Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Java Web App Framework Millstone 3.0 Released 51

Posted by timothy from the don't-put-it-around-your-neck dept.
idot writes "Millstone 3.0 is a java LGPLed library for the development of networked applications. The developer doesn't have to deal with HTML or individual pages, but rather writes a very swing like continous client application. A terminal adapter converts the abstract UI together with a Java Servlet container to the desired themed client side code. In case of Web applications HTML complete with or without JavaScript. Press release millstone home page complex go example game It seems to be a very mature framework, whose first two iterations were used only internally by the developers. It will be interesting to test this library against JSF, tapestry etc. in terms of developer usability and scalability."
This discussion has been archived. No new comments can be posted.

Java Web App Framework Millstone 3.0 Released More

Java Web App Framework Millstone 3.0 Released

Comments Filter:

  • Millstone (Score:3, Funny)

    by Anonymous Coward on Thursday December 12, 2002 @07:22PM (#4876013)
    is actually meant to be a library destroyer, and has been a staple of control players for years.
  • This seems quite similar to echo [nextapp.com] which is getting close to reaching 1.0. Can anyone comment as to how the two compare?
    • Millstone does not seam as feature rich. I have downloaded it and after looking at a few classes for some of the features I love in echo I find it lacking for example Button There appears to be no rollover support. It seams that Millstone is a reasonable framework, but I feel that it compares better to AWT then swing where ECHO compares to SWING.
      • Thanks for the tip.
        Now I will have something to play around with over the holidays.

        On the one hand, competition is good. On the other ... I hope somebody will post a comparison of the various frameworks.

        Create two, three many petstores!

      • The philosophy of Echo and Millstone are quite different from each other: Echo components include their representation (fonts, colors, rollover efect...). In Millstone all the components are representation independent. The representation is given in adapter (and in web adapters case in web adapter theme).

        Using rollover (as well as any other visual efects) in Millstone applications is specified with styles: Just do button.setStyle("rollover") and define "rollover" style as you wish in CSS. If you are just using (extending) the default theme you can do this by adding .button-rollover class definition. You can freely add any CSS style specifications (fonts, colors, layouting, backgrounds, ...). If you want to do more advanced things (DHTML animations, popups, scripted client side logic, sound, ...) you can easily add new button template for your style in theme XSL.

        To summarize: in Echo it is easier to turn on limited roll-over effects by the programmer. In Millstone theme designer (not necessarily the programmer) can freely add any visual effects supported by the browsers.

      • First a disclaimer: I am one of the head developers of Millstone and CEO of the company [itmill.com] behind it.

        I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo [millstone.org] (also available for download [sourceforge.net]) and Echo Test application [nextapp.com]. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

        Still Echo is very nice framework and provides good competition for Millstone. I hope that the both frameworks gain popularity.

        • I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo [millstone.org] (also available for download [sourceforge.net]) and Echo Test application [nextapp.com]. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

          I am the lead developer of Echo [nextapp.com]. I am therefore, by definition, not qualified to make an unbiased comparison between Millstone and Echo. An analysis by a developer of either product will be flawed because that developer will be significantly more familiar with his/her own product than that of another. Such a developer also has an interest in seeing a particular outcome to any comparison.

          That said, I do feel the need to set a few things right. First of all, to perform a feature-for-feature comparison between Millstone and Echo, one also needs to consider EchoPoint. EchoPoint is an LGPL licensed collection of Echo components. It includes features such as the mentioned server-side event generation and a large collection of user-interface components including trees. For more information about these components, visit http://echopoint.sourceforge.net [sourceforge.net], or specifically http://echopoint.sourceforge.net/LinkedArticles/Us ingEchoPointComponents.html [sourceforge.net]. Also, please note that the TestForEcho application is not intended as a demo. TestForEcho is maintained only as an interactive test application for the framework, and as such, its aesthetics and demonstrative capabilities are quite limited.

          As far as the data-binding issue goes, I am not aware of how Millstone distinguishes itself from Echo. Both frameworks use an architecture where data is decoupled from the components themselves, such that developers are not required to create code to update the state of components when their represented data changes.

          In the case of XSL stylesheet-baesd themes, you are correct that Echo does not provide this capability in this manner. The reason we have not pursued this course is architectural: Echo goes about rendering the HTML and JavaScript representations of components using Java-based renderers, which take into account the eccentricities of different Web browsers to ensure consistent output. Look-and-feel definition is handled on the "component-side" of the framework, rather than the "rendering-side." Should one desire to fully externalize L&F information, the EchoPoint project provides a package to do so by placing such data into cascading-style-sheet-like resources.

          One thing everyone needs to bear in mind when considering Echo or making comparisons against it is that it has been developed for the creation of Web-based applications, not for the creation of Web pages. The term "Web application" is often gratuitously used to describe the spectrum of software between a feedback form and an online banking system. Echo is intended for the latter portion of this spectrum. It was built to offer capabilities previously only available to rich-client (desktop-based) interfaces.

          In order to offer a level of capability approaching that of rich-clients, Echo includes features which are to the best of my knowledge not available from any other framework. Echo provides a client-side state management engine, written as a series of cross-browser JavaScript modules which serve to synchronize the state of the client browser with that of the server-side application. This engine is capable of managing multiple browser windows with a degree of control that is far beyond what one would expect from a Web application framework. Echo makes use of a hidden "controller" frame in each browser window to transparently communicate the state of the client to the server, and to allow the server to issue directives back to the client without re-rendering unchanged resources. While my description of these features unfortunately must be quite technical, the real benefit of them is a user and developer experience not unlike that seen with a rich-client interface.

          Please understand that my comments are in no way intended to flame or otherwise deride the Millstone framework. I wish you folks nothing but the best.

          Best regards
          • Echopoint looks very interesting and comprehensive collection of components. With compatible lisence (LGPL) it might event be possible to port some of the components to Millstone.

            So to summarize comparison discussion, there is some philosophical (and architectural) differences in the design of the both frameworks. I wish that the both frameworks will find their audiences in the applications they are most suited for.
  • Is gonna love this. *sigh* More work for me... ;)
  • It uses swing-like api and it doesn't has any overhead with pure java applet.

    My friend who is a financial content provider which distribute information with the help of java applets. They just stuck with the problem with XP which does not come with Java support, which is very bad for their business because their users usually don't know(or don't want) to download and install a JRE. Let's see if it can help him.

  • once again... (Score:1, Troll)

    by tongue ( 30814 )
    the slashvertisements strike again.
  • Millstone: A heavy weight; a burden: "This job is a millstone around my neck."
    • aye, as if Sun(tm) Java(tm) did not already have enough baggage. java needs many things, but Yet Another Framework or TLA (YAFTLA) is not one of them.
    • Lol, good irony indeed, yet the real etymology of the name, is the name of our company that created it, IT Mill Ltd. [itmill.com]

      Miq
    • You know, not all Millstones are not bad. For example, there is the Official Beverage [millstone.com] of IT Mill ltd., which is quite good :)

      Note: The Millstone-the-UI-library lives in http://www.millstone.org [millstone.org], millstone.com is about something completely different.
    • In fact the name was meant to describe a stable core that is spinning inside the mill [itmill.com] (Millstone was targeted to be internal tool in the beginning). Anyway - blame me, as I was the one who came up with that name...
      • Okay, consider yourself blamed. Surely you were aware of the irony when you chose that name?

        -- Brian
        • The product naming would not be taken so seriously. But on the API the good naming is very important. Everybody in IT Mill liked the name and still do.

          One related naming issue: we first (in year 2000) called UI-components UI-automatas (UIA) to describe that they contain a state that is changed by sending events to them. Fortunately after the 1.0 we realized that this would be far to academic sounding and decided to rename. One of the name candidates was grain to follow the spirit of mill and millstone as well as Java beans :)

  • The on-line demo / example pages do not appear to work without cookies. Sorry, thank you for playing! One of the cardinal rules of a good general purpose web app framework is that it should not require cookies to work. It may be that the framework itself does not require cookies. If so, it was a poor decision to write demos that do. Oh well. Next player, please!

    • You know... cookies are not all that bad, once you get to know them. ;)

      Seriously though, the framework, although apparently developed like swing, still outputs HTML and Applets to a browser. Cookies are a valid method of transferring state from one page to the next, although admittedly server-side session tracking is usually a better alternative.
      • Cookies are a valid method of transferring state from one page to the next, although admittedly server-side session tracking is usually a better alternative.

        Uhm, and how does the server know which session he stores belongs to which request?

        Yes, right, either cookies hold this information, or the URI, via mangling the displayed links.
        If you use session cookies, the two are equivalent privacy wise, it's just that cookies are is far more robust than link rewriting, because the latter can break in a plenty of ways.

        • Hey, you're preaching to the choir man! I have no problems with cookies whatsoever. I love 'em. 'Specially with milk. Server-side session tracking *is* the better alternative to cookies, however, if only because of the limit on cookie data. If you have a complex list of user-definable options in your website (as is increasingly the case of late) or a potentially large amount of data you need to transfer from page to page (say a shopping cart), then this can be a problem.
    • Base Library does not depend on cookies, but the Web Adapter uses cookies for session support. Adding support for URL re-encoding to avoid cookies might be added in future [millstone.org].
  • Explain why you'd intentionally make something swing-like. You don't program swing, you fight swing. You fight it with your teeth and nails. Then it decides to resize your button, and you just give up.
    • Aaah, but we only took the good bits :)

      None of that pesky relational sizings and layouts to size contained components that *never* works like you expect or even, intend.

      Miq
    • Fully agreed.

      Millstone is not designed to be Swing-like. Millstone API has been designed from ground up to easier to learn and use than Swing. Using Swing API directly was one of the options (easy one), but we decided not to follow it and to create API better suited for multiterminal environment and easier to use instead.
  • If anybody is interested, here is my take on the current state of web development and how to make it more client/server-like (Delphi/VB/PB) from a developer's perspective.

    [geocities.com]
    http://geocities.com/tablizer/webstif.htm

  • Clever but possibly misguided (Score:3, Interesting)

    by vbweenie ( 587927 ) <dominic,fox1&ntlworld,com> on Friday December 13, 2002 @05:46AM (#4879024) Homepage

    If a calculator app which has to make round trips to the server every time you press a button is meant to be a representative demo of this application, then my response has to be: no thanks.

    I tried a couple of other demos on the site, like the treeview control which seemed to need to go off to the server every time you expanded a node. Responsiveness is a key issue in usability: anything slower than PDQ (Pretty Damn Quick) ramps up the end-user's frustration levels and makes the interface feel clunky and hostile rather than intuitive and friendly. All of the stuff on their site looked great, but it handled like a pig in treacle.

    Maybe they're suffering a slashdotting right now, but that actually doesn't excuse them: if the responsivity of individual elements of your user interface depends on the responsivity of your servers, then the usability of your site is - to my mind - unacceptably fragile.

    Is it possible that the developers used this primarily on a small LAN or even spent their time pointing a browser at localhost, and never considered how it would feel to be using it over the web? Surely they must have load-tested it? Surely they must have thought, "hmmm, so that's why client-side scripting was invented"?

    • Misguided not. It would have been possible to create an entirely client-side calculator-app that would be fast as lightning, yet this is not what Millstone is for. I'll conceed that the Calc-app is perhaps a bad example-app as it brings forth sentiments like this. It is only intended to demonstrate and tutor the usage of Millstone, and not, in this case, it's power.

      One important aspect of Millstone is that the presentation of an app is separated from the underlying logic. This means that once adapters have been made for different terminals, that same Calculator app, without so much as one line of code changed, will work on your cell-phone, digi-tv and terminals that aren't even imagined yet.

      As to the responsiveness of the example application, I'd like to point out that it's running on a single server sitting in the room next to me, in Finland ... so you're bound to get some netlag if your surfing in from the states. Regarding the /. :ing as an excuse, it is if we never really believed that we'd get on here. :)

      Realistically, we're too small to make mega $ hardware investments in preparation for high demand, we just have to wait for that demand to realize itself and then respond to it.

      Further discussion regarding the speed and efficiency of the ui transformation process can be found in the serverside.com thread. [theserverside.com]

      Regards,
      Peter Bäck

      • I still have my doubts about the whole approach, but this is to some extent an ideological issue (HTTP/HTML for complex real-time client-server interaction just feels wrong to me) so basta for now.

        The promise of multi-channelling GUI components is an alluring one, and Millstone is certainly impressive in its use of HTML/CSS/Javascript as a rendering target. Presumably having abstracted to that level you could retarget the renderer at an SVG or XSL:FO browser?

        • vbwwneie wrote:
          The promise of multi-channelling GUI components is an alluring one, and Millstone is certainly impressive in its use of HTML/CSS/Javascript as a rendering target. Presumably having abstracted to that level you could retarget the renderer at an SVG or XSL:FO browser?

          Certainly! To clarify, a Millstone renderer is what we call a Terminal Adapters; an adapters recieves from the appliation an XML representation (that we call UIDL, User Interface Description Language) of the state of each component and translates this XML into whatever the terminal can understand and maintains a map of terminal varibles (content of text-fields, state of checkboxes, etc). In the asynchronous Web-Adapter case, the adapter waits for the terminal to send back the updated set of variables that are then passed back to the application for handling.

          However, the terminal may also be synchronous, in that case there will be a continuous stream of variables from the terminal->adapter->application and a continuous stream of UIDL from application->adapter->terminal.

          Some of the envisioned terminals are Flash (ofcourse), MIDP (almost implemented), Digi-TV, and my personal pet-project of creating a Win32 native adapter per use of the Eclipse widgets.

          As it happends, HTTP/HTML is actually one the hardest terminals to implement because of the inherent statelessness of HTTP (and the erratic behaviour of HTML browers.. :p ). Many other adapters are (in theory) much easier to implement.

          Hope that cleared some things up.

          Greets,
          Peter

        • I still have my doubts about the whole approach, but this is to some extent an ideological issue (HTTP/HTML for complex real-time client-server interaction just feels wrong to me) so basta for now.

          You're not the only one who has doubts about this approach.

          Because everything old is new again, many companies are starting to build hybrid J2EE systems which have a Swing GUI as a front-end instead of a broswers. The advantage is (over traditional client-server) that you can have the scalability and transaction-safe benefits of J2EE on the server, but the fast responsiveness and better UI of a GUI on the client. (As well, you can still create purely serverside applications where it's appropriate and reuse the same infrastructure.) It's far fewer roundtrips, since the client only needs to pull or commit data from the server, but can perform all the interim data manipulation and UI work client-side.

          To extend your calculator example, imagine a mortgage calculator in a bank branch. The calculator would only need to talk to the server when the bank employee pulls up your customer data, or commits any changes. However, before making changes, you as the customer might want to see how much faster you could pay off the mortgage if you increased your payments, or put in a bigger down payment, or tried a different interest rate plan, etc. All of that should be calculated client-side -- there's very little need to make several server roundtrips for these temporary calculations.

          As well, the bank could use that same back-end infrastructure to set up a website to allow you as the customer to check the status of your mortgage and your payments. Customers wouldn't be the same kind of power-user that the bank employee would be, so the number of roundtrips is somewhat less of a problem -- as well, the web version could be a simplified version of the GUI version.

          Sun has actually addressed this (they sometimes call this architecture rich-client J2EE) through the JNLP spec and its reference implementatation, Java Web Start. Personally, I think JWS itself has limited use, but the architecture of the rich-client system is nonetheless pretty sound.

          DISCLAIMER: I haven't looked at Millstone. I have spent a lot of time with these hybrid, rich-client J2EE systems, though.

        • All the critique of HTTP/HTML UI is probably correct. HTML is not designed for UI and any continuous event based widget set probably can be used to create better and more responsive UI than possible with transactional HTML/HTTP model.

          Millstone is not anyhow limited to HTTP/HTML - the support for continuous events based terminals is being added in the future. Still the reality in many applications, where the number of users is large, is that installing anything (including JVM) to client side is unacceptable. Millstone resolves this problem by providing extensive and easy to program UI library that can offer the best of the both world.

  • end of the inning and the game...
  • When I see "Millstone [millstone.com]" I think coffee. I wonder if they did that on purpose (Java... beans... etc)... the Java PR people love the coffee terms, and it is only fitting that something that extends Java should use a coffee related term. I'm gonna make a java-based game engine called Starbuck. :)
  • There is an extensive features demonstration online [millstone.org], where the UI components can be tested and configured on fly. This is the fastest way to get a good overview of Millstone capabilities.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close