myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] Commented: (MYFACES-2616) Fix UIData state saving model (spec issue 153)
Date Fri, 14 May 2010 03:22:43 GMT


Leonardo Uribe commented on MYFACES-2616:

Just one clearification about why do #1: 

Originally, in jsf 1.2 and earlier, trinidad in its tag handler (see org.apache.myfaces.trinidadinternal.facelets.TrinidadComponentHandler)
has the call to markInitialState(). It is known that PSS comes from trinidad idea (I checked
how it works long time ago), so in mojarra implementation this method is called from its ComponentTagHandlerDelegate.
In javax.faces.view.facelets.ComponentHandler javadoc there is a mention of this call without
any details.

 The problem is that put this call there makes markInitialState() method be called from nodes
to root. Also, aditional calls to markInitialState() are required to be set in other places.
The fix on MYFACES-2616 requires the opposite, call from root to nodes, because on UIData.markInitialState()
the fix requires put some code that save the full state of all children in a map to be used
later (on UIData.setRowIndex() ).

 It could be good to have all calls to markInitialState() in just one place, in one specific
moment, and identify when this call comes from vld.buildView or from UIData.setRowIndex()
(we need only to save the full state if the call comes from vdl.buildView).

> Fix UIData state saving model (spec issue 153)
> ----------------------------------------------
>                 Key: MYFACES-2616
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Task
>          Components: JSR-314
>    Affects Versions: 2.0.0-beta-2
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>         Attachments: fixUIDataPSS-6.patch, fixUIDataPSS-7.patch
> In short, this topic is an attempt to add full state to components inside UIData. I'll
do a brief resume, so people can understand this one easily.
> UIData uses the same component instances to render multiple rows. Suppose this example:
> <h:dataTable id="cities" var="city" value="#{country.cities}">
>     <h:column>
>         <h:outputText value="#{city}"  />
>     </h:column>
> </h:dataTable>
> In the component tree it is created this hierarchy:
> HtmlDatatable
>   UIColumn
>     HtmlOutputText
> If we have 10 cities, the same component is used over and over to render all 10 cities.
The reason to do that in this way is keep state as small as possible.
> Now let's suppose something like this:
> <h:dataTable id="cities" var="city" value="#{country.cities}">
>     <h:column>
>         <h:inputText value="#{city}"  />
>     </h:column>
> </h:dataTable>
> It was changed the output component for an input one. If this table is in a form and
the values are submitted, the same component is used to apply request values, validate and
apply them to the model (update process). To make this possible, UIData class has some code
to preserve this values between phases (using EditableValueHolder interface), so when each
phase is processed, all rows are traversed and you get the expected behavior.
> Now suppose something more complex: We have a code that use invokeOnComponent to change
the style of my inputText. In theory, only one row should change. But in fact, all rows are
rendered with the same color. Why? because we use the same component to render all rows, and
we don't preserve the children component state between rows.
> There is a lot of issues, questions, and side effects related to this issue, but just
to put some of them here:
> TOMAHAWK-1062 InputTextArea doesn't work properly inside facet DetailStamp
> TOMAHAWK-96 Data table Scroller not working the dataTable which was actually contained
in other DataTable
> Problems
with UIData state saving
> Also, it is well know that one reason why people uses c:forEach in facelets, is because
this one create "full" components per each row. It is very easy to find articles on internet.
> Now, with jsf 2.0 we have partial state saving, so we have a chance to fix this one once
and for all. I tried fix this one per months (maybe years!), but talking with Martin Marinschek
on JSFDays, some ideas came out and finally it was found a possibility to fix this one using
the existing api and with little changes on the spec.
> The proposal is this:
> 1. Do not call UIComponent.markInitialState() on ComponentTagHandlerDelegate, as ComponentHandler
javadoc says, instead call it after PostAddToViewEvent are published on vdl.buildView(). We
need to call it from root to nodes, so the parent component is marked first. I know the place
where this call comes is from trinidad tag handler, but this call needs to be fixed in a more
predictable way.
> 2. Use an attribute on facesContext to identify when the VDL is marking the initial state
(in myfaces there is already an attribute called "org.apache.myfaces.MARK_INITIAL_STATE").
This is necessary to indicate UIData instances that it is time to save the full state of all
component children,
> 3. Allow UIData to hold a map where the key are client ids and the value are the deltas
of all components per row. This map should be saved and restored.
> 4. Change UIData.setRowIndex() to restore and save the component state.
> I'll attach a patch on this issue with the algorithm proposed (because it is based on
myfaces codebase). It was tested and it works. But note it is necessary to fix the javadoc
for UIData.markInitialState(), ComponentHandler and maybe vdl.buildView(), so the intention
is propose this change for jsf 2.0 rev A. Note this works only with PSS enabled because without
it we don't have a place to notify UIData instances that it is necessary to get the full state.
Also, note this patch preserve backward compatibility, because the old way to store/save is
applied after the full state is restored.
> Really, I have the strong temptation to apply some similar code on myfaces UIRepeat component
(because this class is private), but I prefer first ask to EG.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message