You always seem to beat the people up who are making
suggestions.
Sorry, not my intention. I admit, that I am quite bad at putting up a
sensible attitude for conversation.
was dreamt of. As to your point about children. I was not suggesting
that you allow getChild but a getChildElements() which like all the
methods that JAXME gives just returns a List of Objecs.
That's not so different. It has the same problem with very unclear
semantics. For example, suggest an atomic element with xs:string. What
do you want to be in the list? The string? Some wrapper element? If the
latter: Call it Element, and you are already beginning to recreate DOM.
The second
issue is about getting a parent which seems a very reasonable thing,
given that the class structure that JAXME creates is fixed around the
XMl structure and therefore to have a getParent() which just return an
Object that can be used to navigate trees etc would be really useful.
The desire to have a link to the parent is in clear contradiction to a
lot of other requests. Currently, the trend is more towards POJO's as
the bean classes. Obviously, a POJO doesn't have a parent reference.
Another problem: How about the collections? If a new child gets added to
the list (or even worse: is filled into the array), how do we know?
I repeat my definite impression, that you might get something working
for your personal desire, but not more. That said, I wouldn't stand in
the way, if someone would start to implement these kind of things. It is
just that I'd clearly not be the person and that I'd insist to separate
the required code from the default code generators. (Luckily, that's
quite possible with the factory chains, because they have designed to
handle exactly these kind of things.) In other words, if you want to
give it a try: You're welcome.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
