Canoo releases ULC XML, XML tool for Java RIA development

Discussions

News: Canoo releases ULC XML, XML tool for Java RIA development

  1. Canoo Engineering, a provider of Web front-end application development and Java-based software consulting services and products, has released ULC XML, an open source XML tool that creates UltraLightClient user interfaces from XML files. With ULC XML, the XML file is parsed at runtime and rendered into Java objects. Java classes are mapped to element names and property names translate into attribute names. According to Canoo, ULC XML's major benefit is that the layout of the user interface is separate from the Java classes of the application. The XML hierarchy mirrors the hierarchy of UI components such as windows, sub-windows, tables, trees and tabs, and allows developers to quickly assemble a user interface. ULC XML offers a Rich Internet Application (RIA) option for SwiXml/Swing developers. Industrial Strength for Rich Internet Applications UltraLightClient (ULC) is a Java library that enables the development of Java-based RIAs. ULC XML requires a license of ULC. ULC uses Swing on the client, standard communication protocols set by the Java EE container and standard lifecycle management on the server. ULC closely follows Java standards and can be integrated into existing Web platforms. What do you think of ULC XML and ULC?

    Threaded Messages (22)

  2. And what would be advanteges over SwiXML? http://www.swixml.org/
  3. With ULC XML you can use ULC rather than Swing. ULC simply provides a server-side API to Swing for easy development of Rich Internet Applications. For more info please see Canoo ULC.
  4. With ULC XML you can use ULC rather than Swing.
    Oh, please, ULS uses Swing to create client-side UI according to your site http://www.canoo.com/ulc/home/whatisulc.html So, what are the real advantages over SwixML (if any)?
  5. So, what are the real advantages over SwixML (if any)?
    As I said before, ULCXML uses the ULC library rather than Swing. The ULC library is a SERVER-SIDE proxy library to Swing. With SwixML you get a Swing FAT client, whereas with ULCXML you get a ULC THIN client.
  6. As I said before, ULCXML uses the ULC library rather than Swing.
    Lets be clear here, ULC does uses JVM and Swing on client side. I guess you mean that ULC XML calls Swing wrapper library.
    The ULC library is a SERVER-SIDE proxy library to Swing. With SwixML you get a Swing FAT client, whereas with ULCXML you get a ULC THIN client.
    ULC requires JVM and Swing to be present on client side, and then we do not take advantages of our ability do delegate UI processing to client and optimize data exchange. Does not make much sense IMO. Java Web Start client application looks more appealing for the situation when we can require Swing capable JVM on client. Even Applet will be fine.
  7. Your are mixing up software distribution and architecture which are orthogonal aspects. Java Web Start or Applet do not define any architecture. Both a Swing fat client and the ULC rendering engine can be distributed via JWS or Applet. The primary questions for client-server applications (and I am not talking about stand-alone applications) is whether you would like to have a fat client or a thin client. Depending on the requirements and the infrastructure context you have to choose. A fat client is preferred if you really need the processing power of the client. Otherwise, a thin client leveraging the UI features of Swing has its advantages: 1) Presentation logic is executed on the server, i.e. it is a lot easier to call business services, deal with larger results etc. 2) ULC deals with optimizing the data transfer (round-trips, data volume) between client and server, e.g. caching, lazy loading, compression etc. 3) Security: Since the client is generic it reveals nothing about the inner workings of your application. 4) Less software to distribute, the client typically stays the same even if the application changes 5) Integration into a Web architecture where the state is managed on the server side is much easier, e.g. a ULC application can easily share the session state with a Servlet based application
  8. ... Both a Swing fat client and the ULC rendering engine can be distributed via JWS or Applet.
    Agreed
    .. a thin client leveraging the UI features of Swing has its advantages:
    1) Presentation logic is executed on the server, i.e. it is a lot easier to call business services, deal with larger results etc.
    Any proofs? Hessian or HttpInvoker allow to call server side logic with extreme ease and speed.
    2) ULC deals with optimizing the data transfer (round-trips, data volume) between client and server, e.g. caching, lazy loading, compression etc.
    Any comparisons? It looks like ULC should have higher volume of traffic than a slightly fattier 'traditional' Swing client because of ULC generic nature and necessity to transfer all the events. Also for bigger datasets ULS might not be beneficial at all, for example when a large dataset gets delivered on client (through paged transfer of course) then server memory is free and all the back and forth browsing, sorting, and filtering can be handled on client easily: http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#sorting
    3) Security: Since the client is generic it reveals nothing about the inner workings of your application.
    This one seems valid
    4) Less software to distribute, the client typically stays the same even if the application changes
    Perhaps, but with JWS it is almost is irrelevant, especially if 3rd party libs are externalized and do not get transfered over and over again.
    5) Integration into a Web architecture where the state is managed on the server side is much easier, e.g. a ULC application can easily share the session state with a Servlet based application
    Hessian and HttpInvoker, both can tap into session-scoped data easily since those protocols are handled by servlets. So, unless I missed or severely misunderstand something I do not see killer features to justify putting ULC layer atop of Swing.
  9. 1) The closer you are to the server the easier it is. just two examples: business services typically return much more data than you really need in the UI. It is easier to strip the data on the server rather than transmitting it to the client where you need 2 properties out of 200. Second example: handling caches in the server environment is a lot easier than keeping distributed caches among hundreds of clients coherent. 2) A fat client is more efficient regarding bandwidth only if you have a small data set which is rarely changed by other clients. Then you can work on this data set without using the wire. With large data sets which are changed frequently it is a different story. In addition, implementing all the lazy loading and cache invalidation is not really fun unless you are an infrastructure freak rather than intending to deliver business value. That's exactly the reason for ULC - enabling developers to deliver business value faster and cheaper. 3) Even with JWS it is not irrelevant. It takes quite some time to figure out a sensible granularity. Large libraries take some time to get downloaded, with many small libraries JWS takes ages with each start up to figure out what has changed. 4) State might be a shared cache of business services, which is just easier to handle locally rather than remotely. All I am saying is that ULC just provides some infrastructure which makes developing client-server apps easier in many cases. It's up to a developer whether she wants to develop infrastructure for a fat client or use ULC to realize more business value in less time.
  10. So, what are the real advantages over SwixML (if any)?
    ULC XML is not an alternative for using SwiXml: As Bruno Schaeffer mentioned ULC uses its own API. ULC XML is a way to create UIs (which are ULC and NOT Swing widgets) on the server side using an XML syntax. As described in ULC XML Essentials Guide the XML dialect used is quite similar to the one used with SwiXml and the main concepts of how the UI is generated is the same. Furthermore ULC XML offers some features that SwiXml doesn't: support of XMLSchema (to validate the XML files) and its extensibility (see ULC XML Extensions Guide for more information)
  11. I really like the idea of ULC, which finally leverage the ease and strength of JAVA to the RIA market and I am looking forward to test ULCXML to describe and generate some of the View (and having more time to concentrate on Model and Controller).
  12. I watch the development of ULC for more than a year now. I did not yet try it out in real programming, though. I believe that this technology/library is valuable at present time and has got a bright future. Actually, I was wondering why Sun doesn't come up with this kind of approach for thin Java clients. My questions regarding ULC XML are: 1. is the XML used internally to carry the information about the GUI-elements from server to client? 2. Which way of defining the GUI elements is preferable in terms of application performance? Or is the difference only marginal? Thanks, Marcus
  13. When I use the Applet version of the OnlineShop Example and scroll down the list on the right, all I see is a blank list... Until I stop scrolling and the content appears... Is this a bug? It's not the behavior I expect from a scroll-down list. That aside, I like the way the GUI looks and resizes properly to the page size. Reminds me of a flash app like Flex.
  14. Poor experience using FF 1.5.0.7[ Go to top ]

    I would shutter to think that our clients would enjoy the end result of using this tool. Running one of the demo applications as an applet. Gave my eyes shell shock. As the screen flashed with such frequency. I thought it was a strobe light application. I still have not seen anything which provides a better using experience than AJAX (Echo2) or OpenLaszlo. Personally I prefer Echo2. My 2%
  15. When I use the Applet version of the OnlineShop Example and scroll down the list on the right, all I see is a blank list... Until I stop scrolling and the content appears... Is this a bug? It's not the behavior I expect from a scroll-down list.
    This is not a bug. The table should be updated even if you don't stop scrolling. ULC uses lazy loading, i.e. it loads table rows on demand and then caches them on the client side. If the client side does not immediately receive the table rows it displays empty rows until the table rows arrive at the client. Depending on the responsiveness of the server, incl network bandwidth and latency, this may take longer. However, the user interface does not block.

  16. 1. is the XML used internally to carry the information about the GUI-elements from server to client?
    XML is only used to define the user interface. There is no XML used for transferring the user interface description from the server to the client. XML is way too inefficient for this task.

    2. Which way of defining the GUI elements is preferable in terms of application performance? Or is the difference only marginal?
    Creating the user interface via ULC XML is probably a little bit slower since the XML description has to be parsed before the GUI code can be executed. In a real live application this can be neglected in most cases.
  17. Does Canoo ULC support an off line mode? This would give it a distinct advantage over other rich client platforms.
  18. Does Canoo ULC support an off line mode? This would give it a distinct advantage over other rich client platforms.
    ULC supports offline mode, i.e. the client part and server part of the application can be run within the same VM. This is also how development is done. It is very handy if you don't have to deploy to a server to run your application. Deployment in a web development environment often means you have to restart the server, which is not really a productivity boost for developers.
  19. I find this library very interesting for people who already develop with ULC. Most of the time it is faster to specify the user interface using an XML file than with Java code. Not surprisingly for a 1.0 release ULC XML has a few rough edges (IMO) but is otherwise perfectly usable and I would encourage any ULC user to take a look. I think it improves an already good product.
  20. Not surprisingly for a 1.0 release ULC XML has a few rough edges (IMO) but is otherwise perfectly usable and I would encourage any ULC user to take a look. I think it improves an already good product.
    What are the "rough edges" you found? There is a new discussion forum on java.net (http://ulcxml.dev.java.net/) where you can report your experiences.
  21. Not surprisingly for a 1.0 release ULC XML has a few rough edges (IMO) but is otherwise perfectly usable and I would encourage any ULC user to take a look. I think it improves an already good product.
    What are the "rough edges" you found? There is a new discussion forum on java.net (http://ulcxml.dev.java.net/) where your experiences can be reported.
  22. What are the "rough edges" you found? There is a new discussion forum on java.net (http://ulcxml.dev.java.net/) where your experiences can be reported.
    Well, the very minor "rough edges" I've found are: several bugs in the teammembers sample that I don't know whether they are bugs in the sample or bugs in ULC XML (boxpaneconstraints and defaultbutton tags not working properly) and an awkward templating mechanism. I will follow your advice and report my experiences on the discussion forum as soon as I can.
  23. Are some of them still alive?