Rhett Sutphin wrote:
>
> Hi Greg,
>
> I thought I replied to this, but I guess I didn't ever send it. My take:
>
> Q1 - No. This would be a very non-trivial new feature, if it were implemented in a
> sufficiently generic way.
>
> > - but what about: MainXML.getConfigs().findConfig ("mainConfig");
>
> The problem is that there is nothing special about the "config-name" element -- how
> is Castor supposed to know that you should be able to search on it? What if there
> were two string subelements of config, etc.? This is a combinatorially complex
> issue.
>
> Q2 - This is sort of what xpath is for, but it seems like a waste to marshal the
> object every time you want to do a search. I think that custom search code is
> probably the way to go.
You wouldn't need to marshal, the XPath engine, if built generically
could walk the Java object model, instead of an XML object model. Like I
mentioned in my previous post, I actually started down this patch using
Adaptx, it probably wouldn't take me too long to finish it up.
There is also JXPath from Apache, the only problem with that, is that
JXPath wouldn't be able to take advantage of the "XML information"
stored in Castor's descriptors or mapping files, but instead rely on
reflection and a simple naming algorithm, much the same way Castor's
default introspection works.
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
