On Sep 12, 2006, at 2:52 PM, John Mettraux wrote:
Hi Philipp,
On 9/12/06, Philipp Bracher <[email protected]> wrote:
I would say that the name of the node should be the name of then bean
(name of the property or variable). Perhaps you have to provide a
name to the encode method:
myBean = new MyBean();
myBean.setName("gugu");
Encoder.encode(myBean, "myBean");
-->
>> <sv:node sv:name="myBean">
>> <sv:property sv:name="jcr:primaryType" sv:type="Name">
>> <sv:value>nt:unstructured</sv:value>
Indeed, we were thinking about that with Nicolas. OK.
Is there a reason for the prefix field_? I think we should avoid this
prefixes if possible to make the properties transparent. If we use
the code for the configuration we will have this field_ prefix
everywhere. I think we better use prefixes/namespaces for persisting
related information like the class or similar.
I used the "field__" and "entry__" prefix to avoid potential
What is the difference between field and entry? field means property
and entry means what? If I'm right this means a map or collection
entry. If we use a subnode for maps and arrays (I thought so), then
we will never have fields and entries on the same level. Am I right?
collisions. Imagine a bean with setclass(c) and getclass() methods,
This would be a stupid bean since getClass should not get overridden.
they would collide with the 'class' property of bean nodes.
But of course, a change in the point of view and the problem is solved
: the 'class' property could get renamed to something like
"bean__class" which is more safe (but not totally safe though).
Looks reasonable for me. We use mgnl: prefixes for similar things.
Perhaps you use a similar prefix. Something like prs:
About "entry__" I used it for arrays and collections, having
properties and nodes named "entry__0" to "entry__1". IIRC, I can use a
number as an item name and that would be OK.
If I understood a map would encode like that:
n: myBean
n: myMap
n: entry0
p:name = test
p:value = testValue
n: entry1
...
but I would like to use the property name instead:
n: myBean
n: myMap
p:test = testValue
p:
...
About "entry__" and maps, I currently plan on enumerating the entries
(thus being OK with maps like LinkedHashMap). I couldn't use the
Do you need that trick? If you iterate a ordered map it will use the
order. If you use the same order during reading (as it will by
default) then you recreate the order again. I think we should not
escalate the hierarchy to much.
scheme were the key is used as a node name : keys could be beans as
well, so I store maps as lists of entry (nodes). I'd use the number as
the sub-item name.
Perhaps you use the class property to distinguish beans, maps,
arrays. Perhaps we use a property like prs:type which can be class
map, array, collection, ....
WDYT ?
Another question : can I use a "owfebean:" namespace with
nt:unstructured nodes [and properties?] within Jackrabbit ?
Yes
Within
Magnolia ?
It's not easy to register own namespaces in mgnl. This means you can
not make a nodetype like owfebean: fff but you can name nodes or
properties by using this prefix.
Thanks in advance for the feedback and the replies,
--
John Mettraux -///- http://jmettraux.openwfe.org
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
