Re: [phpserverfaces-devel] Merging the two projects

[Tobias S. <tob...@go...>]

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.