(Sorry about the slow response. I'm catching up on email.) Hallvard Tratteberg wrote:
<snip/> > I've been toying with this idea myself. There seems to be many proposals for > bean markup, but I would like to support a more direct Swing-oriented > markup, where you e.g. use Swing constants, create layouts, invoke other > constructors than the empty one. All in all make the XML more easy to use > than Java coding. A general bean markup is often too verbose. I agree. This was my motivation. Most of the "bean markup" approaches I've seen are not author-friendly. Swing coding can be cumbersome, entailing lots of boiler-plate code. And I've never cared for those WYSIWYG IDE layout editors. They are clunky to use (too much clicking through dialogs and wizards) and typically generate pretty hideous code. My approach uses high level tags that correspond to Swing components. Attributes map straightforwardly to Javabean properties. There are also placeholder tags that let you call out to code to provide a custom component without extending the markup language. The way I expose Java constants (and methods) is by exposing XPath variables scoped to special namespaces -- similar to the mechanisms Java XSLT engines use for extension functions. I also provide special namespaces for syntactic sugar for certain common purpose. For instance, there is a system properties namespace that transparently exposes System properties as XPath variables. Similarly, you can construct a special namespace corresponding to a resource bundle and expose resources as XPath variables (assuming, of course, that the keys used by the resource bundle are valid XML names). Resource strings with MessageFormat templates can be accessed as functions in the namespace, with the string returned being the formatted result of the function parameters. (The latter is working, at the moment, due to the namespace bug in SAXPath.) You can add any Java object to a form as a named parameter, and it is then exposed as a variable within the form (that's how you hook up Java beans into the form). The form itself is a Javabean that is mapped to the document root "/". Visual components are mapped into the tree model and serve as the context when evaluating XPath expressions within attribute value templates for any of their corresponding attributes in the XML definition file. When evaluating expressions attached to events, the context is flyweight nodes created wrapping parameters to the listener method (typically an EventObject of some sort). The JDK 1.3 Proxy mechanism is used to create any sort of event listener using reflection (and thus has a JDK 1.3 dependency.) The node hierarchy above the context includes an event listener method node, EventSet node, and then the source JavaBean node, so any of this info can be referenced within the expression. <snip/> > In my thesis, to be delivered in a week, I am working on a dialog model > based on an "interactor/gate/connector" abstraction, which maps nicely to > JavaBeans. Although it does not support two-way constraints, it uses > functions for binding "properties". The main problem with using XPath is how > to notice when a path changes and hence requires to be recomputed. The good > ol' Garnet/Amulet toolkit supported automatic recomputation by registering > all objects used when evaluating an expression, but this is very time- and > memory-consuming. Sounds interesting. I'll be interested in seeing what you come up with (if you can share it). I'm not familiar with your reference to "Garnet/Amulet toolkit" (maybe I'm just showing my ignorance, here), but the approach you mention is the one I've taken. I am concerned about the overhead, so I'm open to any alternative approaches anyone can think of. However, I'm making some assumptions that I think minimize (to some extent) concerns about the overhead. These are: * For mapping Javabean properties, highly selective paths will generally be used to select a single node. Hopefully, there won't be huge numbers of nodes visited. * Location paths will usually use explicit name tests. I'm thinking I may be able to do optimizations, here (e.g. no need to remember a node that failed a name test -- it's name is not going to change). * Paths typically will not be too deep. I don't think it is a common case to have a very deeply nested property displaying on a GUI. So, again, hopefully there won't be huge numbers of nodes visited. * Changes will be generally be coarse-grained events in response to user-interface events. Considerably more overhead can be afforded in this context than in one where events are fired repeatedly in processing loops. * Asynchronous tasks may update certain state rapidly and repeatedly (and any lengthy processing should occur asynchronously). But I provide lightweight components I call "Instruments" for this purpose. They are attached to a Swing timer and provide update notifications at controlled intervals within the UI event-dispatching thread, with any series of events during the interval pertaining to the same state information (e.g the same Javabean property) collapsed into a single event. You can use these to control at what frequency update events are fired and avoid a deluge of such events. Hopefully this will all mean the overhead will be manageable. I haven't fully implemented this part yet, though, so we'll have to see. > That would be great! I've invested some time on Jaxen and want to avoid > moving to JXPath if I can. > Some of this time has been used to make Javascript (GNU rhino > implementation) work with JDOM and Jaxen, I guess that is interesting in > this context, too, to make the GUI code more alive, e.g. react to events. I like it for this purpose. Gets away from having to create all of those adapters for event listening, and without having to resort to full-bore scripting (I'd rather write my code in Java when a declarative syntax won't cut it). Also, I'm hoping that since the form relies upon the XPath model, I may be able to adapt this approach at some points to work with XML documents instead of -- or in addition to -- Javabeans. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
