Hi,
On Fri, Oct 9, 2015 at 3:43 AM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> - Multi-field Validation <f:validateWholeBean />
>
> [...]
>
> But it would be better if the validation is done as part of the parent
> UIForm instance. If there is an input component, there is always an UIForm
> instance in the component hierarchy. It sounds better to "subscribe" a
> component instance to the parent UIForm (an special facet for UIForm? or an
> special "validator" attached object?).
Maybe interesting to note that the OmniFaces version uses a TagHandler
and subscribes to several events.
E.g.
Initially to after restore view:
https://github.com/omnifaces/omnifaces/blob/2.1/src/main/java/org/omnifaces/taghandler/ValidateBean.java#L223
And then it registers two handlers, one before process validations,
and one after process validations:
https://github.com/omnifaces/omnifaces/blob/2.1/src/main/java/org/omnifaces/taghandler/ValidateBean.java#L303
The use case for the OmniFaces version though is not exactly the same,
but there are obviously strong parallels.
> - ui:repeat supports Map and Iterable
>
>
> UIData javadoc does not mention anything.
> IterableDataModel does not mention
> anything too.
I'm not sure if IterableDataModel should mention anything that it
doesn't mention now. It now says:
"IterableDataModel is an implementation of DataModel that wraps an Iterable.
This can be used to encapsulate nearly every collection type,
including Collection derived types such as List and Set. As such this
specific DataModel can be used instead of more specific DataModels
like ListDataModel and CollectionDataModel."
If you compare this to say ListDataModel:
"ListDataModel is a convenience implementation of DataModel that wraps
an List of Java objects."
Then I wonder what else it should say.
> The relevant section that should be updated in the spec is UIData.getValue()
> to include java.util.Map and IterableDataMode
Absolutely, I had this on my TODO list actually, but unfortunately was
not able to commit this before the EDR draft was cut.
Part of the change made it into the spec document, where 4.1.3.2. now says:
The current value identified by the value property is normally of type
DataModel. [P1-start-uidataModel]However, a
DataModel wrapper instance must automatically be provided by the JSF
implementation if the current value is of one of
the following types:
? java.util.List
? Array of java.util.Object
? java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
? javax.servlet.jsp.jstl.sql.Result
? java.util.Map (uses the wrapper for java.lang.Iterable by providing
access to java.util.Map#entrySet())
? Any other Java object is wrapped by a DataModel instance with a
single row.[P1-end]
This should however be:
The current value identified by the value property is normally of type
DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance
must automatically be provided by the JSF implementation if the
current value is of one of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
java.util.Map (uses the wrapper for java.lang.Iterable by providing
access to java.util.Map#entrySet())
Any other Java object is wrapped by a DataModel instance with a single
row.[P1-end]
Note that the new "java.lang.Iterable" and "java.util.Collection" are
missing in the EDR draft.
> - DataModel implementations can be registered
>
> Annotation javadoc of FacesDataModel is ok, but where is the javadoc that
> describe how a UIData instance uses the DataModel?
This is indeed something that still needed to be done. I left this one
open earlier to invite some discussion first.
> Again some documentation
> on UIData.getValue() is required (use getFacesContext().getApplication()....
> to do some magic).
@FacesDataModel is a CDI qualifier, so the runtime would be expected
to use CDI to obtain a matching instance.
I described this in some more detail here:
http://arjan-tijms.omnifaces.org/2015/07/jsf-23-new-feature-registrable.html
Feedback was solicited for here:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2015-06/message/1
The actual algorithm used and lookup did not get much feedback from
the EG, but there was a lively discussion about allowing wrappers for
existing types to be overridden. This is still an open feature request
which I hope we can address post EDR.
Kind regards,
Arjan Tijms