You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by mm...@apache.org on 2005/11/10 20:49:42 UTC

svn commit: r332361 - /myfaces/api/trunk/src/java/javax/faces/component/UIData.java

Author: mmarinschek
Date: Thu Nov 10 11:49:38 2005
New Revision: 332361

URL: http://svn.apache.org/viewcvs?rev=332361&view=rev
Log:
fix for MYFACES-782. Thanks to Simon Kitching.

Modified:
    myfaces/api/trunk/src/java/javax/faces/component/UIData.java

Modified: myfaces/api/trunk/src/java/javax/faces/component/UIData.java
URL: http://svn.apache.org/viewcvs/myfaces/api/trunk/src/java/javax/faces/component/UIData.java?rev=332361&r1=332360&r2=332361&view=diff
==============================================================================
--- myfaces/api/trunk/src/java/javax/faces/component/UIData.java (original)
+++ myfaces/api/trunk/src/java/javax/faces/component/UIData.java Thu Nov 10 11:49:38 2005
@@ -39,7 +39,46 @@
 import javax.faces.model.ScalarDataModel;
 import javax.servlet.jsp.jstl.sql.Result;
 
-/**
+/*
+ * ================================================
+ * Implementation Notes
+ *
+ * Each of the UIColumn children of this component has a few component
+ * children of its own to render the contents of the table cell. However
+ * there can be a very large number of rows in a table, so it isn't
+ * efficient for the UIColumn and all its child objects to be duplicated
+ * for each row in the table. Instead the "flyweight" pattern is used
+ * where a serialized state is held for each row. When setRowIndex is
+ * invoked, the UIColumn objects and their children serialize their
+ * current state then reinitialise themselves from the appropriate saved
+ * state. This allows a single set of real objects to represent multiple
+ * objects which have the same types but potentially different internal
+ * state.
+ *
+ * When a row is selected for the first time, its state is set to a
+ * clean "initial" state.
+ *
+ * Note that a table is a "naming container", so that components
+ * within the table have their ids prefixed with the id of the
+ * table. Actually, when setRowIndex has been called on a table with
+ * id of "zzz" the table pretends to its children that its ID is
+ * "zzz_n" where n is the row index. This means that renderers for
+ * child components which call component.getClientId automatically
+ * get ids of form "zzz_n:childId" thus ensuring that components in
+ * different rows of the table get different ids.
+ *
+ * When decoding a submitted page, this class iterates over all
+ * its possible rowIndex values, restoring the appropriate serialized
+ * row state then calling processDecodes on the child components. Because
+ * the child components (or their renderers) use getClientId to get the
+ * request key to look for parameter data, and because this object pretends
+ * to have a different id per row ("zzz_n") a single child component can
+ * decode data from each table row in turn without being aware that it is
+ * within a table. The table's data model is updated before each call to
+ * child.processDecodes, so the child decode method can assume that the
+ * data model's rowData points to the model object associated with the
+ * row currently being decoded. Exactly the same process applies for
+ * the later validation and updateModel phases.
  * @author Manfred Geiler (latest modification by $Author$)
  * @version $Revision$ $Date$
  */



Re: svn commit: r332361 - /myfaces/api/trunk/src/java/javax/faces/component/UIData.java

Posted by Martin Marinschek <ma...@gmail.com>.
done.

regards,

Martin

On 11/10/05, Simon Kitching <sk...@obsidium.com> wrote:
> Hi Martin,
>
> mmarinschek@apache.org wrote:
> > Author: mmarinschek
> > Date: Thu Nov 10 11:49:38 2005
> > New Revision: 332361
> >
> > URL: http://svn.apache.org/viewcvs?rev=332361&view=rev
> > Log:
> > fix for MYFACES-782. Thanks to Simon Kitching.
> >
> > Modified:
> >     myfaces/api/trunk/src/java/javax/faces/component/UIData.java
>
> Thanks for committing this (and the other patches I filed).
>
> There appears to be a minor problem with the way this got merged,
> though. The initial patch had the new documentation as a normal
> non-javadoc comment block. What's now in SVN has replaced the previous
> javadoc block with this section, though it still has the non-javadoc /*
> opening comment.
>
> I'm happy to see this new info in the actual class javadoc if you think
> that's appropriate. However if that's the case then the text needs to be
> updated to actually be javadoc (eg insert <p> at the appropriate
> places), and the opening comment set to "/**".
>
> Or is the use of a normal comment block intended?
>
> If you let me know what you would like, I'm happy to provide a patch to
> tidy this up.
>
> Regards,
>
> Simon
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: svn commit: r332361 - /myfaces/api/trunk/src/java/javax/faces/component/UIData.java

Posted by Simon Kitching <sk...@obsidium.com>.
Hi Martin,

mmarinschek@apache.org wrote:
> Author: mmarinschek
> Date: Thu Nov 10 11:49:38 2005
> New Revision: 332361
> 
> URL: http://svn.apache.org/viewcvs?rev=332361&view=rev
> Log:
> fix for MYFACES-782. Thanks to Simon Kitching.
> 
> Modified:
>     myfaces/api/trunk/src/java/javax/faces/component/UIData.java

Thanks for committing this (and the other patches I filed).

There appears to be a minor problem with the way this got merged, 
though. The initial patch had the new documentation as a normal 
non-javadoc comment block. What's now in SVN has replaced the previous 
javadoc block with this section, though it still has the non-javadoc /* 
opening comment.

I'm happy to see this new info in the actual class javadoc if you think 
that's appropriate. However if that's the case then the text needs to be 
updated to actually be javadoc (eg insert <p> at the appropriate 
places), and the opening comment set to "/**".

Or is the use of a normal comment block intended?

If you let me know what you would like, I'm happy to provide a patch to 
tidy this up.

Regards,

Simon