Re: Form post as submission...
On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson justinedel...@gmail.com 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 justinedel...@gmail.com wrote:
On 7/22/10 3:17 PM, Tony Giaccone wrote:
order
nameBob Smith/name
accountNumber12345/accountNumber
lineItems
lineItem id=1
qty1/qty
descWidget/desc
price1.99/price
lineTotal1.99/price
/lineItem
lineItem id=2
qty2/qty
descBar/desc
price2.00/price
lineTotal4.00/price
/lineItem
/lineItems
/order
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 Fri, Jul 23, 2010 at 14:00, Tony Giaccone tgiacc...@masslight.net 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...
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: lineItem id=1 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 justinedel...@gmail.com 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:24, Justin Edelson justinedel...@gmail.com wrote: Pretty sure :nameHint can't be used for anything other than the top-level node submitted in a post. input type=text name=name value=Bob Smith/ input type=text name=accountNumber value=12345/ input type=text name=items/widget/qty value=1/ input type=text name=items/bar/qty value=2/ 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 Fri, Jul 23, 2010 at 15:44, Justin Edelson justinedel...@gmail.com 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 qty1/qty descWidget/desc price1.99/price lineTotal1.99/price 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 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: lineItem id=1 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 (p)? 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 justinedel...@gmail.com 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
Orderable Folder
Justin:
So because I'm a little slow, let me be sure I understand what you mean when
you said:
/orders/{orderID}/lineItems - a sling:OrderableFolder
I can't find a reference to a property called sling:OrderableFolder
so I'm guessing that you mean, I should create a folder node
props.put(jcr:primaryType,nt:folder);
but It's not clear to me how to make a folder orderable..
There's this text:
common parent node is defined as having orderable child nodes
Seems to imply it's an attribute of the node type, so
does that imply that a folder is intrinsically orderable?
Tony
Re: Orderable Folder
sling:OrderableFolder is either a jcr type or mixin - not sure which
offhand.
On Fri, Jul 23, 2010 at 11:13 AM, Tony Giaccone t...@giaccone.org wrote:
/orders/{orderID}/lineItems - a sling:OrderableFolder
I can't find a reference to a property called sling:OrderableFolder
so I'm guessing that you mean, I should create a folder node
props.put(jcr:primaryType,nt:folder);
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 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
how to deploy new app jar?
Hi, everyone. I'm a committer on the Sakai 3 project, which we're building on top of Sling. We use a modified version of Sling's Launchpad App. Essentially, it's Sling plus a lot of additional bundles. While I'm doing development, I may end up with a new app jar several times a day. When I'm working on my own machine, I can simply stop Sling, blow away the sling directory, and run the new jar. However, we now have a staging environment at NYU which uses Oracle as the Jackrabbit store, and when I want to roll out a new app jar, I'd rather not drop the whole database if I don't have to. When we go to production, dropping the database will (understandably) no longer make sense. I have no trouble using the Felix console to update bundles one-by-one, but is there a good way to update _all_ the bundles in the Launchpad App without dropping all my database tables? Bringing down the server is ok. many thanks, Zach Thomas Sakai Developer NYU Consultant Sling Enthusiast
Re: Orderable Folder
On Fri, Jul 23, 2010 at 12:28 PM, Justin Edelson justinedel...@gmail.comwrote: We really need a page describing all of the node types provided by the jcr.resource bundle... Started this at https://cwiki.apache.org/confluence/display/SLING/Sling+Node+Types using the same structure as Jackrabbit's wiki. Only got a few done so if anyone else want to finish the rest, feel free :) Justin
Re: Orderable Folder
On 7/23/10 12:34 PM, James Stansell wrote: On Fri, Jul 23, 2010 at 11:28 AM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: sling:OrderableFolder is a node type; you should use it instead of nt:folder in this case. ... [sling:OrderedFolder] sling:Folder orderable + * (nt:base) = sling:OrderedFolder version Note that the actual name is sling:OrderedFolder instead of sling:OrderableFolder :-) -james. Sorry about that
Re: how to deploy new app jar?
Hi, On Fri, Jul 23, 2010 at 7:22 PM, Zach A. Thomas z...@aeroplanesoftware.com wrote: ...I have no trouble using the Felix console to update bundles one-by-one, but is there a good way to update _all_ the bundles in the Launchpad App without dropping all my database tables? Bringing down the server is ok The maven-sling-plugin can install bundles, so if you run a maven reactor build that activates it you should be able to update all your bundles at once. See the autoInstallBundle profile in the Sling parent pom [1] for an example. -Bertrand [1] http://svn.apache.org/repos/asf/sling/trunk/parent/pom.xml
Re: Form post as submission...
Thanks for clarifying this, although it appears to me that these would correspond to HTML div rather than p elements. On 7/23/10 4:45 PM, Bertrand Delacretaz wrote: On Fri, Jul 23, 2010 at 6:00 PM, Justin Edelson justinedel...@gmail.com 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 10:50 PM, Justin Edelson justinedel...@gmail.com wrote: Thanks for clarifying this, although it appears to me that these would correspond to HTML div rather than p elements. Yes, that's what I meant by sequential components of page content, the analogy is correct. -Bertrand
