Java Server Faces vs. OPS(XFORMS)

I would like to get a good comparison of SF and OPS(FORMS).

Here is an initial starter set of features. Please feel free to
add/modify the list as needed.
Input based on  actual field experience would be great.

1. UI (Design) -  IDE tools for development:
      JSF -- provides IDE
      OPS -- no IDE

2. Industry Standard & Several well known companies using it
    JSF   -- Java community process
   OPS   -- w3c proposed, but, not yet a well known standard(?)

3. Performance
   JSF -- industry information suggests it is 9x better than XSLT based
software
   OPS -- expected to be slow -- but this needs better quantification

   Any real numbers on H/W and number of users?

   OPS does cache, so its performance ought to be good.

4. Scalability
   JSF -- MVC and scalable
   OPS -- MVC and scalable

 Any field data?

5. Code readability
   JSF -- ?
   OPS -- seems to be very understandable, control flow is clear

6. Learning curve
    JSF -- there is some learning curve, but relative to OPS, what is it?
    OPS -- requires knowledge of XML/XSL/SAX/Java/DOM4J/LOG4J/
               Quite steep learning curve for the Pipeline and Processor
programming model.
7. Skilled People
    JSF -- lots of people?
   OPS -- how many relative to JSF?

8. UI Feature Richness
     JSF -- several useful components (controls)
            - 3rd party components?
 
    XFORMS(OPS) -- how rich is the components relative to JSF?
                              -- any 3rd party components?

8. Server round trips: client side vs round trip to server
      JSF -- Java scripting to handle input errors, no server round trip
needed
     XFORMS -- ?



Thanks,
Chary




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

My 2 cents comment is that JSF is about designing
pages by dragging components onto a blank canvas then
linking  up the component to data and actions.  This
process does not lead to consistency in a site or the
use of good quality CSS for layout.

OPS on the other hand is about using pipelines of
processing to produce xhtml in a repeatable and
consistent manner.  You don't have a graphical IDE,
nor would you want one.

True, doing the first page with OPS is probably more
difficult than with JSF.  I have no evidence of it,
but I suspect the next 15 pages of the same
application/site are easier with OPS.

John C.


--- chary <[hidden email]> wrote:

               
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

chary wrote:
 >
 > I would like to get a good comparison of SF and OPS(FORMS).

I do not plan to really make the ultimate comparison below, but I will
add my $0.02. I hope other people on the mailing-list share their
experience with both JSF and OPS, and what they think the strengths
and weaknesses of both are. Please note that sometimes "you" below
refers to the developer or user, not necessarily Chary ;-)

 > Here is an initial starter set of features. Please feel free to
 > add/modify the list as needed.
 > Input based on  actual field experience would be great.
 >
 > 1. UI (Design) -  IDE tools for development:
 >      JSF -- provides IDE
 >      OPS -- no IDE

I assume you mean by "IDE" "Drag & Drop graphical user interface
builder". In this case, your assessment is correct.

I am personally a little wary of GUI builders, having seen over and
over the unmet promises of those for Swing in the past. They are
usually good for prototypes, but then fail to do the job when it comes
to building actual deployable applications where you have many
pages. You often end up using property sheets which do not have clear
benefits over typing attributes in XML.

On the XForms side, you have XFormation, a visual tool to develop with
XForms, but I have to confess that I haven't tried it yet.

OPS of course has the Studio plugin for Eclipse. While not a visual
tool, it provides useful editing and monitoring shortcuts.

This said, I am hoping that XForms editors will become mainstream. The
excellent programming model provided by XForms lends itself very much
to visual editors. With OPS, you will be able in principle to use any
XForms / XHTML editor.

 > 2. Industry Standard & Several well known companies using it
 >    JSF   -- Java community process
 >   OPS   -- w3c proposed, but, not yet a well known standard(?)

You cannot directly compare JSF with OPS here. You should probably
compare JSF with XForms, or then compare all the Java technologies you
use with JSF.

On the JSF side, there is JSF, but also JSP and JSTL. Those are in
fact industry standards resulting from the JCP, and supported by
several companies. Note that all those technologies are related to the
Java world: they do not apply to, say, .NET, Ruby, or PHP.

On the OPS side, there is XForms, but also XSLT, XML schema, etc. XSLT
and XML schema are quite well-known. XForms is fairly new, and
although I don't have numbers, I am pretty sure that more people today
know JSF than XForms. However XForms has been a W3C recommendation
(W3C does not strictly publish "standards" but "recommendations" -
HTML is also a "recommendation") for two years, and efforts around
XForms (including the number and quality of implementations) are
extremely promising. The Mozilla foundation's support of XForms, for
example, is coming along pretty nicely in Firefox.

It is possible to generate XForms with OPS, of course, but also with
any web platform you like, including JSP, PHP, .NET, etc. We hope to
provide a "proxy" deployment option for OPS, which will allow all
those platforms to handle XForms transparently. In this sense, XForms
is more cross-platform than JSF.

XPL is today not a standard, but W3C is likely to start soon a
standardization effort for a pipeline language. OPS developers like
standards :-)

 > 3. Performance
 >   JSF -- industry information suggests it is 9x better than XSLT based
 > software
 >   OPS -- expected to be slow -- but this needs better quantification
 >
 >   Any real numbers on H/W and number of users?
 >
 >   OPS does cache, so its performance ought to be good.

We do not have hard numbers, but I think it is fair to say that XSLT
processing is usually slower than JSP processing (comparing here both
as template languages). In OPS, you typically use XSLT for:

o Page templates (you don't have to use XSLT, you can for example use
   static XHTML, which is often reasonable with XForms NG)
o A global theme stylesheet (with clear benefits!)

Currently, OPS runs more XSLT stylesheets than the two above:

o xforms-to-xhtml.xsl for the Classic XForms engine
o xforms-portlet-forms.xsl (which you can remove in most apps, but
   which is used for the examples portal)
o xforms-widgets.xsl (which you can skip if you don't use tabs, for
   example)
o xforms-to-ajax-xhtml.xsl for the NG XForms engine (which is being
   natively rewritten)
o a couple of XSLT stylesheets used for internal XForms processing
   (which are being natively rewritten)

It short is important to note that:

o You can tune OPS by removing stylesheets you don't need.

o The current OPS 3.0 beta 3 does have 3 extra XSLT transformations,
   including one fairly costly, which we are going to remove.

On the other hand, the use of Ajax reduces the number of times you
reload pages. Ajax requests are usually faster than full client-server
roundtrips. Measuring application performance becomes a tad more
difficult with the introduction of Ajax!

 > 4. Scalability
 >   JSF -- MVC and scalable
 >   OPS -- MVC and scalable
 >
 > Any field data?
 >
 > 5. Code readability
 >   JSF -- ?
 >   OPS -- seems to be very understandable, control flow is clear

Developers can write unreadable code with any language ;-) I
personally think that XForms is usually quite readable, because of its
declarative approach.

XSLT code can be hard to read, for several reasons:

o People being unfamiliar with XML-based languages like XSLT.

o People being unfamilar with the declarative style of XSLT and XPath.

o People abusing XSLT - very large XSLT stylesheets become often quite
   hard to read. XSLT 2.0 however allows simplifying XSLT
   transformations quite significantly in many cases.

Using XSLT as a template language for XHTML, however, as is done in
OPS, is IMO quite readable.

 > 6. Learning curve
 >    JSF -- there is some learning curve, but relative to OPS, what is it?
 >    OPS -- requires knowledge of XML/XSL/SAX/Java/DOM4J/LOG4J/
 >               Quite steep learning curve for the Pipeline and Processor
 > programming model.

I cannot comment about comparing the learning curves. You also have to
consider whether the developers come from the Java world or
not. Somebody with 10 years of experience with Java and 5 years of JSP
will likely find JSF more familiar and easier to learn.

One important thing to say: with OPS, you do not need a Java developer
at all except if you write your own processors. In the end, most if
not all of your application will be written with XForms, XPL, XSLT,
and the PFC. With JSF, you probably have to have a Java developer
right away, and much of the application beyond the user interface
controls will be written in Java.

OPS is mainly designed to address the presentation layer of an
application, and it is not meant to implement complex business
logic. For some apps, you can do much of it in XSLT, SQL, etc., but
for certain types of applications, you will do this in Java / EJB or,
better, just have OPS call an XML service which can be implemented
with any language you want.

 > 7. Skilled People
 >    JSF -- lots of people?
 >   OPS -- how many relative to JSF?

We don't have a number. It is clearly less for OPS.

 > 8. UI Feature Richness
 >     JSF -- several useful components (controls)
 >            - 3rd party components?
 >
 >    XFORMS(OPS) -- how rich is the components relative to JSF?
 >                              -- any 3rd party components?

XForms specifies a language to describe forms, and specifies a certain
number of controls. It does not specify a component model, but clearly
leaves the door open for XForms implementors to implement their own
components. If you remember, initially XForms was designed for the
client (web browser), where extensibility is clearly hard to
achieve. With server-side implementations like OPS, there is clearly
room for providing a component API.

This said, XForms has quite nice built-in features, in particular
xforms:repeat and xforms:switch.

 > 8. Server round trips: client side vs round trip to server
 >      JSF -- Java scripting to handle input errors, no server round trip
 > needed
 >     XFORMS -- ?

I will dispute your comment about JSF not requiring server
round-trips. As far as I know, actions and listeners on JSF components
do require round-trips and reloading pages. The JSF-based applications
I have seen so far result in many page loads. Some Ajax components for
JSF have recently surfaced, of course, but I do not know if they are
mainstream, and how well they integrate with the JSF philosophy.

With client-side XForms in general, you have very little client-side
roundrips for many operations. With the OPS 3.0 implementation, you do
have Ajax round-trips.

A few points in favor of OPS:

9. XML-friendliness

OPS is clearly an XML platform. JSF is not, even though JSF, JSTL and
JSP kind of look like XML (you CAN write XML-compliant JSP, but most
people don't do it). If you don't like or don't care about XML
technologies, OPS may not be the right choice for you.

With OPS things like generating (or consuming) say, RSS feeds, is a
breeze. So is accessing XML databases and different types of XML
services, formatting reports with different layouts, etc. You deal
with XML natively instead of converting back and forth with an object
model.

10. Dynamic forms

Many users are looking at ways of dynamically generating forms from a
description or another. Generating dynamic forms with JSF is not easy,
because you cannot (reasonably) dynamically generate a JSP page. So
with JSF, your dynamic generation can use JSF, but it will be entirely
written by connecting JSF components by hand. With XForms and XSLT,
dynamic XForms generation is much easier.

11. Compilation

OPS does not require you to recompile, as XForms, XSLT, XPL, page
flows, and even Java code written using the Java processor is reloaded
and recompiled dynamically. Changes appear quickly while you develop.

With JSF, this only works with JSP pages. Getting other Java code to
recompile and reload dynamically requires you to have a pretty good
setup between your IDE and Servlet container. In general, even such an
advanced setup will be slower to give you feedback about your code
changes.

12. Declarative page flow

OPS features declarative page flow. JSF, as far as I know, doesn't.

All right, that's a good start!

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws