On 9/12/06, Philipp Bracher <[email protected]> wrote:
> 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?
I'm not trying to avoid collisions between fields and entries, but
between class/type and fields like said in :
> collisions. Imagine a bean with setclass(c) and getclass() methods,
This would be a stupid bean since getClass should not get overridden.
Indeed, I should have given the "type" collision instead of the
"class" one as an example.
> 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:
Does a prefix automatically implies a namespace ? IIRC, in our first
tests, the namespace registration was missing and the JCRepository
complained.
> 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
...
not exactly.
but I would like to use the property name instead:
n: myBean
n: myMap
p:test = testValue
p:
...
That's what is planned. Our implementation is rather greedy : whenever
possible it uses a property, it tries to avoid diving too deep into
nodes.
> 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.
You're right.
> 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.
That's a good idea.
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.
Then it's fine, our current implementation doesn't rely on custom nodetypes.
Thanks a lot,
--
John Mettraux -///- http://jmettraux.openwfe.org
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
