My apologies for the very slow reply. bob mcwhirter wrote: <snip/>
> 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. I don't support that particular syntax (since it is not valid XPath syntax and not supported by SAXPath), but I do expose arbitrary Java methods as extension functions. I followed conventions similar to that of Java-base XSLT processors. You declare a namespace starting with a particular base URI which is mechanically mapped to a Java class. Methods on that class are then exposed as functions in that namespace (which is why I was so interested in that namespace-scoped functions issue with SAXPath). To invoke a method on a particular instance, you pass the instance as the first parameter (or at least that's the intent; I haven't implemented this last part yet). As a convenience, I also support a bit of syntactic sugar for Java components added to the form as variables. Top-level accessible methods on that object are exposed as function with no namespace whose name starts with "<variable name>.". For example, a method called "bar()" on a component assigned to variable "foo" would be exposed as a function "foo.bar()". I don't try to expose any graph of descendants using dot notation, though. This is intended to support what I would anticipate to be a common use case of adding components to a form to provide "services" to the form. You can even define "roles" on a variable (which are just Java classes or interfaces) and components can discover other components in the form that provide role-based services. (I'm toying with the notion of exposing these alternatively as BeanContext services for components that wish to discover services via those APIs. I haven't decided, yet.) I am not using the commons-beanutils, but there are similar design patterns in use. There is a Node interface that is the key abstraction for Nodes. There are 2 concrete implementations of Node that are used as the base class for all other concrete implementations in the library, at present. Both delegate actual traversal of axes to a ContentModel component (another interface). This permits reusing a single instance of a model component for each *type* of object to be represented as a node. I currently have one concrete implementation: BeanContentModel, which uses reflection to discover JavaBean properties and expose them as child elements. One of the concrete base implementations is a PropertyNode, which delegates access of its value to a Property component (another interface). PropertyNodes can be used for any node that can be modelled as a property, regardless of whether it is an actual JavaBean property. As with ContentModel, there is currently one concrete implementation: BeanProperty, which uses reflection to access a JavaBean property. I want to wed this model to a DatatypeLibrary that can handle conversion between Java atomic types and string representations. I'm working with Sun's Multi-Schema Validator at the moment and considering using it's included Datatype library, though I'm a bit hesitant to introduce a required dependency on it. (The Datatype library by itself, though, can be distributed separately and is much smaller than the complete MSV package. And Sun has released it as open source, so I may just say the heck with it and introduce the dependency.) Using this approach, Java types could be mapped to XML Schema simple datatypes, or an alternative datatype library, if desired. The Jaxen Navigator interface does not give me everything I need, so I've augmented this with a DocumentModel interface. Implementing a DocumentModel for an object model already supported by Jaxen is trivial (unless you also want event-notification support in the model). I currently have 3 implementations: a DOMDocumentModel (with support for DOM 2 events), a BeanDocumentModel, and a hybrid model that dispatches between models on the fly based on node class, permitting XPaths to select against JavaBeans or XML node sets interchangeably. ------------------------------------------------------- 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
