Sean Schofield wrote:
Can you elaborate on what exactly is buffered in the JSP case. I have
a rough idea of what you are talking about here but I don't know
enough about the internals of JSP to completely understand this. I'm
interested in some more specifics here.
With using JSP (or any ViewHandler), you need to build up a component
tree for evaluation. With JSP, it's now doing two things at once, it's
trying to build a tree and evaluating, buffering string/character
content to the output stream. If you have a page with lots of static
content and a single component, you would be evaluating the whole page,
just to produce maybe 3 component artifacts (two representing the before
and after of your single jsf component).
With Facelets, it knows when you evaluate the page, that you have a
single purpose of "building" a component tree-- that's all it's intended
to do. So instead of buffering or evaluating content in the document,
it just says, here's a pointer for if/when you need it later. In the
above example of a single component in a page, you would just get a
reference to the 2 blocks of static content (without evaluation) and the
creation of your one jsf component.
When you get into AJAX or partial processing, this can get expensive!
With Facelets, we have a static/shared set of instructions for building
component trees and inline content (what would be buffered with JSP) is
simply referenced by each user's component tree. So if you are using
AJAX to partially process only a few components, then you haven't
buffered/evaluated anything from your original document, just gotten
shared references, which less overhead on the server.
Can you elaborate on shared references? Is the component tree still
rebuilt in this scenario? I'm curious as to the specifics of the
lifecycle in this use case.
All threads must have their own UIComponents-- so in Facelets case, we
have UILeafs which are basically wrappers that *point* to shared content
that will be evaluated later. So if you have 500 concurrent users, each
has a UILeaf instance in their component trees, but they all point to
the same set of content. While at the 30,000 foot view, this seems moot
in relation to JSP, but we've found that it's a lot cheaper to just
provide 'pointers' to shared content instead "rebuilding" content for
each thread when we know that it's static.
Again, lets take the extreme case of a single component in a page with
lots of static content. You want to do some cool AJAX stuff but worry
about the overhead of all the rest of the static content in the view.
With JSP:
Each request, the whole document would be evaluated and
buffered/captured to just be able to re-render or operate on the one JSF
component.
With Facelets:
Each request, you are just passed pointers to the static content for
inclusion in your tree, and you can re-render the one JSF component
without evaluating/buffering any other content.
-- Jacob
Sean
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
