Jason,
Very interesting. I have been thinking about something like this
myself. I was not actually thinking about databases, but rather about
XML. I am sure Xalan and a bunch of other implementations of XPath do
a much better job traversing DOM than JXPath. So, wouldn't it be great
to hand the job over to them as soon as it's clear that the rest of the
path will stay within the subtree.
I myself have been very busy lately and probably won't have time to do
anything as big as this feature before October-November. However, if
somebody else is willing to give us a hand, that would be terrific.
Thanks for bringing this up.
- Dmitri
--- Jason Horman <[EMAIL PROTECTED]> wrote:
> The built in support for maps, collections and beans in JXPath gets
> one very far
> in the traversal of object graphs. I am interested though in custom
> traversals.
> An example would be traversal of a RDBMS database. For example, I
> would like the
> expression:
>
> company/[EMAIL PROTECTED]/fname
>
> To translate into:
>
> emps = getCompany().getEmployees()
> rows = emps.select("select fname from employees where id = 10")
> for (row in rows) {
> // collect results
> }
>
> Where employees is obviously some custom db wrapper.
>
> I looked through the reference implementation and I don't see an easy
> way to
> accomplish this. Creating my own NodePointer factory, and NodePointer
> classes
> only allow me to handle the current context, or simple iteration from
> the
> current context. They don't allow me to take over the rest of the
> xpath
> expression, or even access the xpath expression, from a certain
> point.
>
> What would be very cool is if I could just have one of my objects
> implement a
> simple interface that tells JXPath that I will handle the rest of the
> path or
> certain pieces of the path. Example:
>
> // psuedocode
> class MyClass implements JXPathContextHandler {
> public Object, Expression getValue(Object parent, Expression
> expression) {
> // handle the path request
>
> // this would be here "here is the object found, and i
> finished
> // the path traversal"
> return [foundObject, null]
>
> // this would be "here is the object found, and i finished
> paths
> // 0 and 1, continue the expression from there"
> return [foundObject, expression[2:]]
> }
> }
>
> The other context methods, iterate, remove, setValue would also be
> part of the
> JXPathContextHandler interface. It seems like this might be a simple
> way to
> extend JXPath beyond its current support for Collections and Maps.
>
> It does look like the Container interface could be a decent place to
> add this
> functionality.
>
> If there is already an existing way of providing this functionality,
> short of
> rewriting the ReferenceImpl, please let me know.
>
> -jason horman
> [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
