Millstone UI Library 3.0 Released


News: Millstone UI Library 3.0 Released

  1. Millstone UI Library 3.0 Released (40 messages)

    While everyone seems to be waiting for Java Server Faces, Millstone 3.0 released last week provides complete UI component framework utilizing XML and XSLT for terminal independency and themes. The library is released under LGPL-license.

    Check out Millstone at

    Press Release
    Millstone is a user interface library for development of networked Java applications. It provides a terminal independent component model that can be adapted to different terminal types and user interface themes.
    The development model of Millstone is closely related to traditional client side UI development: it has a continuous application lifecycle and an extensive event model. The Millstone library also provides an interface for directly connecting UI components to business logic and data storage.

    Millstone includes Web Adapter that is used for presenting applications utilising the Millstone base library on web browsers. The Web Adapter runs on a Java application server as a Servlet and is thus easily usable alongside other Servlets and JSP-pages.

    The Web Adapter includes a default theme that supports the most common web browsers, both with and without JavaScript. Adaptation of the Millstone UI components to the web includes theme generation with XML transformations, automatic form parameter mapping and dependency sorting of user invoked events. In addition to the traditionel HTTP page request model, server initiated events are supported by new web browsers using http-streams.

    Online demo and more information can be found at

    Threaded Messages (40)

  2. All the comments and/or questions would be appreciated. We (the development team) would be pleased to discuss any related topics on this message thread.
  3. Millstone UI Library 3.0 Released[ Go to top ]

    What is the relationship between Millstone UI library and Java Server Faces? Is it an implemention of Java Server Faces? or part of Java Server Faces? or not related at all?

    If I use Millstone right, will it be easily to migrate to JSF when it becomes available?
  4. Java Server Faces[ Go to top ]

    Millstone is not an implementation of JSF or related to it. IT Mill has been developing (and using) Millstone framework now for about two years. The developers got the first peek inside the JSF, when the public draft was released.

    Here is a brief summary on what is common in the frameworks and what is not:

    - Millstone is very XML-oriented: all the logical UI component can represent themselves in terminal independent UIDL language (XML). JSF relies on java-based renderkits. The implications are that building new themes in Millstone is easy with XSL when comparing to creating a renderkit implementation. On the other hand XSLT used in Web Adapter might be slower than a well implemented Renderkit.

    - JSF defines a strict request cycle, that is very transaction oriented. In millstone, component are independent of any transactions. A terminal adapter can "paint" any component tree whenevet they like to and also send event to any components whenever they want. Also the component changes can be listened. These features combined provide possibility of supporting both transactional UI (web, wap, ..) with the same components as continuous terminals (win32, gtk, swing, flash5, ..). Continuous interfaces are also applicaple to web-interfaces by utilising server-side events sent as javascript through http-stream. For demo, try out GO-game on

    - Currently millstone has larger set of available components, including tree, table, form, tabsheet and others. The features also include data binding interfaces that can be used to connect data sources directly to components. For example I have seen people connecting standard tree component trough hierarchical container model directly to IMAP mail server, NNTP news server and filesystem. On these applications tree reflected the data represented by the interface without any "glue"-code.

    - JSF can be embedded to JSP:s. Millstone does not support this yet. We hope to support this in future.

    In the future (when the JSF specification is published), we plan to support JSF in two ways: allow embedding JSF component to Millstone applications and to allow embedding Millstone components to JSF applications.
  5. This and similar frameworks makes me believe in a soon and inevitable failure of all attempts to use HTML/HTTP as a basis for creation of functionally rich and user-friendly clients.

    There is an ultimate need for a common (widely accepted) UI language (sort of XWindow dialect :) )

    XUL/TK look logical in this sense (SWT and Swing are too tied with Java).

    This framework seems using right ideology, but…
    There are some frameworks that use Swing or modeled after swing UI libraries to do same thing (that is good, because I may use my existing knowledge of Swing), but…

    Probably I will not try to use this and similar frameworks because of that ideological flaw (IMO).

    At this point, I am not sure that it is more difficult to create “native” GUI (Swing, Struts-JSP, etc), than study and use some common denominator with high probability of unknown future problems. If my main logic is on EJB layer I do not mind if my several UI implementations will have slightly different functionality (they should after all).

    Although I believe that is possible to come up with an abstract UI description, I am not convinced(yet) that this is the one, so I will continue to develop JavaWebStart based pure Swing applications as rich clients and use Struts+Tiles for browser-based front-ends.
  6. Feasibility of HTML UI[ Go to top ]

    I must fully agree that HTML is not designed for and thus is not best choise there is for UI. Unfortunately we do no live in idealistic word, and thus it might be the only choise. Also it would be nice to support both the web-ui and swing-based java-applet UI at the same time - through the same application.

    The basic reasoning behind Millstone is:
    - Users do have a wide range on different terminals that are incompatible with each other and have different capabilities
    - Users are not willing to install anything on their computers
    - Only way of creating easily maintenable programs with simple access to resources needed it to make the programs and UI on server side
    - Nobody wants (is able) to handle all the little details it takes to make the application compatible with many existing terminals (or even browsers - just look agent list in any popular sites logs).
    The solution is to create a logical UI component library (that it Millstone) that is easy to use, but is not "the lowest common denominator". The library provides simple clean API for functionality and terminal adapters do the dirty work of handling the protocols and terminal differences.

    Some of the reasons you disliked the HTML demo might be that it is currently fairly slow because of the heavy load on (the news were sent out today). Also the default theme might not be the lightest possible. It would be easy to create much simpler theme without any dhtml support, or complex CSS. We also expect to be able to optimize the XSLT process (through caching) a lot in the future.

    The reason why we did not just use Swing API for millstone, was that we wanted to create UI component library that is easier to use than swing, provides extensive data binding possibilities and can effectively be used in web-environments. We are quite happy with that decision - the result is easier to use than Swing and can be nicely representen on web.
  7. Feasibility of HTML UI[ Go to top ]

    Also it would be nice to support both the web-ui and swing-based java-applet UI at

    >the same time - through the same application.

    IMO: Quite opposite. I think that is a false goal that leads to “lowest common denominator”. I hope that it is possible to come up with an abstract UI description, that might be used for simplifying UI definition for rich client OR thin client. Not both in the same time. As I mentioned: My typical front-ends are different.

    Of course there might be a situation when it is possible to produce all types of clients from the same definition (“Hello World”: functionality may gradually degrade for some clients - joke). Right now compelling reasons to create “transactional/stateless” terminals with Swing/Flash: rich functionality (hot-keys etc.) and consistent behavior on different OS (if a client has a correct JVM). I think that kind of applications might use common definition for all “terminals” and functionality may gradually degrade.

    As I said, the framework uses healthy idea of an abstract widget definition. I am just not sure that level of abstraction is right. Sorry. (I want to preserve my investments in knowledge therefore there should be very compelling reasons for me to study/use something).

    About examples: their slowness is not a problem at all, they just look like another web demo with some source. It would be mush more interesting if you will publish side-by-side code/demo for different terminals. So I would be able to compare your code with code I would have to create with using native “terminal” library Swing/Jsp for instance (Flash, win32, etc).

    I have created a simple demo that uses one EJB backend and 3 different frontends: Swing/Struts+Tiles(jsp)/Struts+Velocity in a simple CRUD+S scenario. That allows side-by-side comparison of using different approaches for the same use case. Sometimes very informal (personal syntax, background, debugging, etc. preferences)

    I would like to see something similar done with your/other frameworks.
  8. Feasibility of HTML UI[ Go to top ]

    Keeping UI description simple and on _logical_ level can help avoiding the "lowest common demonimator"-symphom that can be found in most multiterminal solutions. For example, this might allow use of semi-dynamical DHTML tree (from the default theme) in simple applications, as the programmer does not need any knowledge on DHTML. Without simple UI representation this would not be possible.

    Still in some cases it might require some addiotional work to support the most simple terminals. For example: The mp3-player demo we have online uses multiple frames and automatic frame window updates. We wanted to demonstrate a prototype adapter for wap-phones (at HP Bazaar spring camp, Helsinki). What needed to be done was a simple controller window for small screen terminals. By adding just few (2 or 3) lines of code we created new window with special url and put duplicate of control buttons on that window. That allowed us to control Millstone-based MP3-jukebox both on wap-phone (only change songs on phone) and from web (full interface). Still the application programmer managed to enable the support without any knowledge of WML.

    Currently we do not have adapter for swing or flash. I hope that in future, when such adapters are ready, it would only require one application that would run on them all. On web this would require page reloads, but on swing all the events are sent immediately and only parts of the interface needing repain are repainted. In fact we created a simple prototype adapter for J2ME phones that consisted of two parts: 1) serverside adapter sending UIDL directly to phone and 2) Midlet on phone that interpreted UIDL and viewed it using native widgets. This worked fairly well with mp3-player demo and other simple demos. Unfortunately the prototype Nokia 6310i did not support http streaming too well and the demo worked well only on Jordanas (with HP J2ME environment) and emulators...

    BTW: Where could I see your demo, it would be interesting to study it?
  9. Feasibility of HTML UI[ Go to top ]

    Where could I see your demo, it would be interesting to study it?

    I did not publish it yet (I use it internally), although I am going to do it soon (there are plans to present that for local JUG in January). Write on my email: kgignatyev at yahoo dot com and I will send the project in its current stage and/or notify when the example will be published.
  10. Feasibility of HTML UI[ Go to top ]

    Very impressive peace of work and seems to be more thought out than many other (incl. struts). You may want to script all this with jelly (remains xml, and reduces coding).
  11. Feasibility of HTML UI[ Go to top ]

    Agree. Impressive. But I am so concerned about XML/XSLT processing…. That beast is a performance killer. My bitter experience with a simple XSLT servlet:

    If MyWebServer works on JVM 1 then result looks like this:
    12/06 12:26:34 info (MyWebServer) reportServlet: SQL request + conversion into DOM took:563 ms
    XSLT took: 1922 ms
    Totat time on server: -2485 ms

    If MyWebServer works on JVM 2 then result looks like this:

    12/06 12:24:20 info (MyWebServer) reportServlet: SQL request + conversion into DOM took:1015 ms
    XSLT took: 10563 ms
    Totat time on server: -11578 ms

    average times under load test: 20 seconds for JVM1 and 70! Seconds for JVM2.

    No changes were made, except switching the JVM (xml/xslt are the same: configured via Djavax.xml properties ).

    Not to mention that XSLT took no time with C XSLT processor.

    PS: I do not disclose exact versions and products intentionally. I just share my “bitter” XML/XSLT experience.

    PS2: Struts has(had) less ambitious goals, and possible it is not the best but reasonable good, and somehow trusted(?) framework. Every time I see something new I would like to see what are its advantages over existing frameworks.
  12. XSLT[ Go to top ]

    XSLT is can be slow, unfortunately. What transformer you are using? We have found that Xalan distributed with Sun J2SDK 1.4.1_01 can be very slow when comparing to other transformers. Some comparisons done with XSLT profiler between Xalan and Saxon show 1:20 ratio in performance for some operations.

    Fortunately XSLT seems to be maturing (becoming order of magnitude faster than the first versions) and the servers are getting faster. Power of the XSL-model for doing XML transforms is inevitable and I would guess that the acceptance of XSLT will be growing rapidly.

    BTW: Millstone 3.0.0 uses Xalan by default. We'll be including option for selecting the XSLT implemention in version 3.0.1. examples are using Saxon currently because of the speed.
  13. XSLT[ Go to top ]

    XSLT is can be slow, unfortunately. What transformer you are using? We have found that Xalan distributed with Sun J2SDK 1.4.1_01 can be very slow when comparing to other transformers. Some comparisons done with XSLT profiler between Xalan and Saxon show 1:20 ratio in performance for some operations.

    Fortunately XSLT seems to be maturing (becoming order of magnitude faster than the first versions) and the servers are getting faster. Power of the XSL-model for doing XML transforms is inevitable and I would guess that the acceptance of XSLT will be growing rapidly.

    BTW: Millstone 3.0.0 uses Xalan by default. We'll be including option for selecting the XSLT implemention in version 3.0.1. examples are using Saxon currently because of the speed.
  14. User Guider[ Go to top ]

    Do you have some kind of user or programmer's guide?

  15. User Guider[ Go to top ]

    Millstone manual is under construction. Before it will be released, beginners should go trough installation tutorials and examples on the site. Simpler examples should be easy to read and give overview of the techniques. API-documentation contains also some introductory material on package documentations that might help.
  16. XSLT[ Go to top ]

    In both cases the same XML/XSLT processors were used via JAXP API. I believe that difference is because of JVM only. In both cases default XML/XSLT configuration was NOT used, but JAXP was configured with exact the same values for parameters javax.xml.transform.TransformerFactory
    , javax.xml.parsers.DocumentBuilderFactory etc.. In my case cache cannot be used because it is a dynamic report and every transformation is unique.

    BTW: XML/XSLT performance is a topic for a separate discussion and I hope Bruce Tate and Co will tell about similar issues in the upcoming book “Bitter XML”. Hope that book will help to prevent XML/XSLT overuse.
  17. Feasibility of HTML UI[ Go to top ]

    XSLT engines use their own document model, so it is a worst case scenario for them getting a DOM for input. They prefer flat files or SAX events.

    XSLT frameworks use caching for most pages that they serve. So, transformation is frequently a onetime cost (like JSP compile).
  18. XUL and Millstone[ Go to top ]

    As I am not too familiar with XUL, I have to ask how difficult it would be to send XUL to standard Mozilla browser from server and to receive UI events back through continuous http-connection? If this is possible, it would be very interesting project to create an adapter for representing Millstone applications on Mozilla using XUL. This should be fairly straightforward as the UIDL to XUL conversion could be (probably) done using XSLT and the event firing mechanism might be copied from Web Adapter.

    BTW: You might want to browse the UIDL specification (currently documented in DTD comments). It might be what you are looking for.
  19. Millstone[ Go to top ]

    Interesting, I like the general style. One problem I noticed is that the standard DHTML problem of trying to show layers over combos. Click on the Textfield demo and go to the second tab. Click one of the "i" round buttons near a combo and the popup comes up under the combo.
  20. DHTML layers bug[ Go to top ]

    The layers bug in Default-theme. It seems that the conserns to all variants of IE, Netscape 4.x series and at least konqueror 3.1. Mozilla seems to work well. The problem is with the browsers, and I think that there is only two ways around it:
    1) Avoid using layers
    2) Avoid using components whose z-index can not be controlled (dropdown).

    Probably the cleanest solution would be to implement select fully with DHTML (with layers) when the user uses IE and doesn't use the layers with other broken browsers. With millstone this kind of pathes to avoid browser probles are fairly simple. To see an example, try to turn javascript support of from your browser and then retry the features demo.

    Btw: If you find any other bugs, please report them with
  21. DHTML layers bug[ Go to top ]

    1) Avoid using layers

    >2) Avoid using components whose z-index can not be controlled (dropdown).

    You can solve it with JavaScript. See for example
    Each tab has own listbox. This application uses Tab taglib from Coldtags suite:
  22. DHTML layers bug[ Go to top ]

    I skimmed through the javascript source code. It seems to me that it does not use z-indexes, but just hides the divs containing selects. As the visibility-property is inherited from parent, the selects on tabs are hidden, not below other layers.

    Unfortunately this solution does not apply to floating layers as it would be unacceptable (and fairly complicated) to hide all the selects from page while there is a layer visible.
  23. Popup issue[ Go to top ]

    This is not a DHTML issue, it's an IE issue. The problem doesn't exist with recent versions of the Mozilla family of browsers.

    Now if MS would just get the message and rebuild their 800lb gorilla from scratch (like Netscape realized they had to do), then maybe we'd finally have truly usable DHTML and not have to continuously be testing every little piece of JavaScript in 15 different browsers....

    You can't believe how many service calls our web help desk gets due to problems with *very* specific builds of IE...
  24. XUL and Millstone[ Go to top ]

    As I am not too familiar with XUL

    That is really surprising comment. I expected detailed comparison/critique/explanation of place of the technology in your framework.

    I do not claim that I am familiar with XUL. I would prefer a comparison with TK, my understanding that XUL utilizes the same idea as TK. And I agree with that approach 100%, when Swing to HTML/WAP mapping seems flawed for me.

    Although, “Mapping of Swing API to something else” approach looks more beneficial for me, because of my familiarity with the API, its maturity (arguable), and some degree of trust.

    I do not assume that Swing is the best API possible, but it looks like as a reasonable balance between simplicity and flexibility, and has straightforward architecture.

    Please, do not take me wrong. I am not trying to say that Millstone is totally bad and wrong; I just express my concerns and think others may have similar ones.

    I am looking for UI technology to study, it might be Millstone; I just need enough information. I might misunderstand something.
  25. Millstone UI Library 3.0 Released[ Go to top ]

    Ok, I'm starting the betting pool now. How long before we get a Tapestry post here? :)
  26. Millstone UI Library 3.0 Released[ Go to top ]

    Zero seconds after *your* post. I thought bear-baiting died in the middle ages?
  27. was that all? I thought you'd have more to say. Not the standard plug, but an (ideally) informed comparison of features and concepts would be helpful.

    The WebFW landscape can get quite confusing these days.

  28. Millstone/ Tapestry[ Go to top ]

    Haven't had time to look at Millstone in detail ... I'm a little too busy cooking amazing new features into Tapestry right now.
  29. Trying out Millstone[ Go to top ]

    Quick disclaimer: I'm an employee of IT Mill Ltd., but not actively participating in development or design of Millstone.

    To get my hands dirty with Millstone I wrote a ultra-simple news reader application with it. When I begun I had no experience with Millstone outside of browsing the examples, nor did I have any deep insights on its inner workings or requirements.

    Basically what I did was take the source of a few of the example applications and started to hack them to suit my idea what the application would do. I discovered many things in the process, but one thing didn't go as I anticipated - most of my time went in implementing the containers for newsgroups and articles, and not in the UI. In fact, creating simple the user interface (which works a bit like the news reader in Mozilla) was probably the fastest job after I had figured out the basic concepts. Much more time went for example in implementing a quick and dirty NNTP wrapper class - and I'm very simple class here, it only supports five NNTP commands. Basically, initializing the UI consists basically just of creating the appropriate objects and combining them into other objects to create the desired hierarchy. Support for event handling was even more trivial, just register a few functions to listen the appropriate events, each function less than 15 lines of code.

    The most cumbersome Millstone-related task was to implement the Millstone Datalayer-specific hierarchical containers that are required by the tree component. The API is clean and simple, but to implement all required functionalities took some time because I had to figure it all out first. In the end, though, almost all functions turned out to be trivial, constructors taking most space because of member initialization. Hindsight tells me that the containers could probably be with a lot less work, even maybe use the general container implementations provided in the package, but I did take the "hard way" deliberately as my primary goal was to explore Millstone.

    All in all, I was surprised how easily how it all fell together and how good it looks, even though I used defaults for everything relating to look and feel. And I'm not very experienced in UI programming either. I'm confident that now that I have some degree of familiarity with the framework and the basic concepts, I could write a similar application in just a couple of hours from scratch.

    The application will be available with source from the Millstone website ( later.

    Henri Muurimaa
  30. Millstone UI Library 3.0 Released[ Go to top ]

    Not bad, but I am not sure about the XML/XSLT stuff. In general, I think the main challenge for any programming model in the Java Web UI world is that it must support Rapid Prototyping/Application development. Unfortunately a lot of frameworks on the market do just the opposite, making it very hard to accomplish acceptable time to market.

    We noted that some time before and started development of the iternum ui framework (preview at Our first full blown project that made use of this framework is (until end of december in german only). This is mainly an online diabetes diary that has been solely built based on iternum ui.

    Also, I am almost sure that trying to define a UI using some high level abstraction is futile. It has failed multiple times before, mainly because it introduces an obsolete layer in the application for the vast majority of projects. Also about 40% of any UI is high level custom interaction of components, component aggregation and the like. I am quite sure that the overhead to push that in the abstract definition layer is enormous, while on the other it is necessary to add meaning.

    Also the challenge is not to define but to be able to *adapt* quickly.

    Regards, Karl
  31. Rapid application development[ Go to top ]

    I must say that the greatest challenge of creating a good UI framework is to support different programming models and programmers with different experience and background. With Millstone, we did have a (long and painfull) process of trial and error. We rewrote and (party) redesigned the whole framework three times and after each cycle used it for creation of production applications. The programmers using the framework did have very heterogenous UI backgrounds: we had programmers with Swing, Delphi, Perl, PHP3, Visual Basic UI-experience and everybody did have a bit different expectations how the UI should work. It seems that most of the needs are now satisfied and we have found a good balance between features.

    A good example of evolution is a simple text field. In the beginning the name has changed multiple times, but in the beginning it was an UI Automata (a bit too academic, isn't it ;)) that required connection to persistent data object. The connection provided the Field with data and reflected the data to underlying data storage (proprietary centrally cached data management system sitting between JDBC and UI). This was idealistic and worked quite well, but was complicated to learn (all the concepts) and did use proprietary technology when there existed an industry standard solution (EJB:s). In the next generation the persistency system was dropped and the concept of UI Automatas was renamed to UI components. Still the data-binding was the preferred way of using textfield. For simple cases this was an overkill and also required too much learning.

    In Millstone 3 TextField implements the datamodel by itself - it provides general data property functionality like get/setValue() directly, provides optional data binding and buffering support. Also the data model was applied to all components to that you can expect to find the same methods from the most components with the same names, which really makes learning faster.
  32. Millstone UI Library 3.0 Released[ Go to top ]


    Your iternum framework looks very well-designed, I've taken a peek at it from time to time since you posted it on your site.

    I still don't see any information about licensing. You once told me by e-mail that you hadn't decided yet how to license it. Is this still so?

    Millstone is LGPL, which is great. It takes a bit of investment to learn a new framework, benchmark it, and put it through its paces. I find it hard to justify the effort if the licensing isn't workable.
  33. Themes?[ Go to top ]

    The themes/skinnable UI aspect sounds interesting, but I didn't see anything in the online demos illustrating this feature. Did I miss it, or is it something that requires a download/install to try out?
  34. Themes?[ Go to top ]

    Currently there is no other themes available for download, sorry. We try to put some other themes available soon (we have created quite a few themes, but most of them are either part of some client project or incomplete). Creating themes is simple, but creating a theme that supports most browsers and all styles is complicated process as allways with DHTML and multiterminal support.

    If you want to experiment with themes, the easiest way of creating a custom theme is to:
    - Create a new theme by extending Default theme (see go-game and stoneplayer examples)
    - Replace CSS
    - Override any templates you want to

    The document to look at is surely the UIDL.DTD.
  35. Themes?[ Go to top ]

    Thanks, Joonas. Your graphic designers are quite good, so I imagine some mileage could be gained simply by tweaking the CSS to change fonts, colors, and the like.

    Although "skinnability" is often listed as a feature of Java Web frameworks, very few supply any meaningful library of themes. I'm sure it's because the developers are programmers, not designers. This situation is much different from, say, the many open-source PHP projects (forums, etc.) which offer dozens of really attractive themes.

    Anyway, if your designers create at least a handful of themes, or if users contribute themes back, I think that would be an impressive thing to add to your demo.
  36. Themes?[ Go to top ]

    I am an employee of IT Mill, and have thus had the opportunity to try out Millstone both at work and at home.

    One of the things I decided to try at home was to create a new theme -- I had an idea for a 'completely new' look & feel and decided to give it a go. Here are some thoughts on Millstone 'theming':

    Since you can extend & override, it's very easy to get started on a new theme -- just extend an existing theme, and start implementing one component at a time. This makes the task less intimidating. This also makes it easy to customize the look & feel of a particular application, which is the main idea with 'themeability'. For instance, the programmer might use multiple levels of tabsheets, but since the usability engineer thinks this is bad UI design, he can change one tabsheet so that it looks like a menu without touching the java code (it's still a tabsheet component, but looks like a menu).

    However, if you are looking to implement a _complete_ theme, you'll have to do a fair amount of work to support all features of every component. This is the reason why 'my' theme is not yet ready, and the main reason why there is only one official theme available -- the one complete theme allows theme developers to extend and/or copy&paste the tricky parts.

    The availability of more themes from day one would of course have illustrated this interesting feature better, and I'm sure we'll have new themes available shortly. In the mean time, I think I'll screenshot my theme to illustrate the possibilities :-)
  37. Themes?[ Go to top ]

    I took some screenshots and put them up on a temporary page at

    Just some basic theming examples so far, but I'm sure we'll see some very interesting solutions in the future.
  38. Themes?[ Go to top ]

    One way to demonstrate the theme-support right online is to try to turn off JavaScript support from web-browser, to simulate older browser, and try feature demo. Millstone only detects browser capabilities once per session, so you might want to restart browser to flush the session.

    Adventurous testers might event want to try feature-demo with very limited web-browser like lynx. :)

    You will notice that different terminals are given very different input from the same application. The application itself does not have to know about the browser - web adapter handles the detection and theme provides browser support.
  39. Millstone UI Library 3.0 Released[ Go to top ]

    it looks like a great framework. Even better, that its released under the LGPL.

    I am thinking about starting web application development, and this seems for me the way to go.

    One question I have is, how well does your application model scale? As I understood, for every new request a whole application is made in the VM. Doesn't this approach use a lot of memory if there is much of content? How much time do your transformations take?
    Is it only possible to define the colors of components/background by theming?

    Will you try to make a PetStore application, which can be benchmarked against other frameworks?

    Will you add a selector to your table component which allows to choose the desired range directly?

    Looking forward to read a lot of documentation that you still have to produce.
  40. Millstone UI Library 3.0 Released[ Go to top ]

    One question I have is, how well does your application model scale?

    The application UI components are kept in server memory (in session). This allows better programming model than many other frameworks, but also consumes memory. Fortunately UI components themselves do not require too much memory. Althought this programming model is much easier than request based one, the programmers must remember not to keep large data-object in memory for each application separately.

    Transformations take a lot of time. Unfortunately. 90% of the time in FeatureBrowser example application is spent in Xalan on complicated pages. Fortunately other XSLT processors are much faster. By using Saxon 7 with Millstone, the the same application is allmost three times faster. Millstone bugfix release 3.0.1 due tomorrow fixes some minor gliches and is tested with Saxon 7.3.

    > Is it only possible to define the colors of components/background by theming?

    Yes. Millstone UI components are logical level components. UI formatting is done (mostly) with themes. Fortunately simple formatting is very strightforward just CSS. Easiest way is to create a theme that extends default theme and only includes a CSS file that replaces the default.

    > Will you try to make a PetStore application, which can be benchmarked against other frameworks?

    We have thought about it, but have not yet scheduled this. There is more important tast in the todo before it. (Like the Millstone programmers manual).

    > Will you add a selector to your table component which allows to choose the desired range directly?

    Could you be a bit more specific? Multi-selection is fully supported. Try to turn Multi-select and Selectable properties on in Feature Browser / UI / Table for demonstration. You can even use multi-page table feature at the same time with selection.

    > Looking forward to read a lot of documentation that you still have to produce.

    Me too :) Working on it.
  41. For those of you have been testing the performance of Millstone, 3.0.1 version (available now from adds support for Saxon 7, that is a lot faster than Xalan bundled with Sun J2SDK 1.4.1. Some parts of the feature browser demonstration are three times faster!