You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by jocsch <jo...@freaquac.de> on 2004/12/14 22:16:36 UTC

Node.orderBefore(String,String)

Me again with a jsr 170 question.

Why does orderBefore take two String arguments.
Until I miss something this can/will only work if you have the full node name 
like    
parentNode.orderBefore("tst:case[2]","tst:case[3]");

Getting the full node name is not straight foreward because getName() only 
returns the name without position. It is necessary to retrieve the path and 
grep the substring with the name+position. 

Three issues came up doing so:

1) There is room for improvement in the spec. Why isn't there a method which 
accepts UUIDs or Nodes or whatever?

2) It's better to not have same name siblings (so the name is sufficient to 
distinguish them).

3) There is another possibility to solve this, I haven't recognized.


Any comments?

Thanks,
 Markus


Re: Node.orderBefore(String,String)

Posted by David Nuescheler <da...@gmail.com>.
hi markus,

thanks for your questions. you are welcome to also send those to
jsr-170-comments@jcp.org just for the record.

> Me again with a jsr 170 question.
> Why does orderBefore take two String arguments.
> Until I miss something this can/will only work if you have the full node name
> like
> parentNode.orderBefore("tst:case[2]","tst:case[3]");
> 
> Getting the full node name is not straight foreward because getName() only
> returns the name without position. It is necessary to retrieve the path and
> grep the substring with the name+position.
> 
> Three issues came up doing so:
> 
> 1) There is room for improvement in the spec. Why isn't there a method which
> accepts UUIDs or Nodes or whatever?
well, UUIDs would not be appropriate because they would only
apply to referenceable nodes. passing nodes may look like a feasible 
alternative at first glance....

> 2) It's better to not have same name siblings (so the name is sufficient to
> distinguish them).
...i think in general as you seem to use a lot of
sns in your design you might have uncovered that sns have been 
introduced relatively late into the spec and they are not extensively 
used in the repositories internal nodetypes, never the less they should 
be supported to the full extent.

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.

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 ;) )

> 3) There is another possibility to solve this, I haven't recognized.
i am not aware of another solution that would keep your original
sns based content design in place.

regards,
david
----------------------------------------------------------------------
standardize your content-repository !
                               http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< 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.


mailto:david.nuescheler@day.com
http://www.day.com

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

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

Re: Node.orderBefore(String,String)

Posted by Peeter Piegaze <pe...@gmail.com>.
> Why does orderBefore take two String arguments.
> Until I miss something this can/will only work if you have the full node name
> like
> parentNode.orderBefore("tst:case[2]","tst:case[3]");
> 
> Getting the full node name is not straight foreward because getName() only
> returns the name without position. It is necessary to retrieve the path and
> grep the substring with the name+position.

yes, you have to take the last segment of the abspath of each child node,
which is rather inelegant, I grant.

> 
> Three issues came up doing so:
> 
> 1) There is room for improvement in the spec. Why isn't there a method which
> accepts UUIDs or Nodes or whatever?

No doubt there is room for improvement. Keep in mind that we have
tried to strike a balance between providing useful methods and keeping
the API a reasonable size. So we have tended to avoid the inclusion of
things that we judge to be "convenience methods" or simple helper
methods, that is, methods that are relatively trivial to write and
that the application can provide.

Whether this particular example merits a new method or two is a valid
question,  the spec is still not final...so your suggestions are
appreciated, especially if you find a common use case that we have
overlooked...which perhaps this is.

> 2) It's better to not have same name siblings (so the name is sufficient to
> distinguish them).

This may be true. After all, you are not *required* to use SNS ;-)
BTW, SNS was introduced initially for easy mapping from arbitrary XML
structures (since in XML you can have multiple same-name elements at
the same level in the heirarchy).

Cheers,
Peeter