Hi, I think it's a good idea to deprecate exotic use cases like defining both resourceType and resourceSuperType on a content node. IMHO it is a bad idea though to create a new location for scripts (e.g. "/foo/apps"). Having scripts co-located with other artifacts (I don't call it clutter) in /apps/myapp has never caused a problem in my projects (they are easy to distinguish after all) - in fact another aspect is a lot more important: Grouping of project artifacts should first happen according business requirement/feature (e.g. /apps/blog/blogpage) and then according technical aspects (scripts, component descriptors etc. that belong to it). That way the implementation of a feature is more cohesive, easier to understand and undesired cross-references between features are easier to spot. In AEM implementations we already have at least three locations where a feature "blog page" would contribute: in apps, in /etc/designs and in the corresponding java package - let's not open another location...
Regards Georg > On 19.03.2016, at 14:48, Justin Edelson <jus...@justinedelson.com> wrote: > > Hi, > > On Sat, Mar 19, 2016 at 6:11 AM Carsten Ziegeler <cziege...@apache.org> > wrote: > >> Justin Edelson wrote >>> >>> I guess I'm not really understanding the advantage of this flat list >> (which >>> wouldn't be a single flat list, but multiple flat lists). What is the the >>> difference between >>> >>> /apps/myco/components/bar >>> /libs/myco/components/bar >>> >>> and >>> >>> /foo/apps/myco:components:bar >>> /foo/libs/myco:components:bar >> With /foo you have resource type resources only, nothing else, no >> clutter. It is true, that having /foo/apps and /foo/libs spoils the >> whole thing and my initial idea was actually to just have >> /foo/resourcetypehierarchy - no overlays for the resource type >> hierarchy. But that would go against or overlay principle. > > In your mind, does /foo contain scripts inside the resource type resources? > > >> >> Maybe my idea is not the best, that's why it is an RT :) But I strongly >> believe that we should move the hierarchy definition out of the /libs, >> /apps bags of random stuff. > > > I'm still not 100% sure I understand the problem, but it sounds to me like > the better solution would be to move the random stuff out of /libs and > /apps :) Unless I'm missing something (which is very possible), nothing > would stop this same "random stuff" from showing up in /foo/libs and > /foo/apps. > > It sounds like we need something like FHS ( > http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html). For better or > worse, however, I think such a document needs to really encompass the scope > of AEM (and possibly other downstream platforms based on Sling) to be truly > meaningful. > > Regards, > Justin > > >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >>
