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 > > ./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 > > > > > -- Best regards, Christophe
