Server TF Minutes 2006-12-20

From MemberWiki

Jump to: navigation, search

Minutes stored at url: /member/wiki/Server_TF_Minutes_2006-12-20

Attendees

  • Ric Smith <richard.allen.smith(at)oracle.com>
  • Chris Schalk <chris.schalk (at) oracle.com>
  • Craig McClanahan <Craig.McClanahan (at) sun.com>
  • Christophe Jolif <cjolif (at) ilog.fr>
  • Jon Ferraiolo <jferrai (at) us.ibm.com>
  • Shel Finkelstein <shel.finkelstein (at) sap.com>
  • Ted Thibodeau <tthibodeau (at) openlinksw.com>

Original Agenda

  • Agenda
    • Server Integration Technology review
      • Continued discussion of AJAX implementation architectures:
      • Plan forward:
        • Attempt to evolve from varied approaches into unified common architectural approach
        • Use this to drive upcoming Use cases and Requirements
        • Pass on info to the larger Working Group
    • Perhaps discuss non-JSF integration
    • Wrap up

Minutes

Greg Murray gave an intro to jMaki. Links to key jMaki documents have been added to the Server TF Survey wiki page.

Work on jMaki started about 18 months ago. The idea was to leverage existing Ajax libraries and figure out how to integrate into Java. Now, at this point, most of the integrated widgets have turned out to be Dojo because it has lots of relevant features and has a compatible approach. Have discovered that at this point that many toolkits have become good Ajax citizens. Used to be that toolkits had to be loaded in a certain order to work together. Better now.

Some services such as Google Maps and Yahoo Maps require keys. jMaki tries to provide management features to make the widgets and keys available on a global basis.

Recent work to separate out presentation from the JS. (Imagine that.)

Not dictating a backend model, but JSON is preferred representation. Matches Dojo better.

We wrap all widgets and attempt to create a generic wrapper that can work with components from multiple toolkits. For example, the table widget could use either MochiKit or Dojo under the hood and get the same results.

Going forward, will look more at the Dojo data binding approach to see if there are leverage points there.

Early days of jMaki, looked at created a new version of petstore. Demonstrated a 1500 line version at JavaOne. In process, studied toolkits and noticed that there were common approaches.

jMaki knows which widgets map to which toolkits.

Can do some things on the server. UUID processing and scanning page and determining which toolkit needs to process which component.

jMaki config file is json based and allows links to toolkits to be followed only once. Allows management of shared things like api keys for google and yahoo maps.

Best document on jMaki is the latest presentation. There is a PDF version. Chris will put a link on the Server TF Survey wiki page. (Done.)

jMaki has a publish/subscribe model similar to Dojo. (Jon points out that the OpenAjax Hub has a publish/subscribe feature from code submitted by Alex Russell.)

To play with jMaki, can install it with Tomcat. Best UI experience is by using it with Netbeans. Best single document is that about page.

jMaki is very standards-oriented. Layouts just use HTML+CSS.

Jon says OpenAjax Alliance should try to adopt pieces of jMaki across different technical interoperability initiatives.

Craig says that he is looking at encapsulating jMaki for use with JSF

Chris asks about JSF+jMaki vs traditional JSF. Craig says in traditional model the server "renders" to HTML via Struts or JSF. There are property sheets within a visual designer. This is still feasible with JSF+jMaki, but there is an option for components to do some or all of the "render to HTML" on the client.

Chris says Oracle has the same issues in its products.

Greg talked about some changes to jMaki to enable integration into JSF. These changes are recent and still under development. Now, there are 4 things that are provided by components: (Note: these notes below are undoubtedly incomplete or inaccurate)

  • name - like a package name. A directory with files that make up the widget
  • service - URL for call to get your data. Maybe a JSP page or servlet or JSF component.
  • value - For JSP can be a string of text or a JS object. For JSF, mapping back to server logic.
  • property bag - Key/value pairs. Where lots of the magic happens.

In general, jMaki is architected to be independent of JSF, but there are some ability to take advantage of JSF if present.

Jon points out that there isn't a consistent approach to the widget.json files that are part of latest jMaki distribution. Greg says the widget.json approach is evolving right now. The current clock widget built on Dojo is an example of one that is fairly current.

Greg is working on integrating jMaki into tooling. Craig is working on integrating with JSF.

Localization is currently under construction. Likely to borrow approaches from Dojo.

Going forward, Ric Smith will chair.

Next meeting, Jan. 10.