Re: [jsr-314-open] inter-component and form-level validation
by Ed Burns
>>>>> On Tue, 14 Jul 2009 19:56:11 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
MW> It seems blatantly obvious to me that all conversion should happen
MW> before any validation occurs. I think the current situation is
MW> ridiculous and it's the root of why multi-field validation is so
MW> screwed up to begin with.
MW> See my previous comment=E2=80=A6 The question is: when this will
MW> change. JSF 2.0 would be the right version. But I guess it's
MW> already too late for such a fundamental change in the lifecycle
MW> & separating conversation and validation.
DA> It won't be JSF 2.0. Hopefully JSF 2.1 or sooner.
>>>>> On Sun, 26 Jul 2009 00:47:35 +0200, Norbert Truchsess <norbert.truchsess(a)t-online.de> said:
NT> My vote goes to change this in JSF 2.1 by changing the way this is
NT> handled by separating convertion and validation into two separate steps
NT> (thus effectivly adding an additional step into the jsf lifecyle).
>>>>> On Tue, 28 Jul 2009 14:16:27 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> 1) Validation is happening in two places, once before model update
DA> and once after, which confuses the user (they have to submit the
DA> form twice to get all the validation errors)
DA> 2) Inter-component validation is very complex and in some cases, not
DA> possible without a lot of code stealing from the implementation
DA> There are two root causes that have been identified:
DA> 1) The assumption that validation should happen before model update,
DA> thus making it possible to only partially use Bean Validator (and
DA> the like)
DA> 2) The coupling of conversion and validation in the life cycle (each
DA> component is converted then validated in turn)
DA> The second root cause is easier to solve than the first. Norbert and
DA> I (perhaps others as well) believe everything would get a whole lot
DA> simpler to start with if conversion was completed before validation
DA> began so that when inter-component validation is attempted, all
DA> values are in their converted state.
PM> However this does introduce another "layer" - if conversion fails then
PM> the no validators get run.
Yes, that is true.
I'm ok with this, but let's enumerate some backwards compatibility
concerns. Currently the responsibility to initiate conversion is
assigned to the UIInput.validate() method. Within that method,
getConvertedValue() is called and the result is kept as a local variable
which is passed to validateValue(). If we were to break this process
into two separate lifecycle phases, we'd need some place to store the
return from getConvertedValue() so that it can be accessed in validate()
and passed to validateValue(). For this reason, I suggest we introduce
a new protected "convertedValue" property and rigidly define the
lifetime of this property.
Note that it is ValueHolder that has the owning reference to the
Converter. Therefore, I think we would need to have a
processConversions() method on UIComponent, which we'd override on
UIOutput to call a new convertValue() method. We'd move
getConvertedValue() up from UIInput to UIOutput, and make convertValue()
call it.
PM> I believe to address both (1) and (2) we have to address this problem
PM> anyway, as I would be very unhappy to end up with the worst case
PM> scenario of: conversion failures -> return to user -> property
PM> validation failures -> return to user -> cross component validation ->
PM> return to user -> business logic error -> return to user -> render
PM> next page.
Pete, I don't see any way around having to go back to the user. I think
first class client side validation can make this painless. Of course,
we would still do the same validation on the server side. I think this
could possibly be accomodated with a JSF specific JSR-303 annotation
that is somehow indicated at the point of the constraint declaration.
Something like
public class UserBean {
@Email
@AlsoRunOnClient
string email;
public String getEmail() {...}
public void setEmail() {...}
}
We'd have another bunch of stuff in the jsf.js file, but that's why we
have staked it out, so we can add stuff to it.
PM> I think we should also check that everyone agrees that cross-component
PM> validation should provide first class support for BOTH (a) custom JSF
PM> validators AND (b) model based. My vote would be to require (b) and
PM> make a best effort at (a), but I suspect other disagree ;-)
I think we should go for (b) and forget (a).
AS> solve. For example, I think we should take a look back at use cases
AS> like this:
AS> http://www.jroller.com/robwilliams/entry/jsf_multi_field_validation_not
AS> And try to figure out which solution (or solutions) would have helped
AS> the obviously frustrated user solve the problem in the least painful
And there's also this
http://insights2jsf.wordpress.com/2009/08/06/multivalidator-component-all...
I like this approach for its practicality.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] [616-ajaxInlineScripts] Re: eval of inline scripts
by Ed Burns
>>>>> On Wed, 19 Aug 2009 14:13:12 -0700, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> I've filed spec bug 616, eval of inline scripts.
JD> Currently, the specification doesn't require that <script> tags get
JD> evaluated during update or insert operations on the client, nor does it
JD> specify how they be evaluated if they are included.
If java.net was responding, I'd leave this comment in the issue as well,
but, yes, I agree.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] eval of inline scripts
by Jim Driscoll
I've filed spec bug 616, eval of inline scripts.
Currently, the specification doesn't require that <script> tags get
evaluated during update or insert operations on the client, nor does it
specify how they be evaluated if they are included.
Right now, the RI doesn't eval these included scripts - but we plan to
do so, as does MyFaces. Given that this behavior was the default for
many "legacy" JSF Ajax solutions, I think that's the general user
expectation as well.
Although there is a eval operation in the XML schema, this is
unfortunately insufficient - renderers for custom components, for
instance, will already be wrapped in an update operation, and cannot
easily do a separate eval operation in the RI.
Just wanted to give warning to anyone who may be relying on us *not*
doing script eval that's it's going in for FCS, as well as making the
case for it's inclusion in the next rev of the spec.
Jim
14 years, 8 months
Re: [jsr-314-open] [NEW - MR] Add ExpressionFactory to "11.4.6 Delegating Implementation Support"
by Ed Burns
>>>>> On Tue, 18 Aug 2009 13:16:06 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> I'm not sure why this requires any changes to Unified EL, the change
PM> is needed in JSF (see changes I suggested).
Perhaps I misunderstood your feature request, then. Let me restate it
in my own words and you can tell me if I understand you.
You want to make it so the ExpressionFactory instance returned from
Application.getExpressionFactory() is subject to the decoration
construction pattern that we use for all the rest of our decoratable
artifacts. Is that correct?
The problem is that the JSF spec says the application must simply call
JspFactory.getDefaultFactory().getJspApplicationContext(servletContext).getExpressionFactory();
We don't maintain a reference to the instance that is returned. Even if
we started doing so, and performed the wrapping as an spec requirement
of the javax.faces.application.Application implementation, you'd miss
out on anyone who is creating expressions with the ExpressionFactory
that you get from any other way than the Application instance.
In other words, I assert that to satisfy your request, we have change
the contract of how the canonical ExpressionFactory instance is created,
which is currently the responsibility of the EL implementation.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
Re: [jsr-314-open] [NEW - MR] Add ExpressionFactory to "11.4.6 Delegating Implementation Support"
by Ed Burns
>>>>> On Tue, 28 Jul 2009 14:00:51 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> Hi all,
PM> I would like to propose adding ExpressionFactory to the list of
PM> classes required to support the decorator pattern. This is to aid
PM> integration with CDI (JSR-299) implementations, which are require a
PM> callback when EL expression evaluation completes; the necessary hook
PM> into EL is via the ExpressionFactory. Adding ExpressionFactory to this
PM> list would make implemetors have to jump through fewer hoops to obtain
PM> the callback [1].
PM> I propose this change to the MR so it can be used in the EE6 platform,
PM> the target for JSR-299.
>>>>> On Tue, 11 Aug 2009 19:23:52 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> +1
DA> Has an issue report been created for this yet?
No, but the right issue tracker is <https://uel.dev.java.net/>.
Thankfully, this could just be specified as changes to the newInstance()
method on javax.el.ExpressionFactory.
Note that this can already be achieved by decorating the application
instance itself and overriding the getExpressionFactory method.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Lincoln Baxter, III
So here's one of those, "why is this different than that?" questions:
Unless I'm mistaken, ui:repeat is not a component and therefore cannot
be bound to a backing bean, but -- would it make sense to support
something *like* <h:dataTable> in order to support determining the
selected row on action events and value change events? A component that
would privide a bindable DataModel / List<Object> row access like
<h:dataTable>?
My use case is this:
* Managed Bean contains a List of objects
* Each object rendered to screen with input field
* User submits the input field (with a command link or button,
etc)
* ManagedBean needs to take action on the appropriate row values
I have a list of objects - I need to render them onto the screen (not
necessarily in an HTML table, maybe a <ul> would be nicer) but I can't
use <ui:repeat> because each row has a commandLink, and I need to be
able to determine which row the user clicked on in order to take the
appropriate action.
EL2 helps with this, but... now what if I have a ValueChangeEvent for an
input field on each <li> row? Now I can no longer use EL2 to pass the
row into the ValueChangeListener, and I would have to use something like
<f:setPropertyActionListener> which is not only getting increasingly
complicated, but I'd also have to set an attribute insidethe VCL itself,
or in a bean VCL knows about - then referencing it - which is terribly
ugly. Now try to fit all that into a composite component and it gets
really ugly to try attaching tons of VCLs or ALs or SPALs to values
inside the component.
Am I attacking this problem in the wrong way? Is this one of those
things that has an easy solution I'm not seeing? Or is this a genuine
gap?
--Lincoln
14 years, 8 months
Re: [jsr-314-open] FacesContext API
by Ed Burns
>>>>> On Tue, 11 Aug 2009 11:23:24 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> With that said, I do believe that it would be reasonable to have a
DA> getReleased() method to compliment release() as is true of the
DA> getResponseComplete() and getRenderResponse() methods for
DA> responseComplete() and renderResponse().
I've filed issue [FacesContextReleased-614] on this.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
Re: [jsr-314-open] No @PhaseListener annotation in JSF 2.0?
by Ed Burns
>>>>> On Wed, 05 Aug 2009 15:54:16 -0500, Jason Lee <jason(a)steeplesoft.com> said:
JL> Ryan and I had the same discussion on IRC. Makes sense, I guess, but
JL> I wish there were a way around that. :|
Yes, and this complexity is why we punted on having @FacesPhaseListener.
Because we expect people to use SystemEventListener for this sort of
thing now, I think we should let the decision to not have
@FacesPhaseListener stand.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] Editorial suggestions on spec document.
by Ed Burns
While working on the JSR-303 content for my upcoming JSF 2.0 book [1], I
found a few small edits that should be made in the spec document. I
must say, though, that the document is excellent and Emmanuel should be
commended for his excellent English. Bravo.
* Example 2.1
The Severity example class shows Info and Error using the "extends" Java
programming language keyword, but ConstraintPayload is an interface.
Therefore, I think they should use the "implements" keyword instead.
It would be nice to show in the example how to get access to the payload
and what you can do with it.
* Example 2.3
the age() property is typed to return Audible. Shouldn't it retun
Audible.Age?
* Consider inserting a manual page break before example 2.7.
* After example 2.12, you say, "a future version of the specification
will likely allow it in the future." Using "future" twice is
redundant.
* Section 3.1.2
Java Persistence and Bean Validation
"place your Bean Validation constraint annotations on the same
element (field or getter) than your Java Persistence annotations"
Should be
"place your Bean Validation constraint annotations on the same
element (field or getter) *as* your Java Persistence annotations"
* Section 3.5.2
Check the content and formatting of the code block that shows the
declaration of the TraversableResolver interface. It has extra
copy-paste content in it.
[1] http://bit.ly/edburnsjsf2
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
