+1 Stateless definitely should be part of the codebase, I would not opt
for an extension more for an integrated feature here.
Extensions are so so, because they always are a little bit behind the core.
As for <!-- --> Martin Koci told me, that removal code already is in, it
is just not enabled per default due to legacy browser support.
(you can turn it on via
<context-param>
<param-name>org.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG</param-name>
<param-value>false</param-value>
</context-param>
)
We probably should rethink if we already safely can make this our
default since some legacy browsers no can be considered safe not to be
supported anymore (ie 5.5 for instance and ie6 is slowly on its way out
except for Asia)
Werner
Am 09.02.12 17:36, schrieb Leonardo Uribe:
Hi
Some days ago Thomas Andraschko told on users list that he already
have a variant of this for MyFaces. Look the mail with subject:
"Weird PlexusContainer object in ViewRoot"
I think it is a good idea to put that code in myfaces commons or as an
extension (extensions/stateless-jsf ?). Since the license of the code
is ASL, it is possible to host it here. To make this possible I think
we should vote about create a module.
@Thomas: could you create an issue on myfaces issue tracker:
https://issues.apache.org/jira/browse/MYFACES
and attach the code you are working on, so the PMC can vote if it is
worth to create the subproject?
About performance of MyFaces code vs Mojarra: I think with the latest
changes MyFaces code looks very good. Yes, there is a lot of room from
improvement. I think it is possible to do things like trim spaces in
facelets compiler, remove<!-- --> on the scripts (it is there because
very early versions of MyFaces do that), or optimize js rendering
using some myfaces specific code instead call javax.faces js api. But
note recent optimization in myfaces renderers has been improved its
base speed. If you exclude the javascript rendering part, MyFaces
renderers looks good.
I think we should let those optimizations for 2.2. The only thing left
to start working on that branch is reorganize shared modules (split
shared in two, cleanup and maybe create myfaces-impl-api submodule to
hold stuff like spi interfaces and other myfaces-impl api to be used
for integration points).
Right now, MyFaces 2.1.6 uses a lot less memory, and recent
improvements into its PSS algorithm has reduced the required state
size for views, making it very efficient.
regards,
Leonardo Uribe
2012/2/9 Werner Punz<werner.p...@gmail.com>:
Hia just a general discussion, regarding performance. One of the big
performance impacts is statefulness, now there has been a project
http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/
This however is only for Mojarra, shouldnt we target something similar, one
day or the other it will be part of the spec, so targetting this early might
give the mojarra guys a push for going there also.
If you look at the numbers you can see there is a lot to gain by being able
to render pages stateless one way or the other.
I personally think in the typical extranet site, most pages are able to go
stateless and about 5-10% should be stateful, that way we could cover both.
Another performance issue I still have gripes with is the rendered code.
For a small page we on the average still have way more code rendered than
Mojarra, in some cases up to 40%. Which is a lot.
While we already did some work regarding our onclick event javascript calls,
there is still lots of room for optimization in our code.
For instance we render<!-- --> with all linebreaks and spaces between link
and script tags intact.
Mojarra basically strips all unneeded stuff and renders only the script and
link tags without any blanks.
Werner
