[jsr-314-open] Help Understanding Facelets compiler
by Ed Burns
Hello Team,
I sat down to write some of the Facelets javadocs and quickly ran into
1st order ignorance about the design of the compiler.
Can someone please write up a little text document about the classes in
the compiler, their lifetimes, their relationships to eachother, and
their cardinalities?
Attached is a sketch-in-progress that I have as the package.html in
javax.faces.webapp.facelets.pdl. Maybe someone can see what I'm going
for with this. There are impl details in there, but those will be
stripped out and replaced with sufficiently non-normative text.
Any help would be greatly appreciated.
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
Re: [jsr-314-open] Roger or Andy: high level question on Component Behaviors (was: Re: Behavior API overview)
by Ed Burns
>>>>> On Sat, 14 Mar 2009 23:02:52 -0400, Andy Schwartz <andy.schwartz(a)ORACLE.COM> said:
AS> So this pulls in the "foo.js" JavaScript library any time a Foo
AS> component is present in the component tree:
AS> @ResourceDependency(name="foo.js")
AS> public class FooComponent extends UIComponentBase { ...}
AS> And this attaches an Ajax behavior to the "mouseover" event on a
AS> FooComponent instance, causing an Ajax request to be fired when the user
AS> mouses over the component's content:
AS> <my:foo id="bar">
AS> <f:ajax event="mouseover"/>
AS> </my:foo>
AS> Roger -
AS> Let's sync up tomorrow and see if we can make sure that the spec is
AS> clear on this.
Ok, great. Please do.
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
Re: [jsr-314-open] [ADMIN] JSF 2.0 Spec Snapshot
by Simon Lessard
Hi all,
I'm terribly sorry for the late review, but here are some minor API/JavaDoc issues I found while locally integrating those change to MyFaces :
________________________________________________________________________
javax.faces.application.Application
public abstract void addBehavior(String behaviorId, String behaviorClass);
public abstract Behavior createBehavior(String behaviorId) throws FacesException;
public abstract Iterator<String> getBehaviorIds();
All those methods should not be abstract and throw UnsupportedOperationException to be consistent with other methods added after JSF 1.1.
On that UnsupportedOperationException, would it be possible to revisit that strategy for 2.1? I know we provide that for binary backward compatibility, but in real life usage it's only dust thrown in the eyes of users imho. In fact, it only delays the error until the application is executed and it's then harder to fix issues as you have to redeploy the application after every fixes, as opposed to compilation errors that all show up at the same time. For example, 2.0 API have UIViewRoot depend on PartialViewContext accessed through a new getPartialViewContext on the FacesContext. By default that method now throws an UnsupportedOperationException so if the user application use a FacesContext decorator, the application WILL crash at runtime while a real abstract method would have warned the user about the missing method that he could have redirected to the wrapped instance. Also, since 2.0 provides a lot of new Wrapper classes, assuming users will start using them, then adding new abstract methods should no longer be much of an issue since by default the provided Wrapper classes will already take care of redirecting those.
_____________________________________________________________________________
javax.faces.component.behavior.AjaxBehavior
public Set<BehaviorHint> getHints()
public String getRendererType()
Those methods are either not needed as they only call super (copied doc), or the JavaDoc is incorrect.
_____________________________________________________________________________
javax.faces.component.UIComponent
public void unsubscribeFromEvent(Class<? extends SystemEvent> eventClass, ComponentSystemEventListener componentListener)
The JavaDoc says 'When doing the comparison to determine if an existing listener is equal to the argument componentListener (and thus must be removed), the equals() method on the existing listener must be invoked, passing the argument componentListener, rather than the other way around.' However equals should always be commutative so I don't really know if such really low and strange implementation detail should be part of the JavaDoc
_____________________________________________________________________________
javax.faces.component.UIComponentBase
public FacesListener[] getFacesListeners(Class clazz)
Method is not generic enabled, it should be
public FacesListener[] getFacesListeners(Class<? extends FacesListener> clazz)
Also, on a slightly different but related note, BehaviorBase class also has the listener handling methods, but does not provide the getBehaviorsListeners method, should it be added for consistency purposes?
_____________________________________________________________________________
javax.faces.model.DataModel
public Iterator<E> iterator()
The only way for the returned Iterator to get row data is to set the model's rowIndex (because there's no getRowData(int index) method on DataModel). Therefore, the model become inherently not thread safe. I believe such limitation should be mentioned in the class' documentation. Of course, DataModel were already not thread safe in nearly all implementation so it's only an extra documentation needed here for new users imho so they don't try to place those in application scoped beans.
Also since Java 5.0 allows return type covariance for overridden methods I think we could change the various getWrapped() methods to return relevant type (E[]m List<E>, etc.)
_____________________________________________________________________________
javax.faces.webapp.pdl.facelets.FaceletContext
public static final String FACELET_CONTEXT_KEY = "com.sun.faces.facelets.FACELET_CONTEXT";
Can we get a "javax.faces.XYZ" constant value for that please?
_____________________________________________________________________________
javax.faces.event.ExceptionQueuedEventContext
public static final String IN_AFTER_PHASE_KEY;
public static final String IN_BEFORE_PHASE_KEY;
The spec does not define any value at all for those two constants.
_____________________________________________________________________________
That's about it!
Regards,
~ Simon
________________________________
From: JSR 314 Open Mailing list on behalf of Ed Burns
Sent: Wed 3/11/2009 10:51 AM
To: JSR-314-OPEN(a)JCP.ORG
Subject: Re: [jsr-314-open] [ADMIN] JSF 2.0 Spec Snapshot
>>>>> On Thu, 05 Mar 2009 11:00:20 +0000, Pete Muir <pmuir(a)REDHAT.COM> said:
PM> Ed,
PM> Here are some questions:
PM> * is delta state saving in this revision? The state saving stuff is
PM> still in an appendix, and I find it hard to check.
It's not in the revision. The stuff in the appendix is now quite stale
due to the lifecycle changes introduced to accomodate Andy Schwartz and
Dan Allen's concerns over the performance of view metada gathering.
Ryan is currently reworking the state saving branch, including Martin's
recent patches, but it's tricky. The state management revision may have
to be slipped to 2.1.
PM> * Issue 450 (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=450
PM> ) still hasn't been merged into the spec - I've asked about this one
PM> multiple times. Can we get this merged in?
THANKS for your persistence. This email will include an action plan for
Roger and I to follow, and this will be on it.
PM> * the big changes due to view parameters don't appear to be merged
PM> in?
See action plan below.
PM> Otherwise, the areas I have been involved in look good:
PM> * exception handling
PM> * bean validation
Thanks for the oversight.
>>>>> On Thu, 05 Mar 2009 16:32:18 +0100, Martin Marinschek <mmarinschek(a)APACHE.ORG> said:
MM> Hi Ed,
MM> my feedback below. I already (wrongly) sent these using my Gmail-address,
MM> but I guess (hope) these mails didn't make it...
I've put these into the action plan.
MM> also, should I send out the patch-proposal that I made and the
MM> follow up discussions I had with Leonardo to the EG? Pete and Andy
MM> seemed to be interested...
AS> Is this regarding delta state saving? I am definitely curious to hear
AS> where we ended up with this.
As mentioned above, late breaking view parameter changes have impacted
our ability to include the state saving changes into 2.0.
>>>>> On Thu, 05 Mar 2009 17:26:44 +0000, Pete Muir <pmuir(a)REDHAT.COM> said:
PM> Another couple more after talking to Dan:
In action plan
PM> RegexValidator
ACTION PLAN for Roger and Ed.
These need to be done to the spec.
rogerk * 10.3.1.1: in table 10.3, the f:ajax attribute is called event -
in several paragraphs around this, events - which one is true?
It is now "event". Roger should be taking care of this soon.
edburns * Merge spec issue [SelectItemsCollection-450] into spec.
edburns * Merge all view parameter changes into spec.
edburns * 3.1.8: should the tree-visitor be mentioned here?
edburns * 4.1.18.4: shouldn't this reference AfterAddToViewEvent?
edburns * 5.4.1: seems to have old spec language (language on error
handler says that only predestroy does not call through to it)
edburns * 6.1.14: managed-bean-scope can now be view on top of none,
request, session, application - can it also be flash? I don't see this
mentioned anywhere.
edburns * the spec language for the BeanValidator is light compared to
other validators
(see 3.5.5 - for example RegexValidator's description vs. BeanValidator
Thanks for your feedback!
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
Re: [jsr-314-open] Roger or Andy: high level question on Component Behaviors (was: Re: Behavior API overview)
by Andy Schwartz
Ed -
@ResourceDependency annotates a component class to denote that the class
has a dependency on a particular resource (eg. a JavaScript library, or
style sheet).
Client behaviors allow executable scripts (ie. event handlers) to be
attached to individual components at event points defined by the
component class.
So this pulls in the "foo.js" JavaScript library any time a Foo
component is present in the component tree:
@ResourceDependency(name="foo.js")
public class FooComponent extends UIComponentBase { ...}
And this attaches an Ajax behavior to the "mouseover" event on a
FooComponent instance, causing an Ajax request to be fired when the user
mouses over the component's content:
<my:foo id="bar">
<f:ajax event="mouseover"/>
</my:foo>
Roger -
Let's sync up tomorrow and see if we can make sure that the spec is
clear on this.
Andy
Ed Burns wrote On 3/14/2009 9:49 PM ET:
> Roger just added section 2.5.9 to the spec, to provide a high level overview of the
> Component Behavior feature. In this section, Roger says:
>
> "Component behavors provide a mechanism for enhancing existing components with
> functionality that is not an inherant part of the component itself. The first type of
> component behavior that is introduced is client behavior. Client behaviors provide the
> ability to attach client side scripts to components."
>
> As Roger has been driving component behaviors, I have not been paying close attention
> to the feature. Therefore, I read Roger's overview section with great interest. When I
> read the above text, I had to ask: If client behaviors allow attaching a client side script to
> components, how is that different from having an
> @ResourceDependency(name="script.js")?
>
> Roger, this basic question needs to be addressed in the overview.
>
> I've uploaded the PDF that contains 2.5.9 and other kinds of Overview sections as well.
> It's at <https://javaserverfaces-spec-
> public.dev.java.net/files/documents/1936/129539/JSF_20090314.pdf>.
>
> ACTION: Andy or Roger, please answer my basic question.
>
> Thanks,
>
> Ed
>
15 years, 1 month
[jsr-314-open] So what's left for 2.0?
by Andy Schwartz
Gang -
Seems like we've still got a few loose ends that we either need to
finish up for 2.0, or, if not, agree to punt on until 2.1. Based on
recent email threads, these include:
1. State saving
Martin had raised concerns about compatibility between the new tree
visitor-based state saving implementation and the jstl tags. It sounded
like Martin had a patch - but not sure whether the patch addresses these
problems fully. Also not sure whether we are providing delta state
saving. Can anyone clarify what the plan is for 2.0?
2. f:ajax/f:validateBean wrapping behavior
For consistency I think we want to move f:validateBean over to a
wrapping strategy that is closer to f:ajax, but want to hear Dan's take
on this. (Dan - I can help walk you through the f:ajax implementation
if you have questions about this.)
3. Portlet support
See the "Portlet support - remaining issues" thread for known open issues.
4. Ajax issues
We've got a few minor API-related items that we need to address:
- <f:ajax> should support an "immediate" attribute.
- The AjaxBehavior API still needs some cleanup in order to make it
usable for programmatic cases (eg. need to add typesafe accessors)
- Seems like we never got around to adding support for the @this, @form,
@all, @none keywords in the execute/render lists for
<f:ajax>/jsf.ajax.request(), though think we do want to support these.
4. Behavior issues
The main open issue here is that we need to confirm that Behaviors work
well with composite components, which I believe that Alex has been testing.
Are there any other open issues? Does anyone have anything to add to
the above comments?
Andy
15 years, 1 month
[jsr-314-open] Behavior API overview
by Andy Schwartz
Gang -
I wanted to send one last email on the new Behavior API to help folks
who were not able to keep up with the progress on this API as it
evolved. Much of this information has been covered in previous emails,
but some of the API details are new, so please read on if you are
interested.
* Core APIs
Just to remind everyone why we started down this path... As of the
public review draft, we had a single non-generic "behavior" - the
AjaxBeahvior - which could only be attached to EditableValueHolders and
ActionSource components, and even then, only for valueChange/action
events. So, two obvious limitations that we decided to address:
1. We wanted to allow other types of "behaviors" to be provided - not
limit the solution to AjaxBehavior.
2. We wanted to allow components other than
EditableValueHolders/ActionSources to host "behaviors".
In order to address #1, we introduced the generic
javax.faces.component.behavior.Behavior class. The class provides the
base contract for all behavior implementations. Note that early on we
decided that a "behavior" was something distinct from a "component".
Behaviors, like converters/validators, are objects that are attached to
existing components in order to enhance the component with functionality
that is not provided by the component itself.
The main responsibility of a Behavior implementation is to cough up a
script - ie. a bit of JavaScript code that can be attached to one of the
component's client-side event handlers (eg. attach to "onclick"). This
responsibility is implemented via the Behavior.getScript() method.
In order to address #2, we introduced the
javax.faces.component.behavior.BehaviorHolder interface. Components
that want to allow behaviors to be attached implement this interface.
This allows the component to communicate the valid attach points
(getEventNames()) and the default attach point (getDefaultEventName()),
provides a mechanism for registering behaviors (addBehavior()), and also
provides access to any registered behaviors (getBehaviors()).
While UIComponentBase does not implement the BehaviorHolder interface
itself, it provides default implementations of the BehaviorHolder
methods in order to make it easier for subclasses to implement
BehaviorHolder. The minimal requirement for a UIComponentBase subclass
to implement BehaviorHolder is to provide an implementation of
getEventNames() that returns a non-empty set of the event names
supported by the component.
These two contracts, Behavior and BehaviorHolder, form the foundation of
our new component behavior solution. Hopefully the above should be
familiar since it has been discussed the number of times on the EG list
and was also covered in Appendix C of the recent spec drafts. The
actual set of APIs that we need has grown over the last few months, so I
wanted to also discuss some of the more recent additions...
* BehaviorRenderer
Once we got the core Behavior/BehaviorHolder contract in place, we
(Roger, Ted, Alex and I) quickly realized that additional flexibility
was needed. In particular, we felt that the scripts that are produced
by Behaivor implementations may need to vary based on the RenderKit. In
order to support RenderKit-specific Behavior script generation, we
followed the existing UIComonent/Renderer pattern and introduced a
BehaviorRenderer API. BehaviorRenderers are similar in spirit to
component Renderers, but provide a contract that is geared towards
Behaviors. So, while component Renderers are designed for HTML content
generation and write directly to the ResponseWriter, BehaviorRenderers
simply cough up a script - ie. the main API on BehaviorRenderer is
getScript() (mirrors Behavior.getScript()).
Of course, as with component Renderers, BehaviorRenderers are entirely
optional. A Behavior implementation does not need to use a
BehaviorRenderer at all - it can simply override Behavior.getScript()
and produce the script locally.
* Behavior Event Handling
The next enhancement that we tackled was the ability for Behaviors to
participate in decoding. This was necessary in order to support a very
important use case: the ability for Behavior implementations to deliver
events to registered listeners. The main case that we had in mind was
AjaxBehavior, ie. we wanted to make it possible to do this:
<h:commandButton>
<f:ajax event="mouseover"
listener="#{bean.doSomethingInResponseToMouseOver}"/>
</h:commandButton>
In order to support this we added the following APIs:
- Behavior.decode()
- BehaviorRenderer.decode()
- Behavior.broadcast()
- BehaviorEvent (extends FacesEvent)
- BehaviorListener (extends FacesListener)
We also specified the mechanism/conditions under which BehaviorHolder
components must give attached Behaviors the opportunity to decode.
* BehaviorBase
Around this time we also introduced a BehaviorBase base class that
provides base functionality for Behavior implementations (such as
listener registration, event broadcast support, BehaviorRenderer
delegation wiring). BehaviorBase is to Behavior what UIComponentBase is
to UIComponent.
* Behavior.Parameter
As we started integrating the new behavior contract with our existing
renderers, we realized that Behavior/BehaviorRenderer getScript()
implementations may need access to various pieces of information to help
them generate the correct scripts. For example, in the h:commandButton
case, the component may have f:params attached. These f:param
names/values must be included in the request, whether the request is a
full page postback provided by the component, or an Ajax postback
provided by the AjaxBehavior. In order to support this case, we added a
trivial static inner Parameter class to Behavior. This allows
components/renderers to pass (resolved) parameter name/values into
Behavior.getScript().
* BehaviorContext
At this point we realized that there is danger in adding more arguments
to the Behavior.BehaviorRenderer.getScript() methods. The problem is
that we may not be able to foresee all of the possible information that
getScript() implementations may need access to. Rather than risk having
to later define new overrides of getScript(), we decided to introduce a
BehaviorContext class. The BehaviorContext is used to pass information
(FacesContext, component, parameters, source id) into
Behavior.getScript(). If we find that we need to pass additional
information into getScript() in a later release, we can do so by adding
new methods to the BehaviorContext.
BehaviorContext is defined as an abstract class, but provides access to
a implementation via the BehaviorContext.createBehaviorContext() factory
method. Note that we explicitly avoid going through the FactoryFinder
mechanism here since this is a trivial data transfer object - and one
which may need to be instantiated many times during a typical request -
so we want to keep the overhead low.
I keep going back and forth as to whether Behavior.decode() should also
take a BehaviorContext. Currently it just takes a FacesContext and the
UIComponent. I am tempted to pass in the BehaviorContext instead,
though certain information on the BehaviorContext (like the parameters)
are clearly specific to script generation.
* BehaviorHint
Another issue that arose while integrating Behavior support into
h:commandButton is that the component renderer may itself need to vary
its content depending on whether or not it has a Behavior attached, and
in particular depending on whether that Behavior provides a script that
performs a postback. The issue here is that certain renderers - eg.
commandButton/Link renderers - may generate their own postback scripts
(in Mojarra these renderers generate calls to mojarra.jsfcljs()).
However, when an AjaxBehavior is attached, it provides its own postback
script that should replace/suppress the postback script that the
component renderer normally produces. Since not all Behavior
implementations actually perform postbacks (AjaxBehavior does, but most
won't), the component renderer needs some way to determine whether or
not an attached Behavior is going to perform a postback.
In order to solve this problem, we added a new enum, BehaviorHint, and a
new method to Behavior: Behavior.getHints(). getHints() returns a
Set<BehaviorHint> (implemented under the covers as an EnumSet of course)
that provides information about the Behavior that the consuming
component/renderer may be interested in.
At the moment, the BehaviorHint enum only defines a single value -
BehaviorHint.SUBMITTING. However, we chose to use an enum rather than a
boolean (ie. rather than a Behavior.isSubmitting() method) to allow for
additional hints in the future. If people feel that it is too awkward
to have a single-valued enum in our API, please let me know. We can
consider reverting to a boolean method, though an enum is more future proof.
* Behavior configuration
In order to provide complete support for configuring Behavior and
BehaviorRenderer implementations, we had to touch a number of places,
including:
- javax.faces.application.Application now supports methods for adding
and creating Behavior instances
- faces-config.xml now supports <behavior> and <behavior-renderer> elements
- We have added annotations for identifying Behavior and
BehaviorRenderer implementations so that faces-config entries are not
required
- The Facelets taglib file now supports <behavior> tags.
In all cases we followed the precedents already set by converter/validator.
* Standard HTML component BehaviorHolders
Finally, once we had agreement our generic Behavior solution, we also
decided that it was silly not to enhance the standard HTML component set
to take advantage of this. Most of the standard HTML components now
implement BehaviorHolder and thus allow Behaviors to be attached. The
attach points for the standard HTML components correspond to the
standard "on<Event>" attributes. So, whereas before it was only
possible to attach behaviors to EditableValueHolder/ActionSource
components, it is now possible to attach Behaviors to other standard
components, eg. <h:panelGroup>:
<h:panelGroup>
<f:ajax event="mouseover" listener="#{bean.foo}"/>
</h:panelGroup>
This gives us significantly more flexibility - and a much more powerful
solution than we had outlined in our original plans.
One quick note on event names... The event names/attach points do not
include the "on" prefix that is used in the component attribute names. So:
<f:ajax event="mouseover"/>
Not:
<f:ajax event="onMouseover"/>
The standard ActionSource components still support a logical "action"
event/attach point. And the standard EditableValueHolder components
still support a logical "valueChange" event/attach point. This allows
page authors to attach Behaviors to these components without having to
be aware of the unerlying DOM event that triggers the action/value
change. Also note that the "action" and "valueChange" events are
defined as default events for these components, which makes it possible
to do omit the event attribute, eg:
<!-- Fires Ajax requests in response to actions -->
<h:commandButton>
<f:ajax/>
</h:commandButton>
<!-- Fires Ajax requests in response to value changes -->
<h:inputText>
<f:ajax/>
</h:inputText>
BTW, Jeffrey Stephenson (JSR-276) and I have been having some offline
discussions on the possibility of getting event name/default event name
metadata in place. This would clearly help the development tool experience.
* Limitations
While I think that the Behavior API is a great addition to JSF, there
are a few limitations that we have not been able to address for 2.0.
These include:
1. Custom renderer wiring
Implementing the BehaviorHolder contract is trivial. However, actually
rendering the Behavior scripts - possibly multiple scripts which may
need to be chained with other component/renderer-defined scripts - can
be tedious. To help simplify this, we have introduced a new utility
method into our JavaScript API: jsf.util.chain(). This method takes an
arbitrary number of script arguments and executes each one until it
finds one that returns false, at which point it short-circuits. While
this simplifies things somewhat, it is still nontrivial for a Renderer
author to produce the proper call to jsf.util.chain().
If we had more time, I would recommend trying to get some utility
methods into the JSF API so that we can make it easier for custom
Renderer authors to produce the properly chained scripts. However,
given how little have time we have left, I do not think that we have
time to get this right. My current plan is to try to provide some open
source utilities to help Renderer authors solve this problem. Once
we've worked out the right APIs in open source, I am hoping that we can
incorporate these back into the 2.1 spec.
2. Behavior attribute-property transparency
I have been thinking that, like components, Behaviors should expose an
attribute map that provides attribute-property transparency. That way,
BehaviorRenderers do not have to worry about the actual Behavior type -
they can simply grab attributes out of the attribute map.
I briefly considered implementing this functionality, but after a quick
look at UIComponentBase.AttributeMap I got scared away. I think the
right solution is to:
- Break UIComponentBase.AttributeMap out into its own top-level public
class.
- Introduce an AttributeHolder contract
- Have UIComponentBase and BehaviorBase implement AttributeHolder and
use AttributeMap to hold their attributes.
However, for obvious reasons I decided not to push this for 2.0.
Perhaps we can think about this for 2.1.
Since we do not have a Behavior.getAttributes() API, at the moment,
BehaviorRenderer implementations are forced to cast to the actual
Behaivor type (eg. AjaxBehaviorRenderer casts the Behavior to
AjaxBehavior). I am not happy about this, but willing to live with it
for now.
3. Behavior resources
Behavior implementations clearly are going to want to pull in JavaScript
libraries so that these do not need to be pulled in explicitly by the
application developer. However, at the moment we do not have a
solution/recommendation for this. (Well, there might be some solution -
just haven't identified what it is yet.)
This is another one that will need to wait for 2.1.
I think that's it! If you have any questions/comments on this new API,
please follow up here.
I am hoping to do some blogging on all of this if I can ever find the
time. :-)
Andy
15 years, 1 month
Re: [jsr-314-open] So what's left for 2.0?
by Ed Burns
>>>>> On Wed, 11 Mar 2009 17:09:25 -0400, Gavin King <gavin@HIBERNATEORG> said:
AS> Can anyone clarify what the plan is for 2.0?
EB> We had a plan, but it never was fully prototyped and the prototype
EB> we did have was terribly de-stabilized by the lifecycle changes we
EB> made to accomodate Andy's your concerns regarding the performance of
EB> metadata gathering. Therefore, I'm sorry to say it but we'll have
EB> to push out State Saving enhancements to 2.1.
GK> I don't understand this response.
Technically, the prototype was based on the lifecycle design prior to
the integration of the View Parameters feature. The changes to the
lifecycle to integrate View Parameters into the spec have invalidated
important assumptions made by the state saving prototype. Therefore,
the prototype has to be reworked in light of the current lifecycle
design.
GK> Does this mean you are saying that a stateless lifecycle will be
GK> impossible in JSF2?
Impossible: certainly not. Easy: that's debatable. The easiest way for
a user to achieve stateless JSF in 2.0 is to use only your <h:link> and
<h:button> components for navigation and to mark every <f:view> as
"transient". In this way, there will never be a POST to the server and
there will never be any state saved or restored. I don't think such
restrictions are to onerous.
>>>>> On Wed, 11 Mar 2009 17:06:52 -0400, Gavin King <gavin@HIBERNATEORG> said:
GK> What is the real status on state saving. IMO, the ability to write
GK> "stateless" components is a critical feature for JSF2.
It is certainly possible to write stateless components but not easy.
See the P.S. for one way to do it. Here are my arguments for shipping
2.0 without this feature.
1. We've been working on this long enough, we have plenty of value in
our other features, let's ship it.
a. Economic arguments relating to Sun's cost for funding R&D budget
also fit into this argument.
b. We've been talking about this for the past *three* JavaOnes. I've
been embarrased about not having it done for the past *two*. It's
time to have it done.
2. It is possible, but not easy to do stateless components, see the PS.
That's pretty much it.
Ed
P.S. An extension could be made that makes stateless components easy.
Here's one way to do it, assuming it's acceptable to say to the user:
"You want stateless? Don't use any UICommand components in your
application."
The basic idea is to leverage your view parameter feature to take
responsibility for the ValueHolder nature of a UIComponent and let the
UIComponent subclass only handle the "renderable" nature of a
UIComponent.
Consider these classes:
public class ComponentBaseStateless extends UIComponentBase.
public class ComponentBaseViewParameterHelper extends UIViewParameter.
* make a Facelet tag for ComponentBaseViewParameter helper (no code
required), let's call it <ex:statelessHelper>.
* ComponentBaseStateless ensures its "transient" property is always
true and can never be set to false.
* make ComponentBaseStateless emit a javascript function that, when
called, returns the name=value pair of the component.
* make the the ComponentBaseStateless.encodeAll() find its corresponding
ComponentBaseViewParameter instance and pull the value to render from
there.
* require the page author using the component to place an
<ex:statelessHelper> in the <f:metadata> section with the same id as
the component. Any validators, converters, etc that you would
normally attach to the component directly, are attached within this
<ex:statelessHelper>.
* require the page author to use only <h:link> and <h:button> components
and furthermore, require them to call the special javascript method to
ensure that any name=value pairs in the page are included in the query
string.
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
[jsr-314-open] [426-BeanValidation] Default Enablement Change CLOSED
by Ed Burns
Here's the final word on this:
Issue: 426 Bean Validation
SECTION: Modified Files
----------------------------
M jsf-api/src/javax/faces/component/UIInput.java
- in validateValue(), modify spec for default enablement of bean
validation to be the following.
* <li><p>If the value is empty, but the system has been directed to
* validate empty fields, validation should proceed. The
* implementation must obtain the init parameter <code>Map</code>
* from the <code>ExternalContext</code> and inspect the value for
* the key given by the value of the symbolic constant {@link
* #VALIDATE_EMPTY_FIELDS_PARAM_NAME}. If there is no value under
* that key, use the same key and look in the application map from
* the <code>ExternalContext</code>. If the value is
* <code>null</code> or equal to the string
* “<code>auto</code>” (without the quotes) take
* appropriate action to determine if Bean Validation is present in
* the runtime environment. If not, validation should not proceed.
* If so, validation should proceed. If the value is equal
* (ignoring case) to “<code>true</code>” (without the
* quotes) validation should proceed. Otherwise, validation should
* not proceed.</p></li>
usingFacesInWebapps.fm
- document the VALIDATE_EMPTY_FIELDS context param like this:
javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and calling
toLowerCase().equals("true") on a String representation of its value
returns true, all submitted fields will be validated. This is
necessary to allow the model validator to decide whether null or empty
values are allowable in the current application. If the value is
false, null or empty values will not be passed to the validators. If
the value is the string "auto", the runtime must check if JSR-303
Beans Validation is present in the current environment. If so, the
runtime must proceed as if the value "true" had been specified. If
JSR-303 Beans Validation is not present in the current environment,
the runtime most proceed as if the value "false" had been
specified. If the param is not set, the system must behave as if the
param was set with the value "auto".
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
