[jsr-314-open] FYI: onchange for radio and checkbox
by Jim Driscoll
Just an FYI.
Previously, in Mojarra, the default ajax behavior for components that
rendered radio and checkbox was onchange.
Unfortunately, this doesn't work in the way any user would expect in IE
- the onchange event will not fire until the component loses focus.
This makes it pretty much useless, as a user will click on a radio
button then wonder why nothing is happening. Note that all other
browsers fire the onchange event when you'd expect - without waiting for
a blur event first.
So, in the interests of making all browsers behave similarly, I've
changed the default behavior to onclick for those components. Now, when
you click on a radio or checkbox, the event will fire immediately.
Sadly, this means that we'll now also fire events even when the value
isn't changed (such as clicking multiple times on the same radio
button). In general, most application developers shouldn't notice the
difference, but it's conceivable that it might trip someone up at some
point. The alternative, adding an onclick="this.blur();", seemed more
likely to add problems than a simple change from onchange to onclick.
Just wanted to let you know where we stood with this. As always,
comments appreciated.
Jim
14 years, 8 months
[jsr-314-open] [ADMIN] Schedule note for EE6 regarding JSR-330
by Ed Burns
I'm forwarding this on behalf of Roberto Chinnici, spec lead for Java EE
6.
Roberto said:
RC> We have had to adjust our schedule to accommodate the addition of JSR
RC> 330 to the platform.
RC>
RC> Following are our target dates for the (full) JSRs in the platform:
RC>
RC> Phase 1: JSR-330
RC>
RC> * Handoff to JCP: 09/22/09
RC> * Voting: 09/29/09-10/12/09
RC> * Posting: 10/13/09
RC>
RC> Phase 2: Specifications with standalone RI and TCK (JSR-299, JPA, Bean
RC> Validation)
RC>
RC> * Handoff to JCP: 10/14/09
RC> * Voting: 10/20/09 - 11/02/09
RC> * Posting: 11/16/09
RC>
RC> Phase 3: Specifications where GlassFish is the RI (Java EE Platform,
RC> Servlet, EJB, Connectors)
RC>
RC> * Handoff to JCP: 10/28/09
RC> * Voting: 11/03/09-11/16/09
RC> * Posting: 11/24/09
RC>
RC> Let me know if you have any questions.
RC>
RC> --Roberto
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] inter-component and form-level validation
by Dan Allen
>From the jsr-314-comments mailbox comes this discussion between myself and
Mathias Werliz about inter-component validation. Unfortunately the
discussion progressed outside of the mailinglist, so the post below is the
aggregate of the individual messages. If there is confusion we can summarize
the discussion up to this point and continue the discussion on each
individual point.
---------- Forwarded message ----------
From: Dan Allen <dan.j.allen(a)gmail.com>
Date: Thu, Jul 9, 2009 at 2:09 PM
Subject: Re: [jsr-314-open] inter-component and form-level validation
To: "Werlitz, Mathias" <werlitz(a)adesso.de>
Cc: jsr-314-comments(a)jcp.org
On Thu, Jul 9, 2009 at 11:36 AM, Werlitz, Mathias <werlitz(a)adesso.de> wrote:
> Sorry for the late response. I’m very busy on a customer project at the
> moment, analysing JSF 1.2 (view state) and Facelets memory consumption on
> IBM Portal 6.1.
>
> I agree that there are two basic approaches to solve multiple-field /
> form-validation:
>
> 1. model based validation after the update model phase and
> 2. validating the converted values of multiple components
>
> In both cases there should be an easy way to assign the proper validation
> message to the originating input component or group of input components. With
> complex forms including inputs within naming containers like <h:dataTable>
> this may become quite complicated. Flattening the properties of the object
> graph for JSR-303 model validation does not seem to be a good idea in this
> case.
>
> I realize that JSR-303 isn't going cover every case. I must admit to still
> being the fence on how to best handle the situation you are citing...meaning
> can I do it comfortably with JSR-303 or not? I think a solid use case would
> help us test the limits.
>
>
>
> Well I simplified a test case – I’m unsure that this is easily done with
> JSR-303. Image a form with a master date and several additional dates. The
> number of the additional dates is dynamic – will be configured by the user
> (added and removed) or determined by the server.
>
> For simplicity there is only one multi-field validation rule: all
> additional dates must be after the master date. The view would look
> something like this (note: the list of additional dates is a list of a
> custom bean that stores the date and maybe additional data for every entry):
>
>
>
> <h:input id=”masterDate” value=”mybean.masterDate” />
>
> <h:datatable value=”mybean.myAdditionalDates” var=”item” >
>
> <h:input id=”addtionalDate” value=”item.additionalDate” />
>
> </h:datatable>
>
This could be done with JSR-303. You can have a validation annotation on the
array (or List) property holding the "after" dates and say that they must
come after the master date property. But again, the limitation is that it
has to happen after update model values.
Earlier when I said you have to flatted your model, I didn't mean you
couldn't use collections. You just can't easily validate a property on one
class against a property on another.
But pointing that aside, you could still accomplish w/ a regular JSF
validator if all conversions happened before the validation phase. Then you
just do something like:
<h:input id="additionalDate" value="#{item.additionalDate}">
<x:validateAfter id="masterDate"/>
</h:input>
>
>
>
> One downside of the model based validation is that the whole validation
> process is split up into two phases. That means the user may get the error
> messages in two bunches: first the errors of the validation phase and later
> the model errors. This can be quite confusing.
>
> The reality is, there are two validation phases in input-based
> applications. You simply cannot test some business validations if you don't
> have correct data to start with. I think the real point is to make sure that
> all input validation is handled together...and that business validation is
> really business validation. Having one date before another I agree is likely
> an input validation, not a business validation.
>
>
>
> Yes, that’s the point. At the moment JSF does make it very hard to do the
> input validation altogether.
>
There will likely always be two steps. The question is, can we get those two
steps right?
>
>
> To emphasize why there must be two validation phases, consider this case. You
> walk into an ice cream store and the employee asks you which flavor of ice
> cream you want. You say you want pizza. They say, "Sir, we don't have pizza,
> you have to pick and ice cream." Then you say that you want Heath ice cream.
> The employee says, sorry, we don't have that in stock. So the first is an
> input validation, the second is business. The employee couldn't have told
> you they don't have Heath ice cream in stock because the employee doesn't
> know what you want. It's not really that confusing.
>
>
>
> I agree with you, but in fact there are three steps where messages could be
> associated with an input field (convert, validation, business rules) and
> every step depends on the previous one.
>
>
> Well, one common requirement of our customers is: Display error messages as
> early as possible. Separating the validation into two phases makes this
> hard. Using good old Struts this example is no problem at all.
>
> That's because Struts effectively updated the model and then validated,
> moving all validation to the later phase. In JSF there is an understanding
> that values won't get assigned to the model unless they are valid syntax or
> type. You could throw that out the window and do all your validations after
> the update model values phase and get the same result. So we are questioning
> the fundamental guarantee of JSF (which, by the way, may need to be
> questioned).
>
>
>
> Well I think you got me wrong. The point is that in Struts you are able to
> store all the form data (as strings) in a form bean. You are responsible to
> make your own conversation. But because of that you are able to validate all
> input data including multi-field validation. On success you proceed to
> assign the values on your own to the real model.
>
>
>
> That’s not perfect. The only problem with JSF is that you don’t have this
> intermediate view on the form data where all converted values of the form is
> available altogether before deciding to move on to the update model phase.
>
I think we are saying the same thing. JSF applies the values directly to the
model by attempting to convert each value. Now, you could copy all
properties to a model with string properties and essentially coerce JSF into
skipping validation so that you can handle it yourself, but that really
defeats a large goal of JSF.
>
> I like your idea of dividing converting and validation. I think JSR-303
> model based validation is not sufficient. In the discussion with my
> college we had a similar idea as a workaround for JSF 1.2: We thought about
> a special custom validator added to all relevant input components that
> collects all converted input data from the components and the corresponding
> client ids/component instances. This also works fine with <h:dataTable>. The
> data could be collected with a Map or special validation-model bean. At the
> end of the validation phase another special form/multi-field validator
> (possible phase listener) is called with the collected data and invokes the
> validation logic. This way you get all converted data, components/client
> ids, the real model data is not touched at all and the whole validation is
> processed in one phase.
>
> It seems blatantly obvious to me that all conversion should happen before
> any validation occurs. I think the current situation is ridiculous and it's
> the root of why multi-field validation is so screwed up to begin with.
>
> See my previous comment… The question is: when this will change. JSF 2.0
> would be the right version. But I guess it’s already too late for such a
> fundamental change in the lifecycle – separating conversation and
> validation.
>
It won't be JSF 2.0. Hopefully JSF 2.1 or sooner.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
14 years, 8 months
[jsr-314-open] [NEW - MR] Add ExpressionFactory to "11.4.6 Delegating Implementation Support"
by Pete Muir
Hi all,
I would like to propose adding ExpressionFactory to the list of
classes required to support the decorator pattern. This is to aid
integration with CDI (JSR-299) implementations, which are require a
callback when EL expression evaluation completes; the necessary hook
into EL is via the ExpressionFactory. Adding ExpressionFactory to this
list would make implemetors have to jump through fewer hoops to obtain
the callback [1].
I propose this change to the MR so it can be used in the EE6 platform,
the target for JSR-299.
Changes to spec required
-----------------------------------
* Add ExpressionFactory to the list of classes required to support the
decorator pattern
* Add ExpressionFactoryWrapper class to support the decorator pattern
Changes to implementation required
--------------------------------------------------
* Add support for exposing and using wrapped ExpressionFactory
Impact on users and frameworks
--------------------------------------------
Users can now:
* call application.setExpressionFactory(new
WebBeansExpressionFactory(application.getExpressionFactory());
* configure a wrapping expression factory in faces-config.xml
<application>
<expressionFactory>org.jboss.webbeans.el.WebBeansExpressionFactory</
expressionFactory>
</application>
[1] Currently this is possible by wrapping the application via the
application factory and overriding the getExpressionFactory method
14 years, 8 months
[jsr-314-open] FacesContext API
by Lincoln Baxter, III
I notice that a lot of places in the JSF code call
assertNotReleased(facesContext), but is there any way to tell if a
context has been released?
The only method i see is "release()"
It would be useful to be able to determine the state of this field.
Feelings?
14 years, 8 months
Re: [jsr-314-open] No @PhaseListener annotation in JSF 2.0?
by Dan Allen
On Tue, Aug 4, 2009 at 4:47 PM, Ed Burns <Ed.Burns(a)sun.com> wrote:
> >>>>> On Sat, 01 Aug 2009 17:30:57 -0400, Neil Griffin <
> neil.griffin(a)liferay.com> said:
>
> NG> Hi Guys,
> NG> I can't remember -- was it a conscious decision to not have a
> NG> @PhaseListener annotation in JSF 2.0?
>
> Yes, we decided not to have it because we'd need lots of additional
> information related to the timing of discovery.
As I was driving down the road, this exact thought occurred to me. The
annotation would have to support ordering for phase listeners in the same
classpath and it would end up being pretty complicated.
Btw, it's the same reason interceptors have to be declared/activated in an
XML file for JSR-299.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
14 years, 9 months
Re: [jsr-314-open] Inconsistency between Spec and XSD for include-view-params
by Dan Allen
Followups from Ed.
NG> Hi there again Guys,
NG> Section 7.4.3 of the Spec has an example navigation-handler, which
NG> shows how to use the include-view-params feature:
NG> <redirect>
NG> <view-param>
NG> <name>userId</name><value>someValue</value>
NG> </view-param>
NG> <include-view-params>true</include-view-params>
NG> </redirect>
NG> However, using <include-view-params> as an XML element is invalid
NG> according to web-facesconfig_2_0.xsd
NG> But then, in section 7.4.2, the Spec talks about the "include-view-
NG> params" attribute on the <redirect /> element, like this:
NG> <redirect include-view-params="true" />
NG> The attribute syntax is what the XSD wants, and what Ryan's blog [1])
NG> claims as well.
I fixed the example to have tha attribute syntax. Thanks.
NG> Having said that, if the attribute way is the right syntax, then I
NG> think there are two problems with it:
NG> 1. Although I prefer attribute-syntax for XML, the faces-config.xml
NG> file doesn't use XML attributes anywhere. Instead, it uses the verbose
NG> <element>#PCDATA</element> syntax. So having an attribute on
NG> <redirect /> is really inconsistent with the rest of the file.
NG> 2. it's really inconsistent and weird to have dashes-in-the-name-of-an-
NG> xml-attribute. For example, we use camelCase for actionListener:
Your points are well taken, but we did decide on this syntax.
NG> <h:commandButton actionListener="#{myBean.actionListener}" />
NG> 3. The functionality/purpose of this include-view-parameters feature
NG> is really confusing. Does it mean:
>
NG> A. Include/exclude the f:viewParam stuff found in f:metaData of the
NG> from-view-id?
NG> B. Include/exclude the <view-param> children of the <redirect>
element?
NG> C. Both A & B?
This is covered in the section 7.5.2 where we talk about
getBookmarkableURL().
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
[jsr-314-open] Providing the ability to instantiate EzComp components in Java code
by Dan Allen
This is a somewhat old request from Lincoln Baxter that I don't think ever
made it to the list. After reviewing the message, I too feel it is worth
discussing for JSF 2.1.
---------- Forwarded message ----------
From: Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
Date: Thu, Mar 5, 2009 at 10:25 PM
Subject: [jsr-314-open] Providing the ability to instantiate EzComp components in Java code
To: jsr-314-comments(a)jcp.org
I feel there is value in the ability to instantiate an EzComp object in
Java so that a component tree can be built in a backing bean (or other
Class). JSF must be doing this in the background through Facelets, so
providing this ability in Java should not be too difficult.
Referencing an object by its namespace should be sufficient:
UIComponent comp = Application.createComponent(FacesContext, "
http://java.sun.com/jsf/composite/mynamespace:component").
Attributes would be assigned via the normal method:
comp.getAttributes().put("rendered", false);
This would greatly extend the reach of EzComp objects.
Thanks,
Lincoln
PS... re-posted here on suggestion of Ryan Lubke
14 years, 9 months
