You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@day.com> on 2008/09/18 14:28:35 UTC

Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?

A bit late, but my "best-practice" solution, if you want:

In general it is better to use explicit sling:resourceType
definitions, especially for your own node types. You can easily add
the sling:resourceType as a mandatory property with a default value in
your node type definition. This also has the advantage that you can
change the resource type easily later in the repository.

Using primary node types for the script resolution only makes sense
for JCR's built-in nodetypes and quick hacks.

Regards,
Alex

On Fri, Aug 15, 2008 at 6:48 PM, Tobias Bocanegra
<to...@day.com> wrote:
> On 8/15/08, Alexander Klimetschek <ak...@day.com> wrote:
>> Hi all,
>>
>>  if you use both the "standard" servlet/script resolution using an
>>  explicit resource type (eg. myapp/foobar) and sometimes (for
>>  convenience) via the node type (eg. my:type) you get mixed locations
>>  for both scripts:
>>
>>  /libs/myapp/foobar
>>  /libs/my/type
>>
>>  Often you'd like to put them together, which would organize your
>>  repository much better, ie. like this:
>>
>>  /libs/myapp/foobar
>>  /libs/myapp/my/type
>>
>>  Therefore do you think it is possible to extend the script resolution
>>  for node types to search not only
>>
>>  /apps/<ns>/<nodetype>
>>  /libs/<ns>/<nodetype>
>>
>>  but also to search via wildcards:
>>
>>  /apps/*/<ns>/<nodetype>
>>  /libs/*/<ns>/<nodetype>
>>
>>  ?
>>
>>  The first match would win. It's up to the developers to ensure only
>>  one occurence of my:type under /apps/* or /libs/*.
> i don't think that is a good idea. the script resolution is
> complicated enough and this would even add more complexity to it.
>
> regards, toby
>
>>
>>  WDYT?
>>
>>  Regards,
>>  Alex
>>
>>
>>  --
>>  Alexander Klimetschek
>>  alexander.klimetschek@day.com
>>
>



-- 
Alexander Klimetschek
alexander.klimetschek@day.com