Comments inline --- Wolf Paulus <[EMAIL PROTECTED]> wrote: > Even if this might turn some developers away, I think it is import to be > very clear at this point. Never worry about turning people away if you really believe in your tool others will too. If your tool is the best suited for the task people will use it. People are using Axualize and the numbers of users grow steadily, in fact very quickly recently. I just gave a presentation last night at the Middle Tennessee Java Users group, and found that many people were dying for a tool just like Axualize. Needless to say I had to get more cards printed up this morning. :) http://www.mtjug.org/mtjugWeb/index.jsp All of this to say there is huge demand for projects such as Axualize. And while there are other tools and other projects, none of them are as feature complete and performant as Axualize. > > While we are certainly not done developing Swixml, we will not turn it > into a JSP like programming language or general all purpose tool. > Variables, loop, etc. will not have representations in the XML > descriptors. If you think about every dialect which acts to serialize object state is a language. Yours language is just as much a language as Axualize is, it is just very limited. > There a many (I repeat _many_) projects out there, open-source as well > as close source that already support those kind of things. Wow many... Some links would be great. I would like to evangelize some of those folks. :) > > Swixml is not a one size fits all XML-to-GUI converter and doesn't want > to become such a things. Again, Swixml is suppose to be small and fast; Axualize is small (315K) and wicked fast. :) > we certainly don't want to add to the sometimes already sluggish > behavior of a Swing UI. Therefore, every approach that would require to > sub-class most or even all Swing components and widgets has to be dismissed. If you think Swing is sluggish that is one more reason to support any GUI toolkit such as SWT or LWT as Axualize does.
Which approach would require subclassing? The only point I ever mentioned is that many classes used in Swing are meant to be subclassed or implemented in the case of interfaces. Examples are TreeModel, TableModel, ListModel, and just about every holder type class in Swing. Axualize does not subclass anything itself, it only provides a really slick mechnism for making those things happen. > > The JRE 1.4.x already supports long-term persistence using > java.beans.XMLEncoder and java.beans.XMLDecoder. > http://java.sun.com/products/jfc/tsc/articles/persistence2/#jcp > For Swixml this means that there is no need to add to this persistence > mechanism, which allows to serialize complete Swing UIs into an XML format. > Not axactly. XMLEncoder and XMLDecoder have some serious shortcomings. Thus the need for Axualize. XMLEncoder does a vary poor job of serializing complex graphs to XML. And XMLDecoder is very lean on features, and tends to fail in unpredictable and nearly silent ways. Still it is the best Sun has to offer right now, and it is a standard worth respecting. As I see it any serious XML to Object tool should consider JSR-57 support a key feature. > Like mentioned already, Swixml is not done. I.e., we'll add action maps, > which will result in not having to subclass SwingEngine anymore. > However, the overall approach is not going to be changed or widely > expanded for the foreseeable future. For anyone who is intersted Axualize is cconstantly growing, and if you wish to see some simplified tags like SWIXML I am in the process of implementing them now. Feel free to drop me a line with question or suggestions. I believe that Axualize may be the high performance lightweight tool you have been looking for. I will not be offended if you do not think so. :) __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
