Dan, See my comments inline
--- Dan Kirkpatrick <[EMAIL PROTECTED]> wrote: > Forgive me for chiming in here, but I'd like to add my 2 cents worth > here. I've been evaluating most of the XML-based Java guis recently, > and I think I may have some insight on this topic. > > Russell, I think you may be mistaken that changes to Swing may be > difficult to support in Swixml. Swixml is pretty small and > lightweight--the only thing necessary to support new Swing classes (or > user-extended Swing classes) is a new call to regsiterTag()--just one > line of code. If new complex data types are added, new converters will > need to be created, but this really isn't that great a task. Methods > are handled through reflection, so there is no extra effort required to > support the invocation of new methods in new interfaces. Clearly I was mistaken here. Thanks for clearing this up. I apologize for the inaccuracy. > > Wolf, I think Russell may have a point here about the JSR57 schema, > though. In a loose sense, Swixml really is a sort of serialization > language for Swing. In fact, if you added the letter "J" in front of > the tag names, I think you could even use reflection to find the Swing > classes themselves, thus removing the need to register tags altogether. > Swixml has done a *really* nice job of keeping it simple--its syntax is > simpler than JSR57 (its scope is narrower, too). However, JSR57 really > isn't that complex. And it is a standard. And it supports non-Swing > objects, as well. I think there may be some merit in supporting the > JSR57 schema. Why not support a tool which already capable of doing all you wish? If you wish to strike out on your own feel free. But I would love to have a chance to work with people as concerned about a good tool as you are. Come help out. On this point it would be very easy to add classes which implement TagHandler to do the same things you are doing in SWIXML. An example here is the GridBagConstraints TagHanlder in Axualize. This would allow you the all of the flexibility of JSR-57 with the simple complex syntax of SWIXML. > > This would change Swixml greatly. Right now Swixml consists of only > about 20 classes. This is small, and if Swixml decided to stay with its > schema, I can understand it on this basis alone. Changing Swixml to > support JSR57 would really mean then end to Swixml and the beginning of > something new. > This is the crossroads I came to about a year ago. No joke, Axualize was just about identicle in scope and schema to SWIXML. The path I have taken is based on experience developing real world application with Axualize. This is my bread and butter. > That said, I really think JSR57 has something. I think Russell is > correct in saying there is no value added to having yet another > XML-based serialization language (what Swixml is, really--it performs a > sort of deserialization translating the Swixml code into a Swing GUI). Thanks for pointing this out. I believe leveraging existing tools and standards where they exists is a good thing. > Besides, JSR57 supports so much more than just Swing. Looking at the > resulting XML, I don't think it's really any more difficult than Swixml. The support of any class is key to being truly dynamic. Also, because you can create schemas which extend the JSR-57 schema JSR-57 documents can be in my opinion easier to read. > > What if Swixml were to introduce a new interface called "ObjectEngine" > and make SwingEngine implement it? Then the Axualize group could make a > JSR57Engine or something. Hell, my previous request for a > namespace-capable SwingEngine could be a simple extension of > SwingEngine, too. Yeah, it would take some effort. But I think the Here is where I hope to help. For those of you who want it I am willing add SWIXML type tag handlers to Axualize. This is simple enough. The benefits you seek in a namespace capable engine are most likely already addressed in Axualize. Take a look at how Axualize uses "models" to modularize applications. > JSR57 schema has some strong benefits. I'm not sure what extra support > would be necessary, but it seems to me that this approach might even > allow co-mingling of Swixml and JSR57 files in the future (I'm also not > sure of the benefit of this beyond backwards compatibility, and Swixml > really isn't that old yet). Building on JSR-57 has great benfit, and is already possible with axualize. You can easily add JSR-57 documents to an application as a model. This is way cool because there are many GUI builders out there, and you can use any of them to create GUI, then serialize to XML with JSR-57 XmlEncoder, and then make it really rock by turning it into a full fledged application with Axualize. This is the approach several developers have taken with good results. > > I really like Swixml, as much for what it isn't as for what it is. But > I also think JSR57 deserves a closer look. Good observation. Just keep in mind, the features found in Axualize have not significantly increased its size (315K is not large) and those features are those which many developers together have over time decided were needed to create useful client side applications(GUIS). They are there, but you need not use them if you don't want to. The powerful thing about Axualize is the ability to create full on dynamic UIs that can interact with other applications such as web applications in a logical and effective way. If it helps to see a demo of axualize in action check this out http://axualize.sf.net/demo/demo.zip unzip it start jboss run startup.bat (or write a similar .sh if you are using *nix) leave the username and password fields blank to log in. this demo is incomplete, but it runs. The mojo/country module is the most solid. This is not meant for general consumption, but I thought it may help you see the power of using Axualize to create applications. The zip is large because it contains everything including jboss. The J2EE application is in /mojo2 the majority of the JSP used to creat the application are in directories under /protected each module and sub module has a directory. It's far from ready for primetime, but should give you a glimps of what is possible. The application uses J2EE 1.3 including EJB 2.0 and a nice MVC framework. WR, Russ White __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
