[Phpserverfaces-devel] ViewHandler Implementation - Smarty or Not? (copied from forum discussion)

[Harlan I. <h.i...@gm...>]

By: Harlan Iverson - h-iversonProject Admin
ViewHandler Implementation - Smarty or Not?
2006-08-15 22:34
So I am getting pretty far along with the internals of phpfaces, and it's
getting time to implement a component model. JSF calls for the ViewHandler
to implement two methods (stages) related to template parsing/display:
createView and renderView. The current implementation uses only one stage.
The reason for having two is clear now that I understand the spec, and this
is it:

JSF either parses the view or restores it from a serialized state. The
former requires parsing of the view to create the component tree. For most
purposes this should be 'fine and dandy,' however, there are still a few
more phases before the output is actually sent the client--apply request
values, process validations, update model values, and invoke application.
Only after all these are EL expressions to be evaluated and the response
sent back to the client.

Smarty's advantage is that it compiles directly to PHP code and it is
actively used and maintained by 3rd parties (reduces the scope of this
project++). But as explained above, a single-stage template mechanism simply
isn't good enough. Well, here's the new idea:

Compile Phacelets to Smarty as I have been doing, but rather than actually
outputting the results, simply wrapping everything, including vanilla text,
in an applicable Phacelets block function; this would cause the component
tree to be built in the createView phase when $smarty->fetch("...") is
called. At the end of the request, the appropriate render kit would be
applied to the component tree, and as per the spec, the response would be
rendered.

Going this route offers the advantage mentioned above, outside development,
in addition to immediate availability. Since it only applies to the
createView phase, it also allows makes it easy to drop in a replacement if
it proves to be a bad solution in the long run.


>      By: Nobody/Anonymous - nobody
>      RE: ViewHandler Implementation - Smarty or No
>      2006-08-17 10:17
>      Sorry, i don't understand the createView renderView concepts as good
as i should understand it ;-) Maybe you can explain a little more, e.g. with
an example.
>
>      Using smarty for handling the view was our idea too. Smarty is very
flexible when defining templates and parsing it, but i think smarty has also
some problems. Parsing single templates is very fast, with no compile check
and using cache, it is perfect for "static" pages. But for rendering views
it haves a lack in performance.
>
>      The problem in our PHPfaces project is for example, when some data
from a component changes, the hole component tree has to be parsed by
smarty, that cost much time for an real web-application. Caching outputs
won't work, cause the changed data has to be parsed again, otherwise the
changes won't be displayed. One idea is to split a component in many
subparts and only parse those parts who was changed, e.g. the model changes
or the validation...
>
>
>>
>>            By: Harlan Iverson - h-iversonProject Admin
>>            RE: ViewHandler phases and Smarty
>>            2006-08-17 23:38
>>            Hello, thanks for the response!
>>
>>            So I'll start with a little about createView and renderView
first, then explain how I see Smarty fitting in.
>>
>>            In a nutshell, when a JSF view is loaded for the first time,
the template is parsed and a component tree is built in memory, from the
hierarchy defined in the template itself; in JSF, a 'view' is a component
tree, not the template itself. Each component is individually responsible
for "encoding" and "decoding" itself, that is, when the view is "rendered"
in renderView (last phase, always) it may send an <input> with a designated
name="", which it then "decodes" in the 'apply request values' phase of a
POST request originating from that view.
>>
>>            In addition to just "decoding" the value, conversion and
validation are also run before the new values are applied to the model (the
backing bean properties that they are bound to). After all this, the same
view that comes from createView is then rendered again using renderView.
Each component, being an object in memory and not simply a string
representation with expressions throughout, is then free to apply any
updated values at that time.
>>
>>            I hope my explanation is clear; if not, I hope the official
specs can fill in any gaps :) The API documentation is here
<http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/index.html>
and the JSF Spec here <http://jcp.org/en/jsr/detail?id=127>.
>>
>>            Now, in the way of using Smarty even after finding out how
grossly incompatible it is with the component-oriented way of doing things!
>>
>>            I think it's a valuable tool for use in the initial createView
phase because it has great flexibility for plug-ins. My envisioned use of it
would be completely for its flexible parser, and the parsed template itself
would produce exactly 0 bytes of output that is actually sent to the client,
it would simply be discarded. Instead, the ViewHandler would generate a
Smarty template that is saturated with a hierarchy of {component id="..."}
block functions (more on block functions here: <
http://smarty.php.net/manual/en/plugins.block.functions.php>). These
component blocks would then be used as the basis for creating the component
tree, but not at all for rendering (though, of course one could make a
Smarty Component that then renders part/all of the model in a second Smarty
template, but I digress ;). Basically, rendering would be carried out as per
the JSF specification about RenderKits.
>>
>>            Harlan