commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Barczewski <>
Subject [Jelly] Could jelly be used instead of jsp for JSF development? Would it perform well?
Date Thu, 10 Mar 2005 22:21:08 GMT
Summary - Could jelly be used instead of jsp for JSF development
(givent the proper jelly jsf tags were created)? Would it perform

I have read the overview of jelly from the website and it looks great.

My specific interest at the moment is whether it would be feasible to
use jelly for JSF (java server faces) development instead of jsp. I
understand that I would need to create jelly tags that did the proper
things when running inside jelly. Basically the idea would be that
since jelly keeps things in sax events and doesn't serialize until the
end, it seems like it would be a better fit for generating xhtml and
being able to transform that xhtml before sending to the user.

This would be compared to using jsp and wrapping everything in a
transform tag, where everything would serialize to string, be reparsed
and transformed. In Jelly everything would stay native sax until final
serialization at end, no reparsing. It also ensures that everything is
being written out in xml valid form (versus jsp writing strings).

So my question is would this be a good or bad approach. I like the
idea of keeping things in sax until the final end and being able to do
transforms to apply style or client specific customizations. This
could be done with jsp tags but has the overhead of reparsing and
requires strict discipline by developers to not invalidate the xml
being created.

Would the performance of this be decent or too slow? Obviously we
would not have to reparse the data, however I am not sure how fast the
compiled version of jelly is. Would it handle pumping good amounts of
data through it and spitting out dynamic jsf web pages? Does this
compilation of the script run fast or is it still interpretted and
thus fairly slow ? Any plans to compile jelly scripts to native byte
code in the future? How about compared to the approach of using jsp
and then reparsing/transforming, would a jelly jsf solution be faster
than that approach?

Thanks in advance for any help or advice. I thought I would ask
developers that were familiar with the project about my ideas before I
ventured into some testing and development only to find a big gotcha


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message