phpserverfaces-devel Mailing List for PHP Server Faces
Status: Alpha
Brought to you by:
h-iverson
Menu
▾
▴
phpserverfaces-devel — Development related discussion
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Harlan I. <h.i...@gm...> - 2006-09-21 23:23:25
|
Hello, It's been a while since I've said anything about the project; I'm happy to announce that it is anything but indicitive of the progress that has been made :) The main focus over the past month or so has been creating a build script and improving unit test coverage. This has had the side effect of creating a much cleaner code base, as much refactoring was done. Since things have stabilized, my focus is now on implementing the basic components. At this moment, HtmlForm, HtmlInputText and HtmlOutputText + applicable HTML_BASIC renderers are implemented and covered by tests. The implementation of these components has changed from pseudo implementations represented by Smarty templates to full components. The new component model is not yet functional as a web application, but it's getting close. They need a few Lifecycle and ExternalContext elements to be implemented, but now that building and testing are in place that should come quickly. All these changes are in SVN. Simply check out the "components" branch, edit build.properties if you desire, and run "phing make-reports" to see the progress. Harlan |
|
From: Harlan I. <h.i...@gm...> - 2006-09-08 02:13:44
|
So I was pretty impressed looking at all Matt's Maven code coverage reports and thought it would be cool if there was a PHP tool available. Turns out there is, and it even looks pretty. More info here: http://developer.spikesource.com/wiki/index.php/Projects:phpcoverage Here is the report for PHP Server Faces: http://rosehill.homedns.org:81/phpfaces/report/ Don't worry, I'm focusing on test coverage and documentation this week :) And for you homies using FreeBSD (does anyone still?), the xdebug port doesn't work; it's 1.3.x and Spike requires 2.0. That hung me up for about 10 minutes. Happy testing! Harlan |
|
From: Tobias S. <tob...@go...> - 2006-08-22 08:50:38
|
Hello Harlan, - A component model with StateHolder interfaces > The component models do not have to be serialized within the session, > instead they can choose to serialize only important data. If an object > does not implement StateHolder it is serialized, however any complex > object can implement it. I don't serialze the full component to the session, only the needed value data. Our Components/Controllers can be created with the XML-Model-Data and provide same behavior like the "old" component, but it's not really the old one, only a Controller which handles the appropriate data in the session. - Pluggable navigation and view handlers > This is probably the most important thing. an example would be that I > currently I have two code lines. Our project provides also diffrent "views", but still only one view is implemented. Each Controller has a "fetch" method with a view parameter, currently a "xhtml" view is the basic view parsed with smarty. But for future purposes we have planned to provide a view which outputs XForms. From what I understand an Action Class is equivalent to a Managed Bean? Not at all. A action class is similar like ActionListerens in Java, one component can have many diffrent listeners, e.g. 5 ActionListeners and one DragNDropListener. The action class don't store values like a Bean, only provide a funtion with object references. I agree with reusing the components, but I disagree with adding a fetch > step. A phase listener or navigation handler could just as easily handle > this. Ok, in our project the Controller handles both, data manipulation, prepare rendering the view and parse the View-Template with smarty. Maybe we can spilt this in other concepts. I also think Managed Beans should stay around because they allow one to > display/bind to any information they wish. I agree, but then we have to provide a storage of the bean data, maybe as SessionBean. My understanding of your > project's Action classes (action forms?) is that each page has 0 or more > forms, which aren't really setup to just provide information aside from > default values. No, a our PHPfaces don't think in "pages" only in forms, which could be displayed/outputted in every PHP-script you like. A Form contains children components, like Tables etc. A Form is based on a custom smarty template, so it's changaable by the developer. Only the components itselfs has a base template to provide a comfortable view, like editable tables, sorting functions, drag and drop, treeviews etc. An AJAX request > goes through the same Lifecycle as a regular postback request, except it > is then rendered by the AJAX phase listener. That is a good idea, actually we have a AJAXHandler class which renders the response for AJAX requests. The solution that comes immediately to mind is a > method of defining what components "may" change if the value of a given > field changes, and sending back those components. That we are just doing, every change on the client is stored in a buffer and will be send to server when a Action ist called, in the AJAXHandler the chages from the client were applied to model data. The consistence problem is an other one, more a technical problem that PHP cannot store complex objects with object arrays properly in a session. Therefore we choose an xml data model to be stored in the session. The form renderer > gets the serialized state and puts it in a hidden variable. I know what > you're thinking: bad idea! But it can be as tamper resistant as the > strength of the cryptography you put on it :) The advantage of client > state storage is that the client is free to migrate between any server > in a server farm without needing any special session states in the > router, session migration between servers (normally database session > storage in PHP). I think session mirroring on servers would be a better solution than holding model data as hidden client vars. Maybe a client is going down, or you want to exit the client but save the application state? With data on the server you can restart working again at every time, holding the data on the client you won't be able to do that. |
|
From: Tobias S. <tob...@go...> - 2006-08-21 15:36:10
|
Hello, for future development processes it would be the best, when we merge the best things of each project, to prevent an overhead of development. I've testet your package and i'm thinking some concepts of you are very nice. But i think a too strong orientation on JavaServer Faces concepts would not fit to PHP possibilities. Java is not PHP, vice versa. So i don't prefer to implement the JSF spec 1:1! But for a first step we should do the following things: The base conecpts of your faces-config, ViewHandler ... is very usable. The NavigationRules could maybe beeing mapped to our Action classes. We can maybe reuse the Components from our project and integrate the "fetch" step in your ViewHandler. The ManagedBeans should be bounded with our Component-Model. I decieded in our project to store no complex PHP Objcts in a session, because this causes some constitance errors. So i store simple xml object data and serialize objects with this xml structure. The Client side Ajax Handlers should also be implemented in the "new" project. |
|
From: Harlan I. <h.i...@gm...> - 2006-08-20 18:06:22
|
Okay, so there is no RenderKit or template parser for the new component
model yet... but, this component was fully passed through the lifecycle so
it counts :)
This is the "template":
==========================
$viewRoot = new PhpFaces_Components_UI_UIViewRoot();
$hello = new PhpFaces_Components_UI_UIOutput();
$hello->setValue("hello, phpfaces!");
$hello->setParent( $viewRoot );
$viewRoot->getChildren()->add( $hello );
return $viewRoot;
==========================
In whatever form, the ViewHandler is responsible for creating this component
tree in its implementation of createView(). This happens to be PHP code, but
different implementations of the ViewHandler can create component trees
however they like.
This is the output it produces in the renderView() function, due to the fact
that there is no RenderKit yet:
==========================
PhpFaces_Components_UI_UIViewRoot Object
(
[viewId:private] =>
[children:private] => ListObject Object
(
[list:private] => Array
(
[0] => PhpFaces_Components_UI_UIOutput Object
(
[value:private] => hello, phpfaces!
[children:private] =>
[parent:private] =>
PhpFaces_Components_UI_UIViewRoo
t Object
*RECURSION*
[isRendered:private] =>
[rendererType:private] =>
)
)
)
[parent:private] =>
[isRendered:private] =>
[rendererType:private] =>
==========================
This particular example uses the, appropriately named,
PhpFaces_ViewHandler_Hardcore ViewHandler. I currently have it running in
the pear unit tests, and it should be committed to the SNV
branches/components today.
Harlan
|
|
From: Harlan I. <h.i...@gm...> - 2006-08-18 13:03:44
|
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
|
1 message has been excluded from this view by a project administrator.
