Re: Form post as submission...
On Fri, Jul 23, 2010 at 10:50 PM, Justin Edelson wrote: > Thanks for clarifying this, although it appears to me that these would > correspond to HTML rather than elements. Yes, that's what I meant by "sequential components of page content", the analogy is correct. -Bertrand
Re: Form post as submission...
Thanks for clarifying this, although it appears to me that these would correspond to HTML rather than elements. On 7/23/10 4:45 PM, Bertrand Delacretaz wrote: > On Fri, Jul 23, 2010 at 6:00 PM, Justin Edelson > wrote: >> ...I don't do a lot of document management, but I believe CQ, for example, >> stores a page's paragraphs in a multi-valued String property > > It's not like that, the paragraphs of CQ's "paragraph system" are > stored as child nodes of a node named "parsys" which is found under > the main content node. The tern "paragraph" has a wide sense here, > it's not just a single paragraph of text, it's more a sequential > component of the page content. > > They have pretty much arbitrary unique names, something like > > parsys/text1 > parsys/textimage42 > parsys/text9 > parsys/image12 > parsys/text5 > > So I think it's similar to Tony's problem: with JCR to avoid same-name > siblings you just need to set a unique name for each child node (or > let Sling choose it based on a name hint), name which does not > necessary mean something. Having somewhat descriptive names such as > the above ones helps in debugging and manipulating things, but it's > not a requirement. The numeric values in the node names also have no > meaning in this case. > > Those are just very pragmatic best practices. It would be hard to find > a theoretical justification for the kind of names shown above, but > they work very well for us. > > -Bertrand
Re: Form post as submission...
On Fri, Jul 23, 2010 at 6:00 PM, Justin Edelson wrote: > ...I don't do a lot of document management, but I believe CQ, for example, > stores a page's paragraphs in a multi-valued String property It's not like that, the paragraphs of CQ's "paragraph system" are stored as child nodes of a node named "parsys" which is found under the main content node. The tern "paragraph" has a wide sense here, it's not just a single paragraph of text, it's more a sequential component of the page content. They have pretty much arbitrary unique names, something like parsys/text1 parsys/textimage42 parsys/text9 parsys/image12 parsys/text5 So I think it's similar to Tony's problem: with JCR to avoid same-name siblings you just need to set a unique name for each child node (or let Sling choose it based on a name hint), name which does not necessary mean something. Having somewhat descriptive names such as the above ones helps in debugging and manipulating things, but it's not a requirement. The numeric values in the node names also have no meaning in this case. Those are just very pragmatic best practices. It would be hard to find a theoretical justification for the kind of names shown above, but they work very well for us. -Bertrand
Re: Form post as submission...
On 7/23/10 12:27 PM, Tony Giaccone wrote: > > On Jul 23, 2010, at 12:00 PM, Justin Edelson wrote: >>> >>> It seems we're playing fast and lose with the differences between a nodes >>> name, it's "type" and it's ordinal position. >> Not sure what you mean here. Every node needs a name. A node's name need >> not have a relation to the node's type or ordinal position. >> > > In my mental model of a node, it has intrinsic attributes and external > attributes. > > > Price is an example of an intrinsic attribute specific to a LineItem > > Type is another example of an intrinsic attribute specific to all nodes. > > > These are both explicitly part of the node. A lineItem has certain > attributes, that a paragraph does not for example. A chapter for example may > have a title, while a paragraph usually does not. > > The ordinal number of a lineItem in a collection of LineItems, for me, is an > external attribute. It describes the location of the entity in its > container. Re order the entities, sort them for example by price and not id, > and each entity in the list ends up, potentially, with a new ordinal number. > > > The name of a node, to me, feels like it should be an intrinsic property and > that name should be independent of where it's stored in the document. > > > So for me, and this is in my own little twisted model, mostly based on my > experience with RDBMS, which probably makes that a flawed model for using > with a JCR, using the ordinal number of a node as it's "name" feels so very > wrong. But maybe I just have to get over myself and let go of my previously > good, but what seems like currently flawed model. ;-) > I did not mean to suggest that you should use the ordinal as a name. That's why I changed my suggested data model to use a truncated UUID instead of the ordinal. We are in complete agreement that ordinals make for bad node names. You seem to be saying that because ordinals are bad node names, you want to use the type as a node name and use SNS. Ordinals may make bad node names, but type names are worse. If you need to generate a synthetic node name and ensure that no one assigns meaning to it, use UUIDs. Justin > > Tony
Re: Form post as submission...
On Jul 23, 2010, at 12:00 PM, Justin Edelson wrote: >> >> It seems we're playing fast and lose with the differences between a nodes >> name, it's "type" and it's ordinal position. > Not sure what you mean here. Every node needs a name. A node's name need > not have a relation to the node's type or ordinal position. > In my mental model of a node, it has intrinsic attributes and external attributes. Price is an example of an intrinsic attribute specific to a LineItem Type is another example of an intrinsic attribute specific to all nodes. These are both explicitly part of the node. A lineItem has certain attributes, that a paragraph does not for example. A chapter for example may have a title, while a paragraph usually does not. The ordinal number of a lineItem in a collection of LineItems, for me, is an external attribute. It describes the location of the entity in its container. Re order the entities, sort them for example by price and not id, and each entity in the list ends up, potentially, with a new ordinal number. The name of a node, to me, feels like it should be an intrinsic property and that name should be independent of where it's stored in the document. So for me, and this is in my own little twisted model, mostly based on my experience with RDBMS, which probably makes that a flawed model for using with a JCR, using the ordinal number of a node as it's "name" feels so very wrong. But maybe I just have to get over myself and let go of my previously good, but what seems like currently flawed model. ;-) Tony
Re: Form post as submission...
On 7/23/10 11:08 AM, Tony Giaccone wrote:
>
> I'm right with you, your posting made total sense to me, but then Bertrand
> wrote about not using SNS, and that caused me no end of cognitive dissonance.
> What are arrays of objects? They are typically objects of the same type and
> would be modeled, I assume as SNS. Now if you want to dodge that bullet by
> saying, Well they have names that are the ordinal number of the element in
> the array, ok.. I can live with that, but it feels like a hack, and not
> really the right way to structure that.
>
I think the general idea is that everything can be given a unique name.
Sometimes that name can be derived from the content (i.e. a blog title),
sometimes it can't be and has to be generated.
So, to make it a bit clearer, let me revise my suggestion:
/orders/{orderID} - the order
/orders/{orderID}/lineItems - a sling:OrderableFolder
/orders/{orderID}/lineItems/92efebc2 - the first item
/orders/{orderID}/lineItems/7d845c52 - the second item
I do agree that there is an unfortunate level of dissonance between
"David's Model" and the JCR spec. But I think that is, to an extent, in
the nature of standards committees.
> If we are modeling a document and there are a list of paragraphs, aren't the
> paragraphs SNS ()?
I don't do a lot of document management, but I believe CQ, for example,
stores a page's paragraphs in a multi-valued String property.
>
> It seems we're playing fast and lose with the differences between a nodes
> name, it's "type" and it's ordinal position.
Not sure what you mean here. Every node needs a name. A node's name need
not have a relation to the node's type or ordinal position.
> Now maybe that's the nature of mucking with nt:unstructured nodes, I don't
> know. But I'm trying to wrap my hands around how this all works.
>
>>
>>>
>>> If the solution isn't SNS then what is it?
>> DNS (different named siblings) :)
>
> Yes, well that's fine.. :-)
>
>
>>
>> HTH,
>> Justin
>>>
>>>
>>>
>>> Tony
>>>
>>> On Jul 23, 2010, at 4:12 AM, Bertrand Delacretaz wrote:
>>>
On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson
wrote:
> On 7/22/10 3:17 PM, Tony Giaccone wrote:
>> ...The problem I'm having is that I don't want to give each line item a
>> unique name.
>> Does a node have to have a unique name?...
> Theoretically, no, each node does not need a unique name if you use same
> name siblings
Note that SNS are a bad idea for a variety of reasons, see rule #4 at
http://wiki.apache.org/jackrabbit/DavidsModel
-Bertrand
>>>
>>
>
Re: Form post as submission...
On Jul 23, 2010, at 9:44 AM, Justin Edelson wrote: > On 7/23/10 8:00 AM, Tony Giaccone wrote: >> Yeah, you know.. >> >> I read that entry, and I certainly am in no position to comment on the cost >> of SNS in the repository. >> >> What I can say, is that if you are going to model real world data, and by >> data, I don't mean at the document level, but at a level of some detail, >> then lists, arrays of items of the same type, are rampant and that is a >> data structure that has to be accommodated. > But items of the same type do not need to have the same nam > >> >> It's easy to say in the abstract, to use some identifying title as the name >> of your node, as was done in the blog example, but... look at my example. >> >> There's no "name" for a line item, that you can use like you would a blog >> posting. > What's strange about this statement to me is that the line items in your > original post very obviously DID have names. You just called them id: > I guess I'm distinguishing between numbers and names. Yes, a name can be a number, but I tend to think of names as being alphanumeric. Also I read somewhere, and I can't find the reference now, that one shouldn't use Numbers as node "names". My concern is more that I'm looking for some guidance and there's a lot of information out there from a variety of sources, and it's helpful for someone ignorant, like me, to understand the why as well as the rule. I need to build my own mental model of how to build a document model. > > Alex is correct that this isn't a very user-friendly name, but I'm not > sure how much that matters *in this particular context*. > >> >> Line items have limited data and they have exactly the same structure, and >> they have data that's of the same types. >> >> So my question is, am I modeling at the wrong level of abstraction? Should I >> have one node that describes the whole order? If so how do I handle line >> items in that entry? > I think you're heading in the right direction - one node containing the > first-level properties of the order and then an ordered list of child > nodes for the line items. As I said, I suggest using an intermediate > node between the order node and the line items. I'm right with you, your posting made total sense to me, but then Bertrand wrote about not using SNS, and that caused me no end of cognitive dissonance. What are arrays of objects? They are typically objects of the same type and would be modeled, I assume as SNS. Now if you want to dodge that bullet by saying, Well they have names that are the ordinal number of the element in the array, ok.. I can live with that, but it feels like a hack, and not really the right way to structure that. If we are modeling a document and there are a list of paragraphs, aren't the paragraphs SNS ()? It seems we're playing fast and lose with the differences between a nodes name, it's "type" and it's ordinal position. Now maybe that's the nature of mucking with nt:unstructured nodes, I don't know. But I'm trying to wrap my hands around how this all works. > >> >> If the solution isn't SNS then what is it? > DNS (different named siblings) :) Yes, well that's fine.. :-) > > HTH, > Justin >> >> >> >> Tony >> >> On Jul 23, 2010, at 4:12 AM, Bertrand Delacretaz wrote: >> >>> On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson >>> wrote: On 7/22/10 3:17 PM, Tony Giaccone wrote: > ...The problem I'm having is that I don't want to give each line item a > unique name. > Does a node have to have a unique name?... Theoretically, no, each node does not need a unique name if you use same name siblings >>> >>> Note that SNS are a bad idea for a variety of reasons, see rule #4 at >>> http://wiki.apache.org/jackrabbit/DavidsModel >>> >>> -Bertrand >> >
Re: Form post as submission...
On Fri, Jul 23, 2010 at 15:44, Justin Edelson wrote: > Alex is correct that this isn't a very user-friendly name, but I'm not > sure how much that matters *in this particular context*. Agreed, in this context, numbers might be ok. >> Line items have limited data and they have exactly the same structure, and >> they have data that's of the same types. >> >> So my question is, am I modeling at the wrong level of abstraction? Should I >> have one node that describes the whole order? If so how do I handle line >> items in that entry? > I think you're heading in the right direction - one node containing the > first-level properties of the order and then an ordered list of child > nodes for the line items. As I said, I suggest using an intermediate > node between the order node and the line items. There is one small important thing, that looks like it's already implicitly present in the proposed structures, but still should be highlighted: for the values, use JCR properties. The plain XML structure of a single line item, with XML elements for each value 1 Widget 1.99 1.99 could naively be mapped to JCR nodes. But this would be very inefficient, also for the Jackrabbit implementation. And since you have multi-value properties in JCR, which in XML must be expressed as elements (if comma-separated attribute values don't do it), you can handle all cases. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Form post as submission...
On Fri, Jul 23, 2010 at 15:24, Justin Edelson wrote: > Pretty sure :nameHint can't be used for anything other than the > top-level node submitted in a post. > > > > > > > If you have a second items/bar/qty, it'll just overwrite the first. > > Am I missing something? Ah, you might be right. But that is then only a limitation of the post servlet, that one could improve. Or workaround to get the "right" content structure. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Form post as submission...
On 7/23/10 8:00 AM, Tony Giaccone wrote: > Yeah, you know.. > > I read that entry, and I certainly am in no position to comment on the cost > of SNS in the repository. > > What I can say, is that if you are going to model real world data, and by > data, I don't mean at the document level, but at a level of some detail, then > lists, arrays of items of the same type, are rampant and that is a data > structure that has to be accommodated. But items of the same type do not need to have the same name. > > It's easy to say in the abstract, to use some identifying title as the name > of your node, as was done in the blog example, but... look at my example. > > There's no "name" for a line item, that you can use like you would a blog > posting. What's strange about this statement to me is that the line items in your original post very obviously DID have names. You just called them id: Alex is correct that this isn't a very user-friendly name, but I'm not sure how much that matters *in this particular context*. > > Line items have limited data and they have exactly the same structure, and > they have data that's of the same types. > > So my question is, am I modeling at the wrong level of abstraction? Should I > have one node that describes the whole order? If so how do I handle line > items in that entry? I think you're heading in the right direction - one node containing the first-level properties of the order and then an ordered list of child nodes for the line items. As I said, I suggest using an intermediate node between the order node and the line items. > > If the solution isn't SNS then what is it? DNS (different named siblings) :) HTH, Justin > > > > Tony > > On Jul 23, 2010, at 4:12 AM, Bertrand Delacretaz wrote: > >> On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson >> wrote: >>> On 7/22/10 3:17 PM, Tony Giaccone wrote: ...The problem I'm having is that I don't want to give each line item a unique name. Does a node have to have a unique name?... >>> Theoretically, no, each node does not need a unique name if you use same >>> name siblings >> >> Note that SNS are a bad idea for a variety of reasons, see rule #4 at >> http://wiki.apache.org/jackrabbit/DavidsModel >> >> -Bertrand >
Re: Form post as submission...
On Fri, Jul 23, 2010 at 14:00, Tony Giaccone wrote: > There's no "name" for a line item, that you can use like you would a blog > posting. Have you seen my reply? In reality, there always is some kind of name. Auto-numbered integer IDs are only so common, because relational databases made them popular, and use them for efficient relations between tables. But an ID only has to be unique... and a unique string name or path is sufficient as well. Giving it a readable name makes it more easy for the developer and "content administrator" to work with the content. Just as in a unix filesystem. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Form post as submission...
Yeah, you know.. I read that entry, and I certainly am in no position to comment on the cost of SNS in the repository. What I can say, is that if you are going to model real world data, and by data, I don't mean at the document level, but at a level of some detail, then lists, arrays of items of the same type, are rampant and that is a data structure that has to be accommodated. It's easy to say in the abstract, to use some identifying title as the name of your node, as was done in the blog example, but... look at my example. There's no "name" for a line item, that you can use like you would a blog posting. Line items have limited data and they have exactly the same structure, and they have data that's of the same types. So my question is, am I modeling at the wrong level of abstraction? Should I have one node that describes the whole order? If so how do I handle line items in that entry? If the solution isn't SNS then what is it? Tony On Jul 23, 2010, at 4:12 AM, Bertrand Delacretaz wrote: > On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson > wrote: >> On 7/22/10 3:17 PM, Tony Giaccone wrote: >>> ...The problem I'm having is that I don't want to give each line item a >>> unique name. >>> Does a node have to have a unique name?... >> Theoretically, no, each node does not need a unique name if you use same >> name siblings > > Note that SNS are a bad idea for a variety of reasons, see rule #4 at > http://wiki.apache.org/jackrabbit/DavidsModel > > -Bertrand
Re: Form post as submission...
On Thu, Jul 22, 2010 at 21:44, Justin Edelson wrote:
> On 7/22/10 3:17 PM, Tony Giaccone wrote:
>>
>> Bob Smith
>> 12345
>>
>>
>> 1
>> Widget
>> 1.99
>> 1.99
>>
>>
>> 2
>> Bar
>> 2.00
>> 4.00
>>
>>
>>
>>
>>
> I would treat this as four nodes:
>
> /orders/{orderID} - the order
> /orders/{orderID}/lineItems - a sling:OrderableFolder
> /orders/{orderID}/lineItems/1 - the first item
> /orders/{orderID}/lineItems/2 - the second item
>From a "nice paths/URLs" content model perspective, I would give them
readable names. In this example using the description for example,
using :nameHint = description.
/orders/{orderID} - the order
/orders/{orderID}/items - a sling:OrderableFolder
/orders/{orderID}/items/widget
/orders/{orderID}/items/bar
/orders/{orderID}/items/bar_1
:nameHint will ensure a unique name in case of duplicates. Also using
shorter names like "items" instead of "lineItems" has its advantages
(shorter URLs, more easily readable, etc.).
Just my 2 cents...
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
Re: Form post as submission...
On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson wrote: > On 7/22/10 3:17 PM, Tony Giaccone wrote: >> ...The problem I'm having is that I don't want to give each line item a >> unique name. >> Does a node have to have a unique name?... > Theoretically, no, each node does not need a unique name if you use same > name siblings Note that SNS are a bad idea for a variety of reasons, see rule #4 at http://wiki.apache.org/jackrabbit/DavidsModel -Bertrand
Re: Form post as submission...
On 7/22/10 3:17 PM, Tony Giaccone wrote:
>
>
> I'm doing a form submission as a way to enter information into a Sling
> repository. I need a little advice on how to approach the following problem.
>
> I have an order and the order has line times, and the line times are ordinal.
>
> I want to end up with a node for the Order, and as children of that order, a
> node for each line item. In xml the structure would look like:
>
>
>
> Bob Smith
> 12345
>
>
> 1
> Widget
> 1.99
> 1.99
>
>
> 2
> Bar
> 2.00
> 4.00
>
>
>
>
>
> So I'd like to break this xml down into three nodes. One for the order, and
> one for each of the line items.
>
> The problem I'm having is that I don't want to give each line item a unique
> name. Does a node have to have a unique name?
Theoretically, no, each node does not need a unique name if you use same
name siblings.
However, the SlingPostServlet doesn't support SNS in the
ModifyOperation. It might in the ImportOperation, but I don't know.
>
> If not, how do I construct name value pairs to represent these different
> nodes and prevent the data from the second line item
> ending up in the first one? Do I have to do three separate posts one for each
> node?
I would treat this as four nodes:
/orders/{orderID} - the order
/orders/{orderID}/lineItems - a sling:OrderableFolder
/orders/{orderID}/lineItems/1 - the first item
/orders/{orderID}/lineItems/2 - the second item
You should be able to create all of these with a single post.
HTH,
Justin
>
> Not sure how this should work.
>
>
> Tony
Form post as submission...
I'm doing a form submission as a way to enter information into a Sling repository. I need a little advice on how to approach the following problem. I have an order and the order has line times, and the line times are ordinal. I want to end up with a node for the Order, and as children of that order, a node for each line item. In xml the structure would look like: Bob Smith 12345 1 Widget 1.99 1.99 2 Bar 2.00 4.00 So I'd like to break this xml down into three nodes. One for the order, and one for each of the line items. The problem I'm having is that I don't want to give each line item a unique name. Does a node have to have a unique name? If not, how do I construct name value pairs to represent these different nodes and prevent the data from the second line item ending up in the first one? Do I have to do three separate posts one for each node? Not sure how this should work. Tony
