Discussions

News: Tech Talk with Kito Mann on JavaServer Faces

  1. Tech Talk with Kito Mann on JavaServer Faces (37 messages)

    Kito Mann, author of the upcoming book JavaServer Faces In Action (Manning), compares UI-oriented and foundation-oriented frameworks, and looks at where JSF fits in. He talks about what's new in the beta release, and lists various tools and apps making use of JSF today. He compares JSF to ASP.NET WebForms and outlines the challenges for industry-wide adoption of JSF.

    The JSF final release is expected around the end of this March.

    Watch Kito Mann's Interview

    Threaded Messages (37)

  2. Great discussion and I do feel that JSF going to be "the" framework we use out there my only question is When? I don't think it will happened until we get a good IDE out there that is fully integrated into JSF and I know Sun Studio Creator is coming I'm not confident that it will be a hit. Personally I think I am safe with my standard frameworks like WebWork and Struts for at least the next 2 years, right?
  3. Kris,

    I think "when" is the latter half of this year, after it's been released and tools become available. Also, I don't know of too many technologies that you can "stick" with for two years :-). You've always got to follow the most logical migration path. Sticking with Struts will eventually lead you to JSF -- people are already using the two together now.

    > Great discussion and I do feel that JSF going to be "the" framework we use out there my only question is When? I don't think it will happened until we get a good IDE out there that is fully integrated into JSF and I know Sun Studio Creator is coming I'm not confident that it will be a hit. Personally I think I am safe with my standard frameworks like WebWork and Struts for at least the next 2 years, right?

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  4. Mr. Mann says:
    > "You don't see 30 different versions of the Servlet API because it's a standard. >Sure, there are some things we'd like to see added or changed, but it works well >enough as a basic building block."

    Many of these frameworks try to overcome the deficiencies of the so-called "works well enough" Servlet API. Works well enough to do what exactly?

    JSP is a kludge
    JSTL is a kludge
    JSF is a kludge
    Struts + JSP + JSTL + JSF is the ultimate kludge

    Tapestry is powerful, mature, and scalable. Try it today. Or just keep waiting for JSF 3.0.
  5. I am getting tired of reading half baked comments like this. Would you care to enlighten us by substantiating your comments before heaving them over the wall?

    Maybe in addition to "Noisy" we should request a "Meaningless Drivel" designation so the rest of us can be spared from reading non value added comments like this.
  6. Another great web UI framework is Echo. Its "pure Java" relief from yet more "scripts".

    It has been discussed previously on TSS

    http://www.theserverside.com/news/thread.jsp?thread_id=19744

    You can find out more information at

     http://www.nextapp.com.

    and

     http://echopoint.sourceforge.net
  7. There's another piece of the puzzle, which is a little less certain -- a third-party

    >component industry.

    That is a bit strange – why less :--)
    As seems to me there are components (from MS or other vendors) actually drive
    ASP.NET (and the same was true for VB before that by the way - where are their
    Swing analogues?)

    At the end of the day end users (developers) are dealing with components if you
    talk about the visual design

    Dmitry Namiot
    Coldbeans
  8. An awesome interview and a very good intro to JSF with an insight of how JSF compares with WebForms. Kito mentioned that he is not an ASP.NET expert, but his commands on WebForms knowledge are not bad either:-).

    I would like to share my 2 cents too:

    1. First of all JSF is already too late if you consider the existence of WebForms(almost 2 years), so JSF community should work fast with IDE vendors to release it ASAP.

    2. JSF lacks (I am no expert of JSF, correct me if I am wrong) a caching mechanism similar to caching user controls in .NET world. This feature is very important in today's rich and havy duty web environments.

    3. I strongly believe that Java world especially on the web site is too obsessed with exposing cryptic XML tags to applicattion developers. Even configuring and composing JSF web components using JTL is tedious and very time consumimg as comapred to .NET code behind approach.

    Rashid.
  9. Is it the right pattern?[ Go to top ]

    As I look at the MVC pattern originally developed by SmallTalk developers for GUI applications and compare it to the MVC as it is implemented by Struts, WebWork, etc. I wonder why JSF is trying to shoehorn a pattern that works well for co-located view / controller / model components onto a platform that has serious latency and a stateless protocol between the view and the other layers?

    How can we expect this to scale for large scale applications? Won't these fine-grained event handler calls be overly chatty for a simple web page?

    I'd love to be wrong, and have a magic silver bullet for building web applications, but I don't see it happening...
  10. Is it the right pattern?[ Go to top ]

    As I look at the MVC pattern originally developed by SmallTalk developers

    > for GUI applications and compare it to the MVC as it is implemented by Struts,
    > WebWork, etc. I wonder why JSF is trying to shoehorn a pattern that works well
    > for co-located view / controller / model components onto a platform that has
    > serious latency and a stateless protocol between the view and the other
    > layers?

    Keep in mind that by far the most common event that will cross over the HTTP protocol layer is a submit button. In other words, the network traffic in a JavaServer Faces application will have pretty much the same pattern as, say, a Struts application that primarily uses form submits. The other standard event that JavaServer Faces supports (value change events) will most likely be used primarily for things like "click a checkbox to change the set of options available in a separate combo box", where you often have to go to the database (or to data cached on the server) anyway in order to define the new set of options, so a server round trip is not an unusual occurrence here no matter what development technology you are using.

    The standard components that ship with JavaServer Faces 1.0 will not have any substantial support for client side scripting (although a couple of them must leverage scripting in order to fulfill their behavior contracts). That is primarily the result of the JSR-127 expert group being focused on creating the right foundational APIs -- not on building the world's richest component library out of the box. That library can easily be incremented in future versions. Our initial goal was to provide a set of standard components that minimally supports actually writing real live applications.

    That being said, nothing stops people from writing JavaServer Faces components and renderers that support very rich client side scripting support. Just as an example of this, one of our developers at Sun was able to wrap an existing third party JavaScript-based calendar control inside a JavaServer Faces component *very* easily -- if you're familiar with the APIs this takes less than an hour even for a pretty sophisticated control. In addition, JavaServer Faces can integrate with other frameworks that provide client side support -- for example, the Struts-Faces integration library available (in nightly builds at the moment) lets you use the Struts Validator Framework, including client side JavaScript support, out of the box on JavaServer Faces input components.
     
    > How can we expect this to scale for large scale applications? Won't these fine-grained event handler calls be overly chatty for a simple web page?
    >

    Nah ... anyone who finds the app to be too chatty will be motivated to develop custom renderers (or use third party ones) that enable client side scripting support. The key value add is that the page author doesn't have to be aware when the switch is made -- they just use component tags like they did before, and the built-in rendering takes care of the complexity.

    Even before JavaServer Faces ships, there are many initiatives in this direction ... to say nothing of some major component library vendors we've been talking to, who are planning on supporting JavaServer Faces APIs in their own component libraries.

    > I'd love to be wrong, and have a magic silver bullet for building web applications, but I don't see it happening...

    Stay tuned :-).

    Craig McClanahan
    (co-Spec Lead, JSR-127)
    (Original author of Struts)
  11. <quote>
    I haven't worked with Tapestry, but from what I've seen, it's quite well-done. It actually reminds me a lot of ASP.NET Page Framework and WebForms (and I know Howard learned a lot from WebObjects as well). Tapestry's also been around for a while, so it's pretty mature and stable. I can't really say it's better or worse than JSF, nor can I say how easily you could, for example, use JSF components in a Tapestry environment or vice-versa. I do, however, think it'd be a worthwhile task for someone to pursue.
    </quote>

    Just a referesher on the Tapestry timeline. Tapestry started in January 2000, about the same time as Craig was working on Struts I believe. I had done some minor demos using WebObjects in the 98-99 timeframe. I've never used any Microsoft technologies for development, but ASP.NET and WebForms came later (or became public later). Any simularities reflect parallel development (only so many ways to skin a cat syndrome).

    I've repeatedly banged my head against integrating Tapestry with JSPs. You can use a JSP to render a response to a Tapestry request, but I have yet to find a way to allow Tapestry components to exist inside a JSP ... the rendering model is just too different. I'm about 90% sure it isn't possible.

    I still enjoyed this article and the prominence of Tapestry within it.

    It'll be intersting to see how our competing books fare, sales-wise :-)
  12. Howard,

    I'm glad you enjoyed the interview. I wasn't implying that you were influenced by ASP.NET at all; I recognize the fact that Tapestry pre-dated ASP.NET Web Forms. I just noticed that both solutions have a lot of similarities.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  13. JSF is good but late[ Go to top ]

    I recently evaluated Java frameworks for implementing a simple (15 pages)
    Web front end with business logic already existing in form of CORBA service.
    And I want to say that I was amused how far behind all Java RAD development is comparing to Microsoft's.
    JSP is pretty much outdated from terms of design, 2.0 is a facelift and not a big help.
    We've found only two RAD tools on the market: JDeveloper10 (still preview) and WebSphere (4.5 grand for a starter license). The rest is just a salad of multiple approaches, many still in beta (i.e. Tapestry).
    The amount of housekeeping work is much more that with WebForms.
    Emerging JSF (when finalized) is going to compete with WebForms1.1 but
    WebForms2.0 are about to be released and carry improvements to build applications with 0 lines of custom code.

    Having said that I have to say that we decided to go with Java+ Struts+ JDeveloper because this is the only (WebSphere is out of budget) RAD tool
    that uses standartized technologies and supports development "from side to side". Major reasons against Microsoft were lack of cross-platform portability and licensing terror Microsoft unleashed.

    I am going to enjoy programming with Java, JSP and Struts but I very well know that from design point of view these are not up to date.
  14. JSF is good but late[ Go to top ]

    <!-- I am going to enjoy programming with Java, JSP and Struts but I very well know that from design point of view these are not up to date. -->

    You are right, JSF is way behind WebForms. I don't know why JCP take so much time to roll it out (the first time I heard about it was in 2001 Java conference) and it's almost three years and still no solid/standard product in the market. I bet you have heard that soon MS is launching it 2.0 version of ASP.NET (code name "Whidbey") with almost 45 new web controls. Hope Java junkies with enough coffee and obsession of XML wake up then.
  15. Some problems with JSF[ Go to top ]

    Hi,

      I am testing JSF on a small project. I was making my tests with EA4, so maybe some question is already fixed now.

      Something I do not like is this kind of code :

    <f:use_faces>
      <h:form id="cadastroCidadeForm" formName="cadastroCidadeForm">
        <h:command_button id="novo" label="Novo">
          <f:action_listener type="br.com.infobr.fw.jsf.cadastro.comandos.NovoActionListener" />
        </h:command_button>
    ...

      Why the web designed (who do my JSP page) should know what is the name of the class who will process my button event ?
      
      Another problem is the way used to hide/show (or enable/disable) a component. Why there are no a simple visible (or enabled) property on each component ?

    Danilo.
  16. Some problems with JSF[ Go to top ]

    Danilo,

    You should really try upgrading to beta 1 -- all of these issues have been addressed.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info


    > Hi,
    >
    > I am testing JSF on a small project. I was making my tests with EA4, so maybe some question is already fixed now.
    >
    > Something I do not like is this kind of code :
    >
    > <f:use_faces>
    > <h:form id="cadastroCidadeForm" formName="cadastroCidadeForm">
    > <h:command_button id="novo" label="Novo">
    > <f:action_listener type="br.com.infobr.fw.jsf.cadastro.comandos.NovoActionListener" />
    > </h:command_button>
    > ...
    >
    > Why the web designed (who do my JSP page) should know what is the name of the class who will process my button event ?
    >
    > Another problem is the way used to hide/show (or enable/disable) a component. Why there are no a simple visible (or enabled) property on each component ?
    >
    > Danilo.
  17. Some problems with JSF[ Go to top ]

    Thanks to your reply.
      I will evaluate the beta 1.
      But can you say to me what is the features on beta 1 who will solve my questions ? Just a mention to his names is ok.
  18. Some problems with JSF[ Go to top ]

    Thanks to your reply.

    > I will evaluate the beta 1.
    > But can you say to me what is the features on beta 1 who will solve my questions ? Just a mention to his names is ok.

    In the beta release of JavaServer Faces, you will typically trigger application actions using the "action" attribute, which can take a method binding expression. So, your button would typically look like this:

       <h:command_button id="novo" label="Novo"
          action="#{mybean.doSomething}"/>

    where your backing bean class (normally configured as a "managed bean") would have a method like this:

        public String doSomething() {
            ... deal with the fact that this button was clicked ...
        }

    The String you return is the logical outcome that feeds in to the navigation handler.

    The hide/show flag you are looking for is the "rendered" attribute, which is present on pretty much every component tag. Simply set this property to false and the component will still exist in the component tree, but it wont' get displayed.

    For further assistance on JavaServer Faces, there's a forum available at the Java Developer Connection (free registration required):

      http://forum.java.sun.com/forum.jsp?forum=427

    Craig McClanahan
  19. Some problems with JSF[ Go to top ]

    This is a feature Kito Mann talk on his article, method binding expressions.
      I am sure this is best than create anonymous adapter classes.

      But this is not the point of my first message.
      
      My point is : why the web designer must know the name of the method who will handle the event ?
  20. Some problems with JSF[ Go to top ]

    The hide/show flag you are looking for is the "rendered" attribute, which is present on pretty much every component tag. Simply set this property to false and the component will still exist in the component tree, but it wont' get displayed.

    Got an example/link on how do do that when the page is first rendered? for example, I have a page that is used for adding and updating. Some things are used on add only.
  21. Hi,

    >
    >   I am testing JSF on a small project. I was making my tests with EA4, so maybe some question is already fixed now.
    >
    >   Something I do not like is this kind of code :
    >
    > <f:use_faces>
    >   <h:form id="cadastroCidadeForm" formName="cadastroCidadeForm">
    >     <h:command_button id="novo" label="Novo">
    >       <f:action_listener type="br.com.infobr.fw.jsf.cadastro.comandos.NovoActionListener" />
    >     </h:command_button>
    > ...
    >
    >   Why the web designed (who do my JSP page) should know what is the name of the class who will process my button event ?
    >   [...]
    >
    > Danilo.

    Is that still the case ?
    Do web designers still need to know the name of the class ?

    In that case, why not allowing
    (1) a component designer to define arbritrary type names for components,
    (2) to map these arbritrary type names onto real class names (through an XML mapping stored into a webapp)
    ???

    Thanks for any answer

    Dominique
  22. On the last version of JSF (1.0 beta) you do not need to know the class name.
      But you still need to know the managed bean name, and the method name.
      Look on this page (and Kito's article) to a explanation about this :

    http://bill.dudney.net/roller/page/bill/20040102#jsf_ea4_and_jsf_1

      My point is : even this is too much information.

      I have a framework developed internally on my company where I have this on my java code :

      public class MyForm extends SigeaForm {

        private SigeaEdit myEditor;
        private SigeaButton myButton;

        public void init() {
          addComponent(myEditor = new SigeaEdit("myEditor"));
          addComponent(myButton = new SigeaButton("myButton");
          myButton.setEventHandler(SigeaEvents.EVENT_ON_CLICK,"myButtonOnClick");
        }

        public void myButtonOnClick() {
          myEditor.setValue("Hello world");
        }
      }

      On this case the event handler to a button is on the java class, not the form.
      So on the jsp page I have just this :

    <html>
    <sigea:form>
    <sigea:edit componentName="myEdit"/>
    <sigea:button componentName="myButton"/>

    </sigea:form>
    </html>

      No information about the event handler on the JSP page.
  23. My take on Tapestry vs JSF[ Go to top ]

    I wanted to post this yesterday but I was having trouble logging in (TSS was saying it couldn't compile some JSP page for some reason) so I posted it in my blog and figured I'd post the link here when it let me in. So here goes: my comment on JSF vs Tapestry.
  24. My take on Tapestry vs JSF[ Go to top ]

    Andrew,

      Do you know of a more datailed comment of Tapestry vc JSF ?
      Something to show you how to do common tasks on both enviroments.
      I have a framework developed internally in my company, with a idea very like the one of JSF/Tapestry and I am happy with it. But I want to migrate to a more popular framework.

    Danilo.
  25. Nope[ Go to top ]

    I don't know of such an article sorry. I'd love to see it though.
  26. My take on Tapestry vs JSF[ Go to top ]

    Thanks to Andrew for using my spoon/gallon analogy. I have moved to Tapestry after developing and leading a group of developers on a a large scale JSP/Struts project, I have lived with the Application for a year, so I have seen how an app features evolve, and how JSP/Struts evolve. This project required a massive amount of back and forth between the Designers and Developers, that was a nightmare. Developers sticking scriptlests, and I do mean sticking :) Laziness and must-get-it-done-now attitude.

    Why do these people seem to think that JSF, JSP 2.0 and JSTL will solve the problems of separations of concerns, write less code, write cleaner code, write robust code (check out error reporting in Tapestry), write code that supports Open/Closed principle (blah blah). Why on earth would you want your HTML destroyed and become fragile JSPS. Why do you want your business logic interspersed with HTML in those fragile JSPs with billions of tags and strange twisted JSTL expressions, why on earth do you want/need to see and work with HttpServletRequest/Response/Session/ActionConfig/Mappings etc..Try to create a Page with Eighty fields in JSP/Struts/JSTL/JSF with security, persistence, that is part of a multi-page order entry application, then try to write it in Tapestry, check out the difference in the level of verbosity, and imagine the scenarios of when you client requests different changes; clients make changes don't they?

    Now what the hell, who is not listening here? I believe Sun and the Struts/JSF crowd are slipping something in the Kool-Aid.
  27. My take on Tapestry vs JSF[ Go to top ]

    <quote>
    Why do these people seem to think that JSF, JSP 2.0 and JSTL will solve the problems of separations of concerns, write less code, write cleaner code, write robust code (check out error reporting in Tapestry), write code that supports Open/Closed principle (blah blah). Why on earth would you want your HTML destroyed and become fragile JSPs
    </quote>

    Yes, I tend to agree with your comment. The way of Tapestry is similar to the Barracuda + XMLC and it's a better way to seperate the designers from developers. The point why all the developers use JSP, JSTL and later JSF because those stuffs are standardized and coming from J2EE spec. If you use Tapestry and Barracuda XMLC you need an extra work to add the libraries needed and this is not the case if you use JSP, JSTL...

    Lofi.
  28. My take on Tapestry vs JSF[ Go to top ]

    I had to select a framework for our future web-apps. It boiled down to a short-list of Struts, JSF, and Tapestry.

    While Struts is the de-facto standard, it is obvious it lacks a lot of features. JSF seemed too immature. Tapestry uses a very nice approach, very elegant, and supprisingly simple. We got our first prototype to show to the end-users after 1 week of development (developers did use Tapestry for the first time ever).

    My opinion on JSF:
    * It is overdesigned (as Swing).
    * It wants to abstract the rendering (HTML, WAP, ...), but nobody needs this. For other UI-devices, you probably want other content and flows as well. So everything except the business logic (in EJB's) needs to change anyway.
    * It claims a component market will emerge. However, other component markets (Swing, EJB's) do not really florish either.
    * It requires soffisticated and mature tools to develop efficiently.
    * Makes me think of layout-managers and stuff

    Tapestry
    * does a good job in minimizing the code base (in java, html, xml)
    * if you want there is NO code in the html
    * uses html as its "layout-manager". If you want to do WYSIWYG, use dreamweaver, or even frontpage, ...
    * able to use components (html-fragment + java-class (+javascript is you like)). This can be repeated on a page as often as you like, the component can be used on other pages, etc. Just as a real component, similar to a JPanel in Swing.
    * in contrast to Struts, the code to write parameters on a web-page (form) is in the same location is the code to read/interprete parameters from the submit of the page. The miracle is: it is just in plain getter/setter methods.

    Just take a couple of hours to read about the Tapestry concept, and evaluate it... it's a totally different approach from Struts. More like JSF, but then kept simple; as it should.

    Jo
  29. Congratulations to the JSF team[ Go to top ]

    No EJB, O/R, Weblogic or Websphere?
    No sessions?
    No kludge of "frameworks" stacked upon each other + cache product thrown in as an afterthought?

    The first time I see a important and fairly large project (+5 mill) done as a simple but powerful stateless web application with Resin, JSF and stored procedures, I know that the Java world is on the way to recovery from their strange sickness.

    Happy recovery!
    Rolf Tollerud
  30. Links with Portlet JSR-168?[ Go to top ]

    Hi,
    JSR-168, Portlet is also another developement framework. It has MVC, caching, multilanguage, multi device and more.
    I would like to have some opinions from J2EE experts here.
    Do JSP and Portlet compete? Can they be used together? I'm a little bit confused with all these new J2EE frameworks...

    Regards,
    Mickaël
  31. Hi,

    > JSR-168, Portlet is also another developement framework. It has MVC, caching, multilanguage, multi device and more.
    > I would like to have some opinions from J2EE experts here.
    > Do JSP and Portlet compete? Can they be used together? I'm a little bit confused with all these new J2EE frameworks...
    >
    > Regards,
    > Mickaël

    Hi,

    What about the integration between a portal (respecting JSR-168) and a JSF implmentation ?
    How easy would be the integration ?

    Are these two technologies somewhat independant and the integration is easy ~ some hours ?
    Or, the controler of these two technologies have to be "merged" and the integration is not that easy ~ some days, some weeks, or more ?

    Thanks for any answer.

    Regards,
    Dominique
  32. Re: Links with Portlet JSR-168?[ Go to top ]

    Hi,

    > > JSR-168, Portlet is also another developement framework. It has MVC, caching, multilanguage, multi device and more.
    > > I would like to have some opinions from J2EE experts here.
    > > Do JSP and Portlet compete? Can they be used together? I'm a little bit confused with all these new J2EE frameworks...
    > >
    > > Regards,
    > > Mickaël
    >
    > Hi,
    >
    > What about the integration between a portal (respecting JSR-168) and a JSF implmentation ?
    > How easy would be the integration ?
    >
    > Are these two technologies somewhat independant and the integration is easy ~ some hours ?
    > Or, the controler of these two technologies have to be "merged" and the integration is not that easy ~ some days, some weeks, or more ?
    >
    > Thanks for any answer.
    >
    > Regards,
    > Dominique

    We mention in the exo acticle about JSF and JSR 168 integration. On theory , you can develop a jsf component and drop into a portlet application or servlet application since jsf provide a set of methods in ExternalContext object, which abstract the way you access request, response (request and response can be either ServletRequest or PortletRequest, ServletResponse or PortletResponse)

    Tuan Nguyen
    www.exoplatform.org
  33. Links with Portlet JSR-168?[ Go to top ]

    I've been working to get SOFIA (http://www.salmonllc.com/sofia), also mentioned in the article, to work with the portlet API (JSR 168). In my opinion, GUI frameworks like SOFIA or JSF and JSR 168 solve two different problems.

    JSR gives you a really nice way of combining content from a bunch of different sources into basically a windowing system for a web page. What actually goes into each window (or portlet) is for the most part beyond the scope of the 168 spec, except that a portlet can call out to JSPs generate it's content. What goes in the JSP is up to you.

    What we are doing with SOFIA is adding hooks in there so that a SOFIA JSP Page with all the rich GUI widgets can be snapped into any JSR 168 compliant portal. So you will be able to use the portal tools to personalize the users portal page (basically choosing which portlets go where for each user and how they behave). You will be able to use a tool like SOFIA's with Dreamweaver integration to "paint" the actual portlets themselves.

    BTW: I don't know if JSF pages can be run from portlets. SOFIA pages need quite a lot of exensions to make them work in that environment.
  34. Links with Portlet JSR-168?[ Go to top ]

    Dan,

    The final version of JSF should work with Portlets. The spec has abstracted the external environment so that it can work with either Portlest or Servlets.

    I think the world of Portlets + rich GUI components is a pretty exciting thing; it'll be interesting to see how things play out this year.

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
  35. Kito,

    Read your interview in which you presented a pretty good survey of the state of play concerning UI web development. Given that you know of about 30 frameworks you must be suffering framework-fatigue by now. Would one of these frameworks be the Mozilla Application Development Framework.

    For those unfamiliar with work already done by mozilla.org, the Mozilla Application Development Framework enables the creation of rich clients based on their Gecko render engine. Client applications are built using XUL, JavaScript and CSS, as well as other complementary technologies. The client content is defined in XUL - eXtensible Userinterface Language, an XML vocabulary. As such all the components of a client can be delivered across the net from a remote server.

    Do you know of any plans to enable JSF/Servlet/JSP/JSTL to support this framework on the server side? Some might well ask why this particular client-side framework should get preferential treatment from Java. However, I would point out that the Mozilla browser is special in the sense that it is packaged with the Java Desktop. The implication of this is that Java Desktop contains, not just a 'native' browser but also comes bundled with a client application development framework. I'm not sure if Sun knew this or intended it but this is now so.

    I would love to hear your opinion.

    Regards,

    Gerry Fisher
  36. Gary,

    I've been pretty interested in the Mozilla technologies of late, but I can't say I've had a lot of time to investigate them. I do know, however, that XUL makes a lot of sense to me, and that it's entirely possible to use it to define server-side UIs with JSF. As a matter of fact, there's an example of this in the current distribution of the JSF reference implmentation.

    I would love to see someone develop a full-fledged implementation of XUL for JSF's view layer, as an alternative to JSP.

    By the way, do you know of any tools for building Mozilla ADF apps?

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info


    > Kito,
    >
    > Read your interview in which you presented a pretty good survey of the state of play concerning UI web development. Given that you know of about 30 frameworks you must be suffering framework-fatigue by now. Would one of these frameworks be the Mozilla Application Development Framework.
    >
    > For those unfamiliar with work already done by mozilla.org, the Mozilla Application Development Framework enables the creation of rich clients based on their Gecko render engine. Client applications are built using XUL, JavaScript and CSS, as well as other complementary technologies. The client content is defined in XUL - eXtensible Userinterface Language, an XML vocabulary. As such all the components of a client can be delivered across the net from a remote server.
    >
    > Do you know of any plans to enable JSF/Servlet/JSP/JSTL to support this framework on the server side? Some might well ask why this particular client-side framework should get preferential treatment from Java. However, I would point out that the Mozilla browser is special in the sense that it is packaged with the Java Desktop. The implication of this is that Java Desktop contains, not just a 'native' browser but also comes bundled with a client application development framework. I'm not sure if Sun knew this or intended it but this is now so.
    >
    > I would love to hear your opinion.
    >
    > Regards,
    >
    > Gerry Fisher
  37. Kito,

    Thanks for the information about the JSF-RI example; I shall look into it.

    As for MADF IDEs I have seen nothing out there yet. Something in comparison with Macromedia would be nice. Macromedia already have their own solution in MX and so I don't expect to see them producing anything for XUL. By the way, you might wish to keep an eye on this site: http://books.mozdev.org. This is where Mozilla projects are hosted.

    My instinct is that if MADF is adopted, it will be by individual Java partners or IDE vendors, rather than through the JCP. My reason for thinking this way is that there is no reason for going through the JCP because MADF is a non-Java client-side initiative. I believe that Sun and Oracle are looking at MADF, separately. I speculate that they are looking to incorporate it within NetBeans and JDeveloper, respectively. There is a serious lack in this area of IDEs and anyone with a good solution will surely gain some commercial edge. It is also imperative that the Java community meet any challenges posed by Microsoft.

    Looking at client-side development in a broader sense I do find a lot of the war-of-words concerning the merits of various server-side frameworks rather tiresome. These seem to be predicated entirely on the premise that the client-side content is, and will always be, defined in HTML. As we are gradually coming to realise, from an enterprise desktop application point of view, HTML is unsatisfactory and many people have been barking up the wrong tree. HTML is satisfactory for developing web pages with lots of navigation links. However, this type of layout is not the correct metaphor for enterprise applications that require rich client UIs. My view is that we should first develop good client-side frameworks and then let those frameworks drive complementary server-side framework initiatives. In this respect I believe that the cart has been placed before the horse.

    Apart from Microsoft's XAML, there are two other non-HTML solutions out there that I know of - Mozilla XUL and Macromedia MX. I have had a brief look at Macromedia and my preference is for Mozilla, given the three levels of scriptability it provides. These move us away from the distintion between thin and thick clients. We simply have rich clients that are either resident on the host machine or delivered across the network. If delivered across the net we have the potential to split core functionality between client and server. The designer is given a lot of flexibility. In addition to the flexibility available for deciding how to split core functionality, the rich client is also able to call on services provided by the host platform and thus increase usability.

    Regards,

    Gerry Fisher
  38. How is it possible to route a non-faces request (i.e. from a link ../faces/dosomething, or from a forward jsp:forward page="../faces/dosomehing"
    to a java class which after doing something returns an 'outcome' string
    which could be linked to a jsp.