Wildhoney
commented
10 years ago That seems like a good idea, but it raises another question that you alluded to. In Laravel, the only part that makes it Magento specific are the files that reside in controllers. If we created abstracts for the required methods in each controller, then if in a few months somebody wanted to come along with a Shopify module to work with Mao, it'd be more than feasible.
I'm not too sure on the best way to implement this, but perhaps the files in controllers would all be abstract controllers that specify the necessary endpoints, and then we'd have modules elsewhere that extend these controllers and implement their specialised methods for each eCommerce package.
In answer to your question though, I think we should go ahead with that. One of the features I've wanted to implement is a centralised config file, and with Magento being separate, it'll be far easier to implement this feature now.
aonic
It seems to me this project has use outside of being shipped with a fresh install of Magento, not only that, we will be constantly adding noise/commits to keep our Magento copy up-to-date. Should we not require the users of this project to install Magento outside the scope of this project?
This solves two problems:
To accomplish this we would of course need a config file where we can specify the full folder path to Magento (so Laravel can include the app.php). An added benefit of this is that now Moa can be used for pre-existing Magento sites that are looking for a more modern front-end.
Let me know your thoughts and I can start implementing the code changes to accomplish this.