--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
This was a bit of a pain for me when starting with Silverstipe. Especially with maintaining the .gitignore. The reason why I created https://github.com/guru-digital/SSAutoGitIgnore
It would be nice to have modules in their own sub directory but breaking modules may be an issue.
I know in some of my modules I assume the path will always be in the root when using requirements to include js/CSS.
In later modules I started to use dirname(__FILE__) to set a constant for the modules base directory.
Might not be such an issue if requirements is also modified to search the "modules" folder.
But who knows what else devs may do assuming the module will always be in the root.
I confess I haven't been through as many modules as you have. The only paths I tend to see are the ones each module defines relative to their own root folder. That's not something that this change is likely to affect.I agree that a recommended folder structure is an excellent thing to shoot for. Does it block a change to module loader code that allows both approaches?
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
Requirements::css("modulename/js/cms.js");
You could do this:Requirements::css(__DIR__ . "static/js/cms.js");Then, you wouldn't be so tightly bound to the module name as highlighted above.
Wasn't there also talk of moving the the code out of the public directory? (Or am I dreaming)If so it would seem related as it would need to cover off how assets are handled.
--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/wKVrc0vQ3Zc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.
Yup, that's all part of it. Basically a module exposes the assets that need to be web accessible and they get symlinked by a composer script.
On Sunday, 19 April 2015, Conrad Dobbs <con...@webtorque.co.nz> wrote:
Wasn't there also talk of moving the the code out of the public directory? (Or am I dreaming)--If so it would seem related as it would need to cover off how assets are handled.
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/wKVrc0vQ3Zc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
A good example to look at might be Laravel 5 which uses psr-4 autoloading for everything.
On Monday, April 20, 2015 at 9:11:10 AM UTC+12, Uncle Cheese wrote:
Yup, that's all part of it. Basically a module exposes the assets that need to be web accessible and they get symlinked by a composer script.
On Sunday, 19 April 2015, Conrad Dobbs <con...@webtorque.co.nz> wrote:
Wasn't there also talk of moving the the code out of the public directory? (Or am I dreaming)--If so it would seem related as it would need to cover off how assets are handled.
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/wKVrc0vQ3Zc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.