Discussions

News: Open Source Rich Client Toolkits Bring New Alternatives to HTML

  1. A number of options for free, effective rich client development have emerged from the open source world recently. These frameworks offer simple rich client development with hooks into java and/or Web Services based back-end communication. Luxor-XUL, XWT, and eNode Xalan are just a few.

    TSS member Gerald Bauer writes:

    Luxor (http://luxor-xul.sourceforge.net, currently at 1.0 beta 5) is a rich client tool based on Mozilla XUL (XML User interface Language) and built on Java. XUL tags not found in HTML or XForms, for example, include such goodies as <menubar>, <toolbar>, <datagrid>, <tree>, <slider>, and much more.

    Add SVG (for 2D graphics in XML), JNLP/Web Start (for zero-admin, single-click client app delivery using XML startup descriptors), Python (for scripting) to the picture and you get a compelling free, open-source, open-standard, Java end-to-end, alternative to closed-source, proprietary, Windows-first, rich client solutions such as Macromedia Flash MX or Microsoft .Net Windows Forms.

    XWT is built on Java as well, however, it is limited to Java 1.1 but offers built-in scripting for Web Services (that is, XML-RPC) over SSL.

    eNode Xalan is similar to Luxor. It runs on Java 2 and uses Web Start for zero-admin, zero-hassle, zero-touch, always-up-to-date single-click client delivery.

    Related News Macromedia Builds FlashMX Rich Client Front-End to J2EE Petstore.

    Threaded Messages (44)

  2. there is also an excellent open source project from a german outfit which allows swing type appications to be rendered in html... take a look at

    www.wings.to.com

    there is a swing demo developed with thier wings package... the basic idea is to change JTable, JListBox, etc to STale, SListBox and turn your swing apps into wings servlets... it seems similar to the .Net idea of having WebForms which have a more or less one to one correspondence with the net .Net forms...

    a propriety product which delivers applets using HTTP tunneling cna be found at a small startup from MIT at

    www.nexaweb.com

    these two sites are well worth looking at also...
  3. Hi,

      Just to make it clear Luxor is not yet another web app toolkit a la Winglets, Swinglets, Java Server Faces, Bali or whatever (http://luxor-xul.sourceforge.net/research.html#webtoolkit)

      The key difference is that Luxor XUL apps run *outside* the browser on their very own Java runtime. Although Luxor uses a built-in HTML widget and opens documents in household web browsers, it goes way beyond HTML/Javascript/DOM (aka DHTML) using XUL, Python, SVG, Velocity and more.
     
  4. The eNode product looks very cool but it doesn't appear to be a free product. Is there a freeware version of eNode that I don't see?
  5. <quote>
    The eNode product looks very cool but it doesn't appear to be a free product. Is there a freeware version of eNode that I don't see?
    </quote>
    Not everything is free.
  6. XUL does look promising. Mozilla has native support and now Luxor provides a Java implementation. Maybe someone needs to implement XUL in Flash, then we'd have an implementation of XUL for all major browsers and Java. Then XUL could have a great chance at becoming the next UI markup langauge...
  7. XUL in Flash???[ Go to top ]

    Perhaps I've missed the point, but I thought that Luxor/XUL could be used as an alternative to Flash for developing cross platform web delivered application user interfaces, albeit without the animated graphics?
  8. XUL in Flash???[ Go to top ]

    For a free implementation of XUL in Flash you can check ZULU.
    It's just beta 1 but I'm actively developing it and I'd really appreciate some feedback.

    Ovi
  9. XUL in Flash???[ Go to top ]

    The linkZULU is dead
  10. XUL in Flash???[ Go to top ]

    I actually see people coming. I've checked the link again and it's ok. You can try again netspedition.com/zulu or netspedition.com/zulu.html, both are working.
  11. XUL in Flash???[ Go to top ]

    Hi - -?

      I was wondering who is behind Netspedition Zulu? How long have you been working on it? How much is open-source and how much is free-of-charge?

      I see from your website you work out of Toronto. Can you out yourself or do you believe a faceless company helps to builds trust in your products?
  12. XUL in Flash???[ Go to top ]

    Hi Gerald,

    I am the president of Netspedition Inc, a small software company in Toronto.

    ZULU is our first product based on Flash technology. The idea is one year old but we just recently found the time to develop it. Depending on developers' feedback we may decide to make it open-source. ZULU is free of charge for commercial use.

    Thank you for your interest,
    Ovi Comes
  13. XUL in Flash[ Go to top ]

    Hi Ovi Comes,

      thanks for your answers.

       Zulu is a great idea. Keep up the good work. I will add a link and a blurb at "The Richmond Post" - Chronicle of the Xul Revolution - in the coming weeks. "The Richmond Post" is online at http://luxor-xul.sourceforge.net/post.

      - Gerald
  14. XUL in Flash[ Go to top ]

    Hi Gerald,

    I appreciate the feedback. It's very encouraging. Thank you for presenting ZULU on "The Richmond Post".

    Ovi
  15. Some food for thought:

    It is nice to see open source initiatives in the area of rich clients. HTML is the defacto standard way to deliver UI for web applications it seems. There is a fixation with the browser being the end-all and be-all for all web based applications. The browser rules, but if we think about, the browser is perhaps a mutation of the dumb-terminal (a pretty one at that) in concept.

    Delivering web applications that require statefulness over a stateless protocol with the limited UI rendering capabilities of HTML has gotten us a long way. Very creative solutions have been formulated so that we can piggy-back on the ubiquitous HTTP. Have you ever designed a UI (for the desktop) for a stateful application in which you incorporated a 'Back' and 'Forward' button?. What problems will that pose for the state of your application. Using HTML for UI is very limiting to say the least. We have reinvented pull down menus, grids, and other navigational aids via javascript, flash etc. Doesn't the desktop already have native ways of doing these already?. It would seem that HTML was invented for one thing, it has since been band-aided and duct-taped with supplemental technologies to do things way beyond what Tim Berners Lee had originally conceived it for?.

    About two years ago, there was an idea that I was pursuing to address some of these questions. Unfortunately, the bottom fell off the market right around the time I was trying to generate business interest in the investment community. My research at that time (and I still keep an eye on this field) indicated that many others were cognizant of the same issues and were coming up with new ideas and products to solve the same business need. It is great that open source initiatives have also arrived to fill this need.
    Some of the commercial initiatives are from Kenamea, Altio, eNode, Curl and Droplets to name a few. Many of these companies have deftly marketed themselves to remain 'under the radar' so that they are not perceived as browser killers (perhaps that is too strong a description).

    Curl corp interestingly had Tim Berners Lee as part of the company, perhaps he is still on board with them. They had very eloquently stated the need for rich clients for web applications. If there is interest I can dig up some of the links I had collected to such articles.

    I am very interested in hearing what others have to say about how they see HTML based web applications evolving towards rich clients such as XUL based clients.

    P.S: I am not affiliated with any of the named companies above.
  16. For administrative purposes many people prefer desktop applications over web applications, simply because they are most robust, are more responsive and are very often much more efficient for intensive use.

    A consumer product may need all the bells and whistles that can only be implemented using 3rd generation language. But for most business applications this is typically not what determines the success of the application.

    We already have a platform-independent technology that implements an MVC-model, is capable of storing the layout in XML, supports the four major operating systems - and that's Java/Swing. So there is really no need to invent something new here. What I am more interested in is the *process* by which the application is created.

    I work for a software vendor in the telco space that develops standard business applications with several hundred screens. We sell the product to about a hundred customers around the globe who use them intensively for several years. The challenges we most often face are the following:

    * Prototyping - we need to quickly build prototypes, demonstrate them to customers and get feedback, adjust the prototype, demonstrate again and then implement.

    * Customizations - although we develop a standard product customers often want us to customize it (add more fields, change layout, add business rules). These customizations should not be lost when upgrading to the next version of the standard product.

    * Testing - too much time is spend in the development process actually testing the GUI. Swing GUIs - whether handcoded or developed using e.g. JBuilder - are often riddled with bugs and too much time is spent writing and testing seemingly trivial GUI functionality

    * Performance - programmers are often so busy that they don't have the time to write some of the tricky code that greatly improves the client's performance and as a result the performance is sometimes perceived as being slow

    * Look & Feel - we must ensure that alls screens have a consistent look and feel, since this reduces the need for documentation, training etc.

    * MVC - some people may not care, but it's amazing how complicated an application can get when GUI code and business logic are intertwined. So we want to separate the visual layout from the business logic.

    * Integration - integrating to server-side business logic should be straightforward and robust.

    * Deadlines - too often projects are running late because the client-side has bugs, is inconsistent, and needs a final design brush-up.

    * Standards - the solution should be based on industry standard for all the well-known reasons

    These challenges are by no means unique for my company, but I am still looking for the right tool for the job. Large (and even small) business applications should not be developed in Java, C++, JavaSript, VB or any other 3rd generation langauge. Instead, their layout should be visually designed and their behaviour should be logically linked to the server-side business logic.

    Based on these experiences I have started working on a prototype for such a tool. I am currently completing the visual GUI designer and will soon start working on the part of the designer that defines the intelligence of the application.

    People who have comments or are interested in hearing more may contact me directly a thomas dot b dot pedersen at mail dot dk

  17. Open Source Rich Client Toolkits... (Some food for thought)
    ---Great stuff! Nexaweb actually provides such a tool(Nexaweb Designer?). It used to be on their website but somehow can not find it anymore...
  18. Thomas brings up some great points and pretty much they can be boiled down to how hard is it to write the petstore. E.G. for business apps and given the broad J2EE adoption their for writing applications how compatibile is your development/deployment model with it.We wrote the Nexaweb Pet store to illustrate this point. For a mere 3% code of modification (changing the presentation layer jsps) from spitting out HTML to spitting out XML(XUL/SVG/Xforms) appropriately we deliver a non-PETA compliant pet drag and drop into shopping cart with tree controls for the catalogn and floating windows for search experience that for common transactions like buying pets delivers up to a 90% bandwidth reduction due to incrmental screen updates. You don't need to touch anything but the presentation tier and don't need to recompile the java classes. It took a fresh J2EE dev who didn't know the 40k lines of petstore code or XUL/SVG/Xforms on Nexaweb only a week to write the petstore on Nexaweb.

    <p>
     The more you have to change the development/deployment model and the more proprietary the output language is the greater risk you are taking in writing your app and thus also raising its cost both to write and maintian the application. For most apps this rise in cost can easily surmount the benefit to the productivity gains from the rich client which is why a lot of business apps still today tend to get written in HTML. IF you are macromedia your petstore requires a huge rewrite of code since you have to code it up on the client side in java/actionscript so they didn't bother to do that code comparison. It would be great to see what these other toolkits can do to implement the pet store.

    By the way the Nexaweb Designer beta can be seen here. Its integrable with traditional development environments like eclipse etc...



  19. Whoops a url typo - here is where you can find the Nexaweb Designer
  20. Hi Rajeev Surati,

      I was wondering how much of your Nexaweb stuff is open-source and how much is free-of-charge?

      
  21. Hi Gerald,

    you asked an interesting question...
    Nexaweb is free for developers and we broadly support open standards because that makes it a level playing field and gets people to want to adopt the technology and get corporations to start using it ubiquitously which makes possible all sorts of opportunities. Our server product enables real time apps over low bandwidh connections using open standard based XML that Fortune 2000 enterprise are deploying because it is compatible with their current J2EE development and deployment practices. Whatever they do on the server it must be the case that it emits open standard based XML because then they aren't screwed when/if the company
    goes away along with the support for the client.

    So in our minds an open source client, like Luxor or any of the others, even believe it or not a MSFT client that supports SVG/XUL/XFORMS + whatever else is the way to go.
    That way when folks write their applications they aren't betting the boat on some company. As long as the XML rendering engine, just like the HTML rendering Engine becomes standardized the sooner the better. We're out to make money by providing enterprise type features much in the same way that app server vendors make their money selling support and J2EE clustering/caching solutions to enterprise that things like Tomcat don't provide.

    We were forced to write a client because there was no such client that was standardized and adopted all ready. We believe that it will use XUL/SVG/Xforms etc... so that's why we wrote it. Our long term strategy is to use what becomes standardized because our value is in making the server client connection efficient and sufficiently abstracted and in many sense. We think that the GUI functionality should be open standard based XML and that likely will/should be be "free" or integrated with the OS however you want to view that again the sooner the better for everyone!

    I run a fairly large web site: www.photo.net along with philip greenspun. It runs on the arsdigita(now redhat) community systems which is open source, I even wrote some modules, but even getting that to work and scale required some custom "enterprise-scale" features for cache coherence across multiple servers and we relied on some code AOL wrote for digital cities to help us out. That's a clear example where enterprise features aren't necessarily something you find open sourced because most people except big companies share that problem and then they want support and responsivity with their solutions.






    That will and should be free.


    We sell a communication/presentation server product that allows J2EE/.NET enterprise developers to continue to code the way they do today to write their HTML based apps.
  22. We already have a platform-independent technology that

    > implements an MVC-model, is capable of storing the layout in
    > XML, supports the four major operating systems - and that's
    > Java/Swing. So there is really no need to invent something
    > new here.

      I'm not sure if we are on the same page and live in the same century, but locking yourself into hardcoded Swing GUI is hardly the end all for rich desktop apps.

      And don't get me started on Java Bean Persistance, if you are alluding to it by saying "is capable of storing the layout in XML".

    > Based on these experiences I have started working on a
    > prototype for such a tool. I am currently completing the
    > visual GUI designer and will soon start working on the
    > part of the designer that defines the intelligence of the
    > application.

      Now this is interesting. Ranting against reinventing the toothbrush. What are you doing here? I wonder how are you going to compete with your one-man band against JBuilder, Netbeans, Eclipse and so on for Swing GUI builders?

      If you want a competitive edge switch to GUI designers/builders for XUL and free yourself and your customers from the Swing toolkit lock-in. I bet JBuilder, Forte and other corporate milk machines won't follow soon as they have a different agenda.
  23. Now this is interesting. Ranting against reinventing the

    > toothbrush. What are you doing here? I wonder how are
    > you going to compete with your one-man band against
    > JBuilder, Netbeans, Eclipse and so on for Swing GUI
    > builders?
    >
    > If you want a competitive edge switch to GUI
    > designers/builders for XUL and free yourself and your
    > customers from the Swing toolkit lock-in. I bet JBuilder,
    > Forte and other corporate milk machines won't follow soon
    > as they have a different agenda.

    I think you are missing my point here. My goal is not to compete against JBuilder, Forte etc, because I think those tools are bloated and completely over-complicated for your common business application. The programmer just needs to know too many things about Swing to be able to write a decent user interface.

    Having fine-grained control over every detail of every single screen and input control may be fine if you are coding a LimeWire program, but for a business application with hundreds of screens you need a tool that significantly raises the abstraction level in order for you to be productive.

    What I was trying to imply with Java is that it would do just fine as the client enabling technology. There is really no need to invent something new that can present a neat user interface on the client.
  24. I think you are missing my point here.


      Am I?

    > for a business application with hundreds of screens you
    > need a tool that significantly raises the abstraction
    > level in order for you to be productive.

      Guess what, XUL raises the bar without regressing to multi media tutti frutti (also known as useless self-executing UML diagrams and other dead ends dreamed up by illiterate suits).

    > I think those tools are bloated and completely over-
    > complicated for your common business application.

      I wish you good look for your Enterprise Builder Lite. Why don't you try to squeeze a tank or pagoda in a sandcorn?
  25. Beyond the mud slinging and name calling, this is an excellent discussion about something very meaningful and important to the future of Web applications. The way I see it, most online apps today (simple/static UIs) will never provide full functionality and will never replace client/server based desktop systems or even older mainframe apps because users can&#8217;t interact with the underlying business logic the way they used to.

    I think all of us here see this, and there are obviously various products and general technology solutions to solve this. However, because the Web is still fairly new and immature, most technologies that go beyond (D)HTML or SWING are only now starting to be recognized and win over people. From the discussion here, it is obvious that the various alternatives and their different benefits and drawbacks are about as clear as mud&#8230;

    When trying to build rich/smart clients, there are so many things that become important that we haven&#8217;t had to consider before. Thomas Pedersen and Neil Smyth mentioned many of them, but essentially I think it boils down to providing a really rich user interface that is still light and fast and doesn&#8217;t fall over after minutes or hours of use. However, what a lot of people don&#8217;t talk about (Andrzej Bialecki did mention this, though in one post) is the integration of the UI to the back-end and making sure that all the richness we create on the client still interacts with the business logic on the back-end. Specifically, a lot of the manipulation of the data should be able to be done locally to minimize network usage and the waiting time for back-end server processing. However, when actions on the client do require server-side processing, all the different controls (buttons, charts, lists etc.) should be tightly integrated with the business logic on the back-end, and we should be able to continue using the app without any latency. The UI should be a seamless extension of the business logic we have created on the back-end. It should not just be a pretty UI with dynamic controls but with no real integration to the actual application. We create some very sophisticated logic on the back-end servers, and UIs that can represent this logic in full are correctly called smart clients.

    When focusing on the UI integration and how it interacts with the bus. logic, I think it is at this point that several of the mentioned solutions start falling short. Just because a UI solution is dynamic, doesn&#8217;t mean it is smart or that it achieves the goal we are looking for. Dynamic UIs with lots of animation and local data manipulation capabilities but with no real integration to the business logic are nothing more than an clever extension of HTML. However, for real business applications to work on the Web, this is not what we need.

    From what I can tell, the solutions that provide real desktop functionality but also lets you create very robust interactions with the actual application must have a server-side component to manage the client-to-server communication. I know Nexaweb has this despite its seemingly early stage and a few other question marks. Altio uses this as well (called a presentation server) and their demos exhibit exactly the type of behavior we are lookig for. I&#8217;ve also heard Macromedia is planning on an identical architecture for later releases next year to catch up and move away from just "animating apps."

    Swing has sort of been the forgotten stepchild in all of this, but maybe rightly so. I think you can code a lot of solid business apps in Swing, but you still have a rather obese client that takes many weeks of hardcore coding and expensive maintenance. Great job security for the coder, but this is not really how we want to build all of our apps, is it!? One important point that T. Pedersen made about productivity was needing much better abstraction when building larger apps with tens or hundreds of screen. Building apps quickly also encourages risk-free prototyping and stimulates creative minds to build things otherwise not attempted before. The UI has so many aspects to it in terms of input requirements that the server-side doesn't. The UI is the piece of the app that everyone else besides engineering actually gets to touch, and we need to therefore involve business- and other non-technical end-users. 20-30 years ago, it was unfathomable that non-technical users would write programs that would perform complex calculations for mission critical tasks. Yet today, we don;t think twice about charging a business analyst with creative an excel spreadsheet for calculating interest rate SWAP values for hundreds of millions of doallars and distributing this to everyone else in the company. Web apps are still complex beasts, but at one point, we have to let go on certain parts of it and make it easy enough for others to partake in the effort (longer vacations for everyone :) )

    What we are all looking for here is not necessarily a general technology to replace HTML, but more comprehensive products that recognize that apps have both a front-end and back-end and the two needs to be tightly integrated while cleverly separated.

    Java is still very viable on the client, but it has to be much more lightweight than Swing. However, it does afford us great interoperability between platforms and browsers and with WebStart, the promise of Java on the client is finally a reality. I think vector graphics and solutions show
    very nice functionality, but few, if any, of them have shown the ability to seamlessly tie into back-end apps and perform data synchronization between front and back-end.

    Just my $0.02, but I would be very interested in what you guys think about the rich client architecture and what the important things are that we should be looking for when evaluating all these products and emerging technologies.

    -Joe
  26. I agree with the points in Joe Mack's comment and I can see from Gerald Bauer's response to my original posting that it may not have been obvious that what I am really interested in is the glue between the client and the business logic on the server.

    While many people here disagree about which data representaion to use for the GUI definition (XUL, Java Bean Persistence, proprietary etc), I think most people agree that Java is gaining more and more credibility on the client side. With Java Web Start and JNLP Java is a very obvious and very viable candidate for rendering the GUI on the client.

    Personally, I don't really care how the GUI is represented in data files, since I don't intend to write those files by hand. What I am interested in is an authoring tool that simplifies the development of rich client applications that interact with business logic on the server side.

    In my project I have first focused on writing a very simple form designer that lays out components using absolute positioning. This is not at all the most preferable way, but it enables me to get something up and runing quickly. I could just as well use Luxor/XUL, which I may in fact do later on.

    The next step is to design an authoring tool that visually allows you to connect the pretty GUI you just designed to some components on the server side. So far, I have not run into anything in that category and I do NOT want to write that glue i Java, Python or any other 3G language, except for the most complicated things.

    I am working on a paper that discusses how such "glue" may work. I'll post it later on what it has more substance.



  27. Having thick clients that allow a user to interact with a web site in a meaningful way wihout making calls back to the server/jump through javascript hoops (in an often broweser dependent fashion) is a big step forward. However I'd like to add a few other points for thought :)

    (disclaimer: I work for Altio and so have a vested interest in this space)

    - by using a thick client, the developer is effectively shielded from the various brwser inconsistancies. For example one of the reasons custom applets have not really taken off is that the various jdk1.1 jvms in the browsers have a lot of subtle issues.

    - the thick client is there to display/interact with data, so there is considerable benefit to having a server side component to manage/route/update the data to/from the client. The client should receive data updates without doing anything. The client then talks to the server side component which manages all interactions of the client with the business systems. It also greatly simplifies integration of the presentation layer with the business systems.

    - ideally the performance of the thick client should be on a par with a desktop system and the user should not be aware of the technology they are using. This implies avoiding requiring a plugin in the browser (plugins are fine for us technical folks but not for the average web user).

    I would also emphasise that the creation of what the user sees/interacts with should be as painless as possible.
    <marketing>
    To that end we provide a browser based drag'n'drop design tool for creating the user interface. Underneath, everything is configured via XML but the user is not exposed to it.
    </marketing>
    This particularily ties in with the point Thomas makes about rapid prototyping.

    I'd be glad to discuss any of the points above in more detail (nsmyth at altio dot com).

    Regards,

    Neil









  28. Hi Neil,

    > I work for Altio and so have a vested interest in this
    > space)

      Is this true?

      Why do use deragotory and dated terms for (super) rich clients?

      Obese clients, fat clients or thick clients have no future because they usually die after a couple of strokes/heart attacks. And don't get me started on bypasses.

      Why do you think Micropoly calls rich client "smart" clients and not obese client? Why do they call C Sharp not D Flat?

    > Underneath, everything is configured via XML but the user
    > is not exposed to it.

      Are you playing the lock-in game here by creating a unreadable XML haystack for "dumb" clients? Or is your radiactive XML suited for hand-coding in a simple text editor a la HTML? Have you heard about XUL?
  29. Gerald,

    I highly regard your professional skills as a programmer and architect, but you apparently don't go along well with people who express opinions different than yours, do you... Let's not degrade this really interesting thread to mere mud-slinging contest, ok?

    Regarding Luxor: I actually tried to run Luxor demos, and browsed the API. The UI layout works great, but when I press buttons in the demo apps nothing happens, i.e. the events are not wired into any real actions, not even a "this is a demo" popups... The thing I'd love to understand, for example, is how you tie the model to your view, and how you handle the events from the UI. IMHO you should concentrate on providing an end-to-end simple app, instead of just a lot of pure UI demos without any real functionality. Without this understanding Luxor is just a toy to me...

    And BTW: I believe XUL and XUP have a bright future, although (even though I live on Java programming :) I think Flash XUL engines are more likely to take off than Java-based ones... Flash runtime is small and has a strong integration and presence in the browser market. Java plugins are still somewhat unwieldy, and monstrously sized.. Just my 0.02PLN, of course :-)


    Best regard,
    Andrzej
  30. Andrzej,

    I hope your interest in Flash/XUL engines has grown after coming upon Zulu ;)

    Ovi
  31. Wish: More Zulu Docs[ Go to top ]

    Hi Ovi,

      it would be great if you could expand your Zulu online docs. Now it's a little skimpy and leaves the impression that Zulu is a three-hour afternoon hack.

      - Gerald
  32. Wish: More Zulu Docs[ Go to top ]

    Thanks Gerald. I'm working on it. It will be ready soon.

    Ovi
  33. but you apparently don't go along well with people who

    > express opinions different than yours, do you...

      I'm not sure how you come to this conclusion. I respect different opinions and I get along well with my grandma and other non-believers.

    > you should concentrate on providing an end-to-end simple
    > app, instead of just a lot of pure UI demos without any
    > real functionality. Without this understanding Luxor is
    > just a toy to me...

      I have to start somewhere. You are more than welcome to contribute instead of playing the arm-chair critic.

    > I think Flash XUL engines are more likely to take off than
    > Java-based ones..

      You must be kidding. As the name Flash implies, it's goes like Flash - Flash - Flash - Puff (Now it's gone).

      Flash along with Cold Fusion and other single-vendor dead ends will disappear.

      XUL, SVG, and so on will rule along with good old HTML.
     
  34. Satirized for your amusement[ Go to top ]

    I think Flash XUL engines are more likely to take off than

    >> Java-based ones..

    > You must be kidding. As the name Flash implies, it's goes like Flash - Flash - Flash - Puff (Now it's gone).
    > Flash along with Cold Fusion and other single-vendor dead ends will disappear


    Well, Gerald, I disagree. Macromedia did a very good job so far and I'm sure Flash is here to stay. Products with good support and a great community don't die just like that.

    I see in Flash the foundation we need to build the web interfaces of the next generation.

    As for Flash XUL engines, they already took off ;)

    Ovi
  35. Hi Gerald,

    The designer I referred to is a browser based design environment to visually create the user interface to display in the browser. It creates XML files, but these files are in no way hidden and can be viewed in your favourite ascii editor. The XML is designed to be easily readable and editable if that is how you choose to edit it - however that restricts the audience that can develop the user interface - hence the additional support.

    I don't want to turn this discussion into a marketing promo - but I do feel that Java as the basis for smart/thick clients has gotten a bad rap - perhaps undeservedly so. Our applet is jdk1.1 based, but does not use the standard AWT controls but our own graphics library all configured via XML. If you are worried about large downloads, please go to http://www.altio.com/products/altioinaction/altioinaction.htm and try the demos - and look in your cache at the size of the applet :)

    XML based user interfaces do have a bright future...

    Regards,

    Neil

  36. Hi Neil,

    > but I do feel that Java as the basis for smart/thick clients
    > has gotten a bad rap - perhaps undeservedly so.

      I agree. Java is back big time for rich clients thanks to Web Start. The broken promises of applets still linger in many minds.

    > Our applet is jdk1.1 based, but does not use the standard
    > AWT controls but our own graphics library all configured via
    > XML.

      Forget applets. Don't misuse them for zero-admin rich clients.

      Applets are for "dynamic" content snippets inside a web page and not for free-floating, full-fledged, mega-sized, self-installing, always-up-to-date client apps.

      Web Start's single-click magic is the way to go for rich client apps.
  37. Which one of these would best integrate with Struts?
  38. Luxor XUL uses Apache Velocity http://jakarta.apache.org/velocity and XSL-T for client/edge-side processing.

    If you create HTML, XUL or whatever on the server you can use whater you feel like including Struts, Tapestry, Knitware.

     
  39. A Fortune 30 wrote an application that used Struts with Nexaweb recently. There is no "integration" you just continue to do what you do you: write your java classes and just have the jsp pages spit out the appropriate XML (XUL/SVG/XFORMS)

    As long as the solution lets you do that - struts should work just fine. Its good to be compatible with that model because then you make it possible for devs to benefit from
    preexisting solutions. If the solution doesn't do that then you may have to write a lot of code to compensate for this "deficiency" in design.

    please ignore the last two paragraphs of my last posting. I was writing and didn't see it when I posted i.t

  40. I don't know if it's appropriate to post it here. Like most web developers, I've been looking around for a more interactive/intelligent non-propriety web client. If you take a look at those wml tags, they've got very rich features including multi-layers, refreshing part of the page (elements) without refreshing the whole page, format mask, events, etc which are sufficient for most purposes. Imagine how those features can fit into a small cellular screen and bandwidth. Is it not possible to have similar features built right into our standard html's? Note that wml is not a W3C standard.

    Clifford
  41. Clifford,

    I think XUP (http://www.w3.org/TR/xup/) as a protocol for delivering events and user interface updates tries to accomplish this. It seems it can work with any UI models with XML-based representations.

    Ovi
  42. Ovi,

    Thanks for your information. I have visited your web site and tried out the zulu.swf. Great work (and Zulu is so slim in size). We've been trying to use Flash as an alternative to the dumb html client where better interactivity is required. The purpose is not necessarily for the sophisticated movie effect but rather the kind of interactivity closer to a desktop client and avoiding the painful html/dhtml/java scripting process. To make it possible, however, we would need a Flash designer who can do good Action scripting or 2 persons one for Flash and the other for Action scripting. Using Zulu would make life so much easier. I have the following questions:

    - What other Flash components such as drop box, calendar, etc are currently supported?
    - Can the components be dynamically populated (e.g. the listbox items in birds.xul)?
    - Is it possible to do some simple front end data validation or business logic in Zulu?
    - How to populate the flash with data retrieved from the backend?
    - When would some documentation or a more comprehensive example be available?
    - Any plan for Struts integration/support?

    Thanks
    Clifford
  43. Clifford,

    Thank you for your interest in Zulu. Indeed the small footprint - under 100k - is one big advantage for a front-end engine.

    To give you a short answer: current version implements an editable and a non-editable combo-box. We developed an extension mechanism which allows user defined components to be used. This feature will be available on beta 1.1 version. Since the whole interface is defined through an XML document, any component can be dynamically populated with data coming from the business layer.

    As I don't want to crowd this forum with technical details about Zulu, I invite you to visit Zulu Developers Group at Yahoo for a detailed answer.

    Ovi
  44. Hi,

      If you are looking for a no-fluff, fast-paced, example-packed XUL tour, check out my hot-off-the press VanX talk slides now
    online at
         http://luxor-xul.sourceforge.net/talk/vanx-jul-2002/slides.html

       For a more Java-code centric 35.000 feet Luxor XUL panorama check out my JUG talk slides at
      http://luxor-xul.sourceforge.net/talk/jug-oct-2001/slides.html
  45. I immensly enjoy reading these threads. Invonvenience, though, lies in the fact that when I print the whole thread in order to read it without compromising my vision, it never manages to fit in the page. Usually the lines are too long and are truncated therefore.

    As public service to community, I offer to write a PDF printing utility, which will be invoked by 'Print as PDF' button, and will print the whole thread nicely on Letter or A4 sized paper, with page numbering, headers, TheServerSide logo, et cetera, in condenced, yet highly readable layout.

    Floyd, if interested, respond to vgritsenko at acm dot org with technical details. In essence, if I can read the thread as XML from your server, I can return PDF in user's browser.

    To imagine how nice the mail thread may look, click Print button at
    http://semantic-estate.com/gold/opano/view_update.jsp


    Viktor Gritsenko