[jsr-314-open] Testing
by Max Lanfranconi
I believe this is working now.
Sorry about the inconvenience.
Regards,
Max
14 years, 10 months
Re: [jsr-314-open] clarification for unnamed insert
by Dan Allen
I was made aware of an additional detail that is needed in this
clarification request.
On Thu, Jun 18, 2009 at 3:58 PM, Ganesh <ganesh(a)j4fry.org> wrote:
> Hi Dan,
>
> There is one important difference between named and unnamed inserts. Named
> inserts get inherited , unnamed don't. If page a is based on template b and
> template b is based on template c then an unnamed insert in a can only be
> used in b while a named insert is also visible in c.
>
> Best regards,
> Ganesh
>
--
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.
14 years, 10 months
[jsr-314-open] clarification for unnamed insert
by Dan Allen
There is an important feature of Facelets composition templates--unnamed
insert--which I feel needs clarification in the pdldocs. The feature can be
described as follows:
The name attribute of the ui:insert tag is optional. When this attribute is
> excluded, the text that is inserted is any markup within the associated
> ui:composition, ui:component, ui:decorate, or ui:fragment that falls outside
> of a ui:define tag.
>
The pdldocs state that the name attribute on ui:insert is optional, but does
not specify the behavior when it is excluded. In fact, the documentation
misleads the developer by stating the following at the top of the ui:insert
page:
Inserts content into a template. That content is defined—with the ui:define
> tag— in either a ui:composition, ui:component, ui:decorate, or ui:fragment.
I'd like to request that the first quoted block be added after this
statement.
-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.
14 years, 10 months
[jsr-314-open] Cleaning up the composite PDL
by Jim Driscoll
The composite PDL currently has an exmaple component, which takes up a
rather large amount of space, and, I feel, doesn't really give a lot of
information for someone coming to the technology for the first time.
At the same time, important information like the specialness of the
values "action", "actionListener", "validator", and
"valueChangeListener" are buried in the name attribute of the
composite:attribute page.
I think we might be better served by removing the example (or else,
using a much smaller and simpler example), and including information
like the special names in that freed space.
What do you guys think? Am I off base?
I've filed the following spec issue 572 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=572
Jim
14 years, 10 months
[jsr-314-open] Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne
by Dan Allen
There is a standing invitation by Sun (from what I've been told) to host an
EG face-to-face meeting at Sun's San Francisco office after each JavaOne
event. This year there was a strong representation by the JSF group. Andy
and I both took notes and to be consistent with our policy on openness, we
felt compelled to produce a consolidated set of minutes and share it with
the JSR-314 community.
What follows are the minutes from the meeting, held on June 05, 2009 from
10:30AM - 1:00PM. If you were in attendance, feel free to supplement these
minutes with your own notes. Apologies if we left out any names of who was
in attendance. There was no formal sign in sheet.
The meeting began with introductions. Attendance:
Name, Project/Spec, Company
Andy Schwartz, JSR-314 EG, Oracle
Tedd Goddard, JSR-314 EG, ICEfaces
Greg Wilkins, JSR-315 EG, Mort Bay
Rajiv Mordani, JSR-315 EG Lead, Sun
Jason Lee, Mojarra/JSFTemplating, Sun
Justin Lee, Sun
Kin-Man Chung, JSR-245 EG Lead, Sun
Wenbo Zhu, Open Google Servlet Engine, Google
Dan Allen, JSR-314, Red Hat
Kito Mann, JSR-314, Virtua
Jan Luehe, Sun
Ed Burns, JSR-314 EG Lead, Sun
Roger Kitain, JSR-314 EG Co-Lead, Sun
(apologies if we missed anyone)
Topics:
- Andy gave an overview of the improvements that came with JSF 2.0. Features
mentioned:
- Ajax support. Though not a new technology, the first time JavaScript
APIs were introduced into Java EE. Cited RichFaces and ICEfaces as source of
ideas (he didn't mention Trinidad/ADF Faces, but they were sources as well)
- Standardization and improvement of Facelets. We could call it Facelets
2.0.
- Easy component creation: Built on the Facelets compositions, all aspects
of a UI component can be defined in template markup.
- Bookmarkable URL components and view parameters contributed by Red Hat.
Eventually led to the introduction of the metadata facet for non-rendering
components which can be processed before the page is built.
- System events. Used for more fine-grained control and interception of
the JSF life cycle. A more fine-grained approach than PhaseListeners.
- Exception queing so that root cause exceptions bubble out of the
FacesServlet.
- Bean Validation integration. Constraints defined with annotations.
- Partial state saving to reduce the overhead of having to generate and
save an entire component tree representation on each request.
- Annotation-based configuration, consistent with the direct the platform
is heading
- Component behaviors, a mechanism for enhancing components with
additional behaviors that are not explicitly defined by the component author
- Kin-Man reported that there will be a maintaince release for JSR-245
- The focus is on EL improvements
- EL will include support for method parameters
- New version of EL/JSP will be aligned as "2.2"
- Dan asked to discuss other features of EL that are supported by JBoss EL
- EL should support calling static methods in addition to non-static
methods (just treat static like member method)
- EL should recognize namespaces in EL names, with API support to "import"
a namespace (should involve JSR-299, which is introducing qualified EL
names)
- Rajiv gave update of JSR-315
- Annotation-based configuration
- Improved security/login routine; preemptive login now possible
- web.xml fragments
- Programmatic registration of listeners, filters, servlets
- Introduced the ServletContainerInitializer API, which the JSF members
didn't seem to be very familiar with
- Rajiv made the comment that the Web Tier spec may be able to rev more
quickly than JEE as a whole
- Greg requested that we discuss ordering with regard to web.xml fragments
- Discussed the ordering of servlet life cycle callbacks
- Similar in nature to the JSF faces-config.xml ordering
- Begin/end callbacks compilments should be called in reverse order on
exit (e.g. filters)
- Point source callbacks should be executed in defined order (no
reversing) (e.g. property listeners)
- Exclusion mechanism should prevent resources from being located in it's
classpath entry when using getResources() and how this affects JSF
- Rajiv and Ed are going to sync up to make sure that we are consistent on
ordering behavior across Servlet 3.0/JSF 2.0.
- Dan asked for a clarification in servlet spec on when the
ServletRequestListener#requestDestroyed() is called when an exception is
raised
- Tomcat notifies the listener that the request has been destroyed before
rendering the error page; this breaks framework reliant on the request
boundaries such as JSR-299
- The group agreed that the notification should be fired after the error
page is rendered, just like when an include or forward is dispatched to the
RequestDispatcher
- A lengthly discussion pursued regarding annotation scanning
One concern is that various EE specs need to scan for annotations, which may
lead to multiple scan passes, and possibly inconsistent behavior regarding
how paths to scan/exclude are determined. To avoid performing an extra
scan, servlet EG members recommended that JSF implementations leverage the
new ServletContainerInitializer API. This allows the servlet container to
call JSF implementations back with any classes that may be of interest to
JSF (as specified via the @HandlesTypes annotation). JSF 2.0
implementations do not/should not require Servlet 3.0, but could possibly
leverage this mechanism when running in 3.0 containers.
Dan raised concern that the servlet spec is too narrow to deal with all
annotation scanning needed in Java EE, so likely this is only going to be a
partial optimization. He mentioned that the Java EE EG and the JSR-299 EG
should be brought into this discussion.
Towards the end of the meeting Ed provided thoughts on what's next for
JSF... Ed is collecting a list of issues to be addressed in an MR. Ed
would like to hold off on any major changes on top of 2.0 until the
community has had a chance to adopt 2.0 and help identify key issues.
Others (Dan, Andy) expressed interest in seeing some of the more pressing
smaller issues addressed more quickly, either via an MR or, if not possible,
via a 2.1 rev of the spec.
Ed also raised the idea of a component-centric JSR for JSF in order to
address concerns about the limited set of standard components. We'll need
to have some more discussion to scope this out and understand the
implications for existing component vendors. Ted Goddard suggested that one
obvious place where standardization would be across the models defined by
the various component frameworks.
--
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.
14 years, 11 months
[jsr-314-open] Adding a description field to the JavaScript event payload
by Jim Driscoll
I'd like to propose that we add a freeform text description field to the
JavaScript event and error payload.
This would allow for user readable descriptions to go along with errors
like the infamous "MalformedXML" error.
I think this could fit into an errata, since:
1) It's got no backward incompatibility impact.
2) It's a single line in the spec.
3) It's (almost) trivial to implement.
and most importantly:
4) We really should have had this in there in the first place, and it's
omission was really more of an oversight than a deliberate choice.
Thoughts?
I've opened up spec issue 570 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=570
And yes, I made it a P1.
Jim
14 years, 11 months
Re: [jsr-314-open] inter-component and form-level validation
by Dan Allen
Mathias,
There was some discussion of multi-field and form-level validation at
JavaOne and therefore was on my list of items to raise with the EG list.
Here's where we left off.
As you have noticed, multi-field validation is not in the JSF 2.0
specification. From the point when I joined the EG, there were no proposed
solutions that could be agreed on and given the importance of getting this
issue right, it was deferred. I have two recommendations for accomplishing
this requirement, which I will cover in this message.
You are correct that the current JSR-303 integration does not handle
multi-field validation. But I believe that JSR-303 can become the preferred
solution for multi-field validation in the future. That brings me to my
first recommendation.
Post-update module validation:
The JSR-303 integration currently works by leveraging the pre-binding
validation method Validator#validateValue() from the Bean Validation API.
This method validates all constraints placed on the property if the value
supplied would be assigned to the property (intent). This is consistent with
how the built-in validators work in JSF today.
However, this approach leaves behind much of the capabilities of JSR-303.
The remainder of the validation mechanisms in JSR-303 require the object to
be in its final state. Therefore, I believe that we need to introduce a
validation step that occurs at the end of the Update Model Values phase.
Presumably there would be a declarative way of indicating which objects or
properties should be passed through the Validator, perhaps using EL
expressions.
The one restriction is that to validate two fields against one another (such
as the return date must be after the departure date), the properties have to
be siblings (on the same class). However, it would be trivial to introduce
composite objects that can make properties appear as siblings even if they
happen to be on different objects.
So what is the difference between pre-binding and post-binding validation?
The pre-binding ensures that the value you are assigning to the property is
sane, to prevent difficult to catch errors such as NumberFormatException.
The post-binding validation is for logical constraints, such as comparing
dates or requiring a valid city given a state selection.
However, there are still cases when you might want an alternative approach
to JSR-303. For this case, I think the onus falls on the validator to
enforce the value of related fields in the form. But in order for that to be
a reasonable requirement, one critical change must be made to JSF.
Currently, conversation and validation are performed one component at a
time. If you want to do a multi-component validation, you need to ensure
that both components have been converted. This requires that you put the
validator on the component which is visited last in the component tree.
Otherwise, you have to convert and validate the related component.
A far better approach in my mind would be to convert all the fields, then
validate all the fields, in two distinct steps. Then, when you are writing a
validator, you can depend on the fact that all fields have already been
converted and the validator can focus on simply validating. Then it becomes
simple to develop custom validators that do multi-field validation in a
declarative manner.
Let's discuss these two solutions. Perhaps both are needed.
-Dan
On Thu, Jun 11, 2009 at 8:39 AM, Werlitz, Mathias <werlitz(a)adesso.de> wrote:
>
> Hi JSF2 group,
>
> what happened to the specification goal of "inter-component and form-level
> validation"?
> I found no reference in the current spec. Support for field-level
> validation only makes it quite hard to develop complex business forms.
> Validation of one field frequently depends on values in other fields of the
> form. There are already some strategies for solving this on component or
> model-level, but no tightly integrated standard solution. The JSR 303
> integration won't solve this either.
>
> A simple example is a group of (optional) address-fields (name, forename,
> street, city, zip ...) - if the user fills one of the fields, all others are
> required. If the user does not fill any field no address-field is required.
>
> Regards,
> Mathias Werlitz
>
>
>
--
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.
14 years, 11 months
[jsr-314-open] annotation scanning (was Re: Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne)
by Dan Allen
On Thu, Jun 11, 2009 at 4:21 PM, Pete Muir <pmuir(a)redhat.com> wrote:
> As I understand it, the problem here (especially with the Servlet spec) is
> that there is no limiting which jars can contain annotations, so every class
> must be checked. There are various optimizations you can do (the obvious one
> is to exclude all known library jars which don't contain annotations). NB
> this isn't such a problem with 299 as it carefully limits which jars need to
> be scanned.
Exactly. The very definition of a scan is widely divergent. Seam (and Web
Beans) have taken the approach of looking for a marker file using
getResources() and scanning the associated classpaths. I brought up this
style in the meeting.
The approach by JSF is to look in WEB-INF/classes and in each JAR file in
WEB-INF/lib. This is problematic if you happen to have an external
classpath. One case is when you run Jetty from Maven. A more common case is
when you have another EE module, such as an EJB-JAR.
The Servlet spec seems to be suggesting that every classpath visible to the
application is going to be scanned, which is terribly reckless in my opinion
(I'm sure others).
So we need consistency in what is scanned, and then need a way to leverage a
container-provided scanning mechanism, if available (obviously in a
standalone environment you have to bring your own scanner).
-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.
14 years, 11 months
[jsr-314-open] Adding an extension mechanism to the JavaScript event data payload
by Jim Driscoll
And as long as I'm discussing the JavaScript event data payload, one
thing that got stripped out during the specification process was the
ability to extend the payload object in a compatible way.
At least one of the proposals I made was to simply prefix any property
to the object that's implementation specific with a "x". Another way
could be defining a "extension" object that's a property of the data
object, hanging all impl specific properties off of there.
If we don't have that extension mechanism, then adding something like a
description property to that object becomes a compatability problem -
since a future version of the spec may add a description property,
breaking existing apps.
Again, I think that defining something like this could fall into an Errata.
Thoughts?
I've filed Issue 571 to track this issue.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=571
Jim
14 years, 11 months
