On Sun, 25 Nov 2001, Paul Hammant wrote: > Here a related idea thought about some months ago. It would be possible > with "Long Term Persistence for Java Beans" - LTPJB - (ex of swing > conection, now in JDK1.4) to XSL style to a complete Swing app or just > an entire panel and stream that over TCP/IP to a handler client.
Sounds like an interesting idea, if perhaps a bit weighty (don't know enough about LTPJB to really say). The question is what do we want to accomplish with XML/XSL in this case? We're not just using it to be buzzword-compliant, right? :) My idea is that a user interface can be described in XML. Then we have an XML schema that goes over the user interface we just wrote and tells us if it's a legal user interface or not. Hand-crafting a GUI is a pretty buggy and obnoxious process, writing some XML and checking against a schema is much better in my mind. The next thing is that changing a UI is a lenghty process, what with distributing the new app to every desktop. Changing an XML file on the server means no distribution and instant updates. Then, we have many tools to dynamically manipulate XML, be they Cocoon or whatever. UIs could adapt to new situations at run-time, if we based them on XML. There are probably many more points. I saw this particular light, when I started to use Cocoon1. I wrote several "quick'n'dirty" applications that were needed in a hurry. So instead of writing a frontend I used the web browser and at the server side Cocoon1 to do the logic. I wrote several XSP taglibs to help model the applications. Each application screen is an XML/XSP file residing on the web server and its logic is encoded in XSP taglib calls. User input goes via standard HTML forms. A really quick and dirty solution, which to my surprise is still in use today. When the users need a new screen or new functionality I can provide that in ten minutes. They just call me and minutes later they have their new feature. Comparing that to the Swing-GUI apps we have in use: those are never updated, because no-one has the time. If you know you need a new window for just one week, you don't bother to put it in. The only negative aspect of those browser-based Cocoon1 apps is program flow. The only way you can send a user somewhere else is by using a redirect. You can dynamically calculate the target location for the redirect, but when your apps become larger you quickly lose yourself in a web of dynamically-built redirects. The "if this, go there, else do that except if that is so" type of statements must be centralized in one place, so you can manage the workflow of large applications sensibly. You don't want to distribute these statements over hundreds of XML/XSP files. The Cocoon project's answer to that was at first the Sitemap. Then people realized the Sitemap wouldn't do all that and talk started about Flowmaps and Linkmaps. I don't know the current status of these discussions, but I do think that these concepts are a little too specific to Cocoon. The Cocoon-folks probably don't want to deal with Swing GUIs and such. Also, if I'm not mistaken, it is quite adventureous to change the Sitemap dynamically at run-time. Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
