> > It's looking like I might get a week of time hacking jaxen sometime
> > after October 15th.  My intention is to do as much of the following
> > that I can:
> > 
> >   1) JavaBeanNavigator (to finally obviate the need for jxpath).
> 
> I've implemented a tentative JavaBeanNavigator as part of an XML forms
> package I'm working on. It's a work-in-progress and is incomplete (and
> my approach may be too quirky, or not general enough to be included in
> Jaxen), but you are welcome to take a look at it if you are interested.

Absolutely.  Can you tell me more about the implementation.  I was 
thinking about using commons-beanutils from jakarta to do it and
basically only support the child axis (property-access) and a
psuedo-namespace 'super' for calling superclass methods.  Do dynamic
method resolution so that $obj/getName() would do what you think it
should.

> The use case I was trying to support is, I think, a bit different than
> JXPath. I wanted to support "live" XPath selectors that can be bound to
> controls in a GUI (similar to XForms, though XForms had no bearing on my
> design approach). These selectors support event notification of
> underlying changes in the model that might affect XPath evaluation
> (assuming the underlying document model supports an event model), as
> well as update. Generalized interfaces are used so that adapters may be
> created for different data/document models. I've currently implemented
> support for JavaBean properties and DOM (with support for DOM2 events).
> I haven't implemented support for collections or indexed properties,
> yet, but the basic hooks are there for extensibility. These can be used
> without event-handling, as well, if desired (or if used with a document
> model that does not support an event model).

That sounds cool.  I'm not a GUI guy, so I really can't evaluate this stuff.

> I've also implemented a lightweight object model that is designed to
> provide a thin veneer over SAX. It maintains context info so you can
> select via the parent, ancestor, attribute, or namespace axes for any
> element (but no children or descendants). It is intended to support
> rules-based processing of XML streams without having to build a complete
> in-memory tree representation of the data, or to support a pattern-based
> approach to annotating XML data with arbitrary metadata (such as tooltip
> text or contextual menus that can follow the data around in a UI, or
> object representations of the data to support data-binding). (This is
> why I'm getting into the pattern classes in Jaxen, though I was
> sidetracked by other things this last week or so. I hope to get back
> into the pattern stuff this weekend.)

Once again, cool stuff.

> I plan on releasing this stuff under MPL soon. If you think you may have
> some interest in incorporating any of this into (or adapting it for)
> Jaxen, let me know and I'll try to expedite getting this stuff into my
> SourceForge CVS repository so you can take a closer look. I'd be willing
> to donate it to the Jaxen project if there is interest.

Yah, I definitely would like to take a look.  It won't be until after
mid-October, so no rush on getting anything into CVS. :)

I can't wait to get back into Jaxen to clean up and expand what
it can do.  

        -bob 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest

Reply via email to