You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2008/12/01 07:52:33 UTC
Re: List of available resource types
Tobias Bocanegra wrote:
> On 11/28/08, Alexander Klimetschek <ak...@day.com> wrote:
>> IMHO a good practice for sling apps is to always define a node type
>> for all the resources (or at least a mixin) they will handle. This
>> node type
>> a) defines a sling:resourceType with a default value (but one that can
>> be changed later) and
>> b) which allows residual properties (for the full JCR flexibility -
>> although YMMV here).
>
> well, i think not :-)
> one power of sling is its flexibility when it comes to resource/script
> resolution. the hassle you have changing a node type is very big and
> defining a mixin does not make sense, since you normally create the
> node before you assign a mixin. changing a node type last is also
> troublesome - so i would stick to the very few nodetypes that are
> really needed. IMO you should only need 3: sling:Folder, nt:file for
> the hierarchy of the scripts, nt:unstructured for content.
>
I'm wondering what our (= Sling's) suggestion as a good practice for
building own apps is? Define node types or use the sling:resourceType
property with nt:unstructured? Of course each use case is different and
might require a different solution.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: List of available resource types
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Dec 1, 2008 at 11:11 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> In this case I agree that it might make sense to use script resolution
>> based on node types, but in the general case I find the
>> sling:resourceType way of resolving scripts closer to our "data first,
>> structure later" recommendation.
>>
>> My best practice recommendation would then be to use
>> sling:resourceType if possible, and nodetype-based script resolution
>> only if one has to.
>>
> Hmm, ok, although I personally don't like to add rendering hints into
> the content, but anyways, what about documenting this? :)
Regarding script resolution we "only" have something in the wiki
(which is too detailed for the beginner) [1]. There is also Lars'
sling cheat sheet, which is very good for a beginner (but a PDF and
not hosted on/pointed to from the sling site) [2]. The "official"
documentation for this is outdated [3].
[1] http://cwiki.apache.org/SLING/url-to-script-resolution.html
[2] http://dev.day.com/microsling/content/blogs/main/cheatsheet.html
[3] http://incubator.apache.org/sling/site/servlet-resolution.html
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: List of available resource types
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Hi,
>
> On Mon, Dec 1, 2008 at 8:52 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...if you want to display some random data contained in the
>> repository, the primary node type is used as it is very likely that you
>> don't have the special sling:* properties already set for your data.
>>
>> I think this is a very handy behaviour when it comes to check out Sling,
>> so I personally would rather tell new people to use script resolution
>> based on node types than using a special property....
>
> You mean this in the context of existing data in a repository, right?
>
> In this case I agree that it might make sense to use script resolution
> based on node types, but in the general case I find the
> sling:resourceType way of resolving scripts closer to our "data first,
> structure later" recommendation.
>
> My best practice recommendation would then be to use
> sling:resourceType if possible, and nodetype-based script resolution
> only if one has to.
>
Hmm, ok, although I personally don't like to add rendering hints into
the content, but anyways, what about documenting this? :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: List of available resource types
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Dec 1, 2008 at 8:52 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...if you want to display some random data contained in the
> repository, the primary node type is used as it is very likely that you
> don't have the special sling:* properties already set for your data.
>
> I think this is a very handy behaviour when it comes to check out Sling,
> so I personally would rather tell new people to use script resolution
> based on node types than using a special property....
You mean this in the context of existing data in a repository, right?
In this case I agree that it might make sense to use script resolution
based on node types, but in the general case I find the
sling:resourceType way of resolving scripts closer to our "data first,
structure later" recommendation.
My best practice recommendation would then be to use
sling:resourceType if possible, and nodetype-based script resolution
only if one has to.
-Bertrand
Re: List of available resource types
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
>
> Basically, Sling does not care for the actual node types. It just tries
> to get the sling:resourceType property, if this is missing the pluggable
> resource type resolver are called. If this does not resolve either, the
> primary node type is used.
>
> On the other hand, to help in the creation of nodes with setting the
> sling:resourceType property, Sling provides the sling:Resource mixin
> node type, which just defines the sling:resourceType property. Likewise
> there is a sling:ResourceSuperType mixin which defines the
> sling:resourceSuperType property.
>
> Final words:
> * Sling doesn't care for the actual node type
> * Sling helps setting the property providing a mixin node type for such
> nodes, whose actual node type prevents setting the sling:resourceType
> property.
>
> Hope this helps.
>
:) Thanks for summarizing this, Felix.
While Sling in theory does not care about the actual node type, in
practice it does as it uses the primary node type for script resolution
if no sling:resourceType or sling:resourceSuperType property is set.
(and no pluggable mechanism is used).
Therefore if you want to display some random data contained in the
repository, the primary node type is used as it is very likely that you
don't have the special sling:* properties already set for your data.
I think this is a very handy behaviour when it comes to check out Sling,
so I personally would rather tell new people to use script resolution
based on node types than using a special property.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: List of available resource types
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Tobias Bocanegra wrote:
>> On 11/28/08, Alexander Klimetschek <ak...@day.com> wrote:
>>> IMHO a good practice for sling apps is to always define a node type
>>> for all the resources (or at least a mixin) they will handle. This
>>> node type
>>> a) defines a sling:resourceType with a default value (but one that can
>>> be changed later) and
>>> b) which allows residual properties (for the full JCR flexibility -
>>> although YMMV here).
>> well, i think not :-)
>> one power of sling is its flexibility when it comes to resource/script
>> resolution. the hassle you have changing a node type is very big and
>> defining a mixin does not make sense, since you normally create the
>> node before you assign a mixin. changing a node type last is also
>> troublesome - so i would stick to the very few nodetypes that are
>> really needed. IMO you should only need 3: sling:Folder, nt:file for
>> the hierarchy of the scripts, nt:unstructured for content.
>>
> I'm wondering what our (= Sling's) suggestion as a good practice for
> building own apps is? Define node types or use the sling:resourceType
> property with nt:unstructured? Of course each use case is different and
> might require a different solution.
Basically, Sling does not care for the actual node types. It just tries
to get the sling:resourceType property, if this is missing the pluggable
resource type resolver are called. If this does not resolve either, the
primary node type is used.
On the other hand, to help in the creation of nodes with setting the
sling:resourceType property, Sling provides the sling:Resource mixin
node type, which just defines the sling:resourceType property. Likewise
there is a sling:ResourceSuperType mixin which defines the
sling:resourceSuperType property.
Final words:
* Sling doesn't care for the actual node type
* Sling helps setting the property providing a mixin node type for such
nodes, whose actual node type prevents setting the sling:resourceType
property.
Hope this helps.
Regards
Felix