jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Node.orderBefore(String,String)
Date Thu, 30 Dec 2004 14:25:46 GMT
hi markus,

please apologize the long delay for my answer

> >personally, i usually avoid sns use in favour of residuals, however i can
> >see that people may have a different opinion on that topic.
> >i must a admit that, when i saw your earlier post the content design
> >that was suggested by your question looked a bit unusual to me,
> >however probably legitimate.
> I thought having equal names for node types would be the way to go. But
> I'm not fixed on using SNS. Looks like I have to read up on residuals.
> Giving the nodes different names (with business meanings) would mix
> structure and content, or? ( I somewhere read about using a jcr:content
> node to seperate structure & content which would imply to not use business
> properties in the node name).

> I give you a concrete example I prototype with, so the discussion can be
> more concrete:
> I would like to store a webpages structure+content in the repository (not
> the html but the parts from which the html will be generated).
this is certainly an architecture that i think is perfectly suitable
both for cms (this is how it should be done) and also this exactly
how i see a jsr-170 repository being used in our own cms product.

> I thought about a structure like
> RN
>  |
> pages
>  |
>  |-tst:page[1]
>  |   |-jcr:content
>  |   |   |
>  |   |   tst:title
>  |   |   |
>  |   |   tst:pictures
>  |   |
>  |   |-tst:page[2]
>  |   |...
>  |
>  |-tst:page[3]
>      |
>      |-...
> (hopefully this ascii art isn't destroyed by the mail transfer ;-))
> This would also reflect the ordering of the pages.
> As you can see I use "tst:page" as node name. I could for sure use the
> content of the tst:title property of the jcr:content node as name instead
> of "tst:page".
> That might have some advantages like a more natural navigation through the
> tree and fewer problems with ordering.
> What would be your approach to realise this scenario? I would really
> appreciate your thoughts about that.
the apporach that we have used for the last number of years
has been the following:

 |-aboutus (tst:page)
 |   |-jcr:content
 |   |   |
 |   |   tst:title
 |   |   |
 |   |   tst:pictures
 |   |
 |   |-financial_reports (tst:page)
 |   |...
 |-products (tst:page)

i put the nodetype into brackets (nodetype) where it is
the benefit of that solution is that not only do you get the
sortorder but you also get a human readable useful identifier 
(the path) as a free side effect.
which means that when you have to expose that identifier 
for example to a uri you will not have to have something
like /pages/tst:page[1]/tst:page[2] or uuid=1234-12314123-...
in your uri but something that actually makes sense to
people or machinery reading, bookmarking, indexing...
so you could imaging a uri that says something like
/pages/aboutus/finacial_reports .
> >could your suggestion be an additional api call
> >something like the addition of a Node.getIndex() method
> >which returns 1 if non-sns ?
> >(we could put as an input from the public on to
> >our jsr-170 issueslist ... obviously i am trying to keep changes
> >to a minimum at this point ;) )
> Yes. That would be a very important improvement. If you have SNS and a
> orderBefore method, you need a way to find the position (withouth being
> forced to hack strings together. That seems really hacky).
> But me personally would like to see a method like orderBefore(Node,Node)
> in addition. I'm not a big friend of operating with strings if I already
> have the nodes which I would like to use for the operation.
we discussed both of those options. the orderBefore(Node, Node)
and generally operations where nodes are passed were avoided 
because you could potentially pass in nodes that were from 
a different session, or possibly repository, etc...

we added the getIndex to the Node though. see the hopefully
soon to be publicaly available proposed final draft.

> >i am not aware of another solution that would keep your original
> >sns based content design in place.
> As stated above. This is just a prototype. I'm trying to find the best
> solution and have no problem with discarding the sns approach.
again sorry for the dealy.


standardize your content-repository !
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel

T  41 61 226 98 98
F  41 61 226 98 97

View raw message