hi guys, i agree with carsten that we probably can't reach on consensus on this list and "design" by committee in this case certainly shows its weaknesses. this is a topic where everybody can have an opinion about but only very few of us larger scale experience with using the sling script resolution to solve their real-life needs.
i think that it is probably the easiest if toby and i come up with a proposal as an actual patch that suits our needs and experiences from a users perspective and meets the performance requirements, and then take this a basis for discussion, and check with you guys where we have shortfalls on the performance side of things... generally, i would like to keep this proposal backwards compatible to the current one, since there are only 2 or 3 that are broken and the rest is perfectly fine and suits the needs. keeping things backwards compatible also makes this a minor change and convenience improvement for current users. regards, david On Sat, Apr 26, 2008 at 11:14 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > > > > > > Well, on the other hand, it has been pointed out that the real issue is > > > just the fact that all scripts are named "htlm.*". I'm really not very > > > optimistic that the simple looking solution to duplicate the node name > (or > > > whatever makes up the last node in the hierarchy) to get the file name > is a > > > clear and simple concept. Telling people that they can write "foo.jsp" > to > > > get html while they have to use "pdf.jsp" to get a pdf, seems very > > > complicated to explain and understand. And as I pointed out, as soon as > you > > > are heavily using any other format than html, you end up with the same > mess > > > (all files named pdf.*) > > > > > > > > > I did think a bit about the refactoring and renaming problems that might > > occur when using prefixes. Since this is a restless architecture it might > be > > necessary to replicate at least the script which is calling the script > which > > is needed by both resources. This is pretty easy when having the scripts > > named the same way (no prefixes). Having a prefix would require renaming, > as > > well as renaming the parent node would require changing the prefix. (which > > would break the default refactoring features for renaming in Eclipse) > > > > Propably it is usefull to remember that a script is never identified > simply > > by its name but additionaly the path. So the name does never identify the > > script (which script is called?) but identfies under which circumstances > it > > is called(when is it called?). > > > > It may be usefull to have an optional prefix (nodename as prefix) to > > "freeze" a path and prevent usage at another location. (This feature would > > come along with the renaming problem but would at least not be the default > > behaviour and require the awareness of the developer of the constraint he > > produces). > i don't see you use case. usually the script is never referenced > directly but addressed via the sling resource type. if you change a > resource type, you would need to adjust the path (and of course the > script prefix) but not change it anywhere else. > i did quite some development with scripts by now for our cms-showcase, > and i think i only included a script directly in 1 or 2 special > locations. all other "includes" work via content include using the > resource type. > > another idea...how about adding an optional name between the type and > the extension? eg: > > /apps/myapp/foo/html.foo.jsp > > the resolution will only check for the "/apps/myapp/foo/html" part, > the extension (jsp) selects the script engine and the intermediate > "foo" is cosmetics for the editors. so when renaming a resource type, > you only need to change the path in the first place. the resolution > will still work. the intermediate name can be changed later. this also > would allow for nice names like "foo/html.FooMain.jsp" or something. > > WDYT? > > -- > toby > > > > > > > > Dominik > > > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
