On 1/16/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > Halo! > > My list was: > > 1/ components > 2/ custom persistence (GRFT-54 like) > 3/ relations > 4/ inheritance > 5/ spread (if it applies, I am not sure yet). > > I am not sure about the connection with collection converters? Are you asking > if the interface of > collection converters fits the interface i was describing for GRFT-54? Well > they are in the same > direction, but there are big differences.
of course, it is just to know if you already review them. > > My goal is to have the 1st 2 defined by the end of this week, so that during > the weekned I can > already start working on them. > > My current vision is to redesign the bean-descriptor to fit all 3 scenarios: > components, custom > persistence and current scenario. In big lines they are very related, the > only difference between > them being the node under which they are persisted: > > components: directly in the current node > GRFT-54: somewhere on a node in a subtree rooted in the current node > current bd: as a direct child node in the current node. > > If all these can be leveled in the bd definition than I guess we pretty much > covered a lot. > Can you give me an example for "component" ? Is it a set of node properties map to a bean ? > ./alex > -- > .w( the_mindstorm )p. > > #: Christophe Lombart changed the world a bit at a time by saying (astral > date: 1/16/2006 11:01 PM) :# > > Well, honnestly I don't remember the complete discussion. > > > > So what are all the improvements you are looking for ? > > 1. the GRFT-54 support - Are there other similar improvements ? > > 2. inheritance > > 3. Spread (?) > > 4. ?? > > > > What about the converter, did you check the collection converter ? is > > it fit your needs ? > > > > > > > > > > On 1/16/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > >> #: Christophe Lombart changed the world a bit at a time by saying (astral > >> date: 1/16/2006 9:48 PM) :# > >> > On 1/16/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > >> >> #: Christophe Lombart changed the world a bit at a time by saying > >> >> (astral date: 1/16/2006 5:25 PM) :# > >> >> > Concerning issue http://issues.apache.org/jira/browse/GRFT-54, > >> >> > Why do you think about the following mapping : > >> >> > > >> >> > <class-descriptor className="xxx.File" jcrNodeType="nt:file" > > >> >> > <field-descriptor fieldName="path" path="true" /> > >> >> > <subnode-descriptor jcrName="jcr:content" ... > > >> >> > <field-descriptor fieldName="mimeType" > >> >> > jcrName="jcr:mimeType" ... /> > >> >> > <field-descriptor fieldName="encoding" > >> >> > jcrName="jcr:encodiging" .../> > >> >> > <field-descriptor fieldName="data" jcrName="jcr:data" ... > >> >> > /> > >> >> > .... > >> >> > </subnode-descriptor> > >> >> > </class-desciptor> > >> >> > > >> >> > the "subnode-descriptor" is there to create a new subnode called > >> >> > "jcr-content" which will contains some object attributes like > >> >> > mimeType, encoding, ... > >> >> > > >> >> > Anyway, I like the "converter" idea. At least, it quite easy to > >> >> > implement it for the fd. > >> >> > Converters for cd already exists but they need to be review. But now, > >> >> > we have to think about how to use the converters for the bd. > >> >> > > >> >> > (I don't speak now on inheritance, we can start this discussion > >> >> > later). > >> >> > > >> >> > >> >> The proposal you are making is quite nice for this particular example. > >> >> But I cannot say how > >> >> extensible it is (by looking at it I would say that it is pretty much > >> >> the bean-descriptor). I would > >> >> like that before introducing more descriptors to be sure that a new one > >> >> will be able to fill in a > >> >> whole range of solutions and not just a particular one. The same > >> >> applies to the existing ones. > >> > > >> > ok - can we create a new jira issues which will contain all use cases. > >> > It is quite difficult to remember all possibilities. > >> > > >> > Thanks > >> > > >> > > >> > >> Not sure what you are asking :-(. Is your question about creating a JIRA > >> issue for each of the > >> suggested improvements? If yes, than I would say that I would prefere > >> having it in the ML than > >> directly on JIRA, and upon concluding adding a JIRA with only the > >> conclusion. But if you think JIRA > >> is better to handle this discussion than go ahead and open the necessary > >> enhancement requests. > >> > >> cheers, > >> > >> ./alex > >> -- > >> .w( the_mindstorm )p. > >> > >> > >> >> > >> >> ./alex > >> >> -- > >> >> .w( the_mindstorm )p. > >> >> > >> >> > > >> >> > On 1/14/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > >> >> >> #: Christophe Lombart changed the world a bit at a time by saying > >> >> >> (astral date: 1/13/2006 11:20 AM) :# > >> >> >> > On 1/13/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > >> >> >> > > >> >> >> >> considering the GRFT54 example, you will write: > >> >> >> >> > >> >> >> >> <bean-descriptor fieldName="file" > >> >> >> >> converterClass="NtFileConverter" /> > >> >> >> >> > >> >> >> >> and NtFileConverter will be responsible for creating the nt:file > >> >> >> >> node structure. Same mechanism will > >> >> >> >> work for fetching. > >> >> >> >> > >> >> >> > > >> >> >> > I like this idea but how set the mapping rules for each attributes > >> >> >> > ? > >> >> >> > I expect the field-descriptor, bean-descriptor & > >> >> >> > collection-descriptor > >> >> >> > are still necessary if we uses the convertClass. > >> >> >> > > >> >> >> > >> >> >> This is a very good question to which unfortunately i don't have a > >> >> >> good answer. While a predefined > >> >> >> converter knows how to deal with a limitted set of > >> >> >> properties/subnodes, on the other side (e.g. on > >> >> >> objects world) those properties may come from really complex > >> >> >> expressions. > >> >> >> There are a few possible approaches to solving this, but for the > >> >> >> moment none of them satisfies me: > >> >> >> - have the object implement an interface which responds to the needs > >> >> >> of the converter > >> >> >> (may be considered bad because it ties the object to the ojcrm tool) > >> >> >> - have the description provided through the same mechanisms of fd, > >> >> >> bd or cd > >> >> >> (may be considered bad because the mapping becomes complex, and > >> >> >> changes in some way the semantics of > >> >> >> fd, bd and cd) > >> >> >> - create/reuse a object graph navigation language > >> >> >> (may be considered bad because the user should learn a new/the user > >> >> >> should use a new `language´) > >> >> >> - have the converter provide extension points so that in special > >> >> >> cases an user may extend it to > >> >> >> extract the values/populate the values > >> >> >> > >> >> >> Example: > >> >> >> 1/ in the simplest case where the object provides accessors to the > >> >> >> object properties according to > >> >> >> the needs of the converter than you don't need to detail the mapping > >> >> >> (the node property paths and > >> >> >> subnodes paths maps directly to object properties) > >> >> >> 2/ in more complex cases where the object needs special manipulation > >> >> >> in order to provide/to write > >> >> >> object properties, than the user should extend the converter and > >> >> >> provide access to those properties > >> >> >> > >> >> >> what do you think? > >> >> >> > >> >> >> ./alex > >> >> >> -- > >> >> >> .w( the_mindstorm )p. > >> >> >> > >> >> >> > >> > >> > >> > > > > > > -- > > Best regards, > > > > Christophe > > > > > -- Best regards, Christophe
