[jsr-314-open] PostRestoreStateEvent called more that once for components inside UIData instances (h:dataTable)
by Dan Allen
>From the jsr-314-comments inbox.
---------- Forwarded message ----------
From: Leonardo Uribe <lu4242(a)gmail.com>
Date: Tue, Sep 15, 2009 at 1:27 AM
Subject: [jsr-314-open] [jsf 2.0] PostRestoreStateEvent called more that once for
components inside UIData instances (h:dataTable)
To: jsr-314-comments(a)jcp.org
Cc: MyFaces Development <dev(a)myfaces.apache.org>
Hi
Checking UIViewRoot class I have noted some side effect on
UIViewRoot.processRestoreState() method.
The javadoc says this:
".....The default implementation must call
UIComponentBase.processRestoreState(javax.faces.context.FacesContext,
java.lang.Object) from within a try block. The try block must have a finally
block that ensures that no FacesEvents remain in the event queue, and that
the this.UIComponent.visitTree(javax.faces.component.visit.VisitContext,
javax.faces.component.visit.VisitCallback) is called, passing a
ContextCallback that takes the following action: call the
UIComponent.processEvent(javax.faces.event.ComponentSystemEvent) method of
the current component. The argument event must be an instance of
PostRestoreStateEvent whose component property is the current component in
the traversal......"
Now just imagine a component inside h:dataTable and read the documentation
of UIData.visitTree(). That algorithm visit child components per row. But
UIData use the same component per each row and only save the values related
to EditableValueHolder interface. The result is that we call
PostRestoreStateEvent as many times as rows are available. This behavior of
UIData.visitTree() has prevented me from using it for partial state saving,
because we only need to call restoreState or saveState only once per
component instance.
In any case, It could be good to know if this behavior is expected or not. I
tried to fix the behavior on myfaces of h:outputScript target="head" and
partial state saving at postback with a listener to this event, but after
reading the javadoc I notice it will not work as I expected.
regards,
Leonardo Uribe
14 years, 7 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Ed Burns
>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Lincoln,
>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>> be bound to a backing bean,
MM> I thought it was - and just checked, it derives from UIComponentBase.
MM> Does the binding attribute not work for you?
Yes, but it's implementation specific and not in the
javax.faces.component package.
LB> **Question 1: Almost every AJAX framework I know of allows you to simply
LB> execute a method on the server side, with or without params, and return
LB> a result... is this possible with JSF's Ajax framework?
Such DWR style functionality was in DynamicFaces, but didn't make it
into the JSF standard Ajax.
>>>>> On Thu, 13 Aug 2009 00:10:59 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> IMO this is not an uncommon use case, and we should support via (1)
Can you please be more specific, Pete? Which part of LB's mail is not
an uncommon case? What is (1)?
>>>>> On Thu, 13 Aug 2009 00:26:14 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Dan,
MM> I did a little research, and it won't work. Therefore I just sent a
MM> mail out to the JSR-245 spec lead asking for the following signature
MM> in the EL-resolver - that might help at least a little in providing
MM> such functionality. And I thought we had discussed that this should
MM> work at some point of time.
MM> public Object invoke(ELContext context,
MM> Object base,
MM> Object method,
MM> Class[] formalParamTypes,
MM> Object[] formalParams,
MM> Class[] parsedParamTypes,
MM> Object[] parsedParams
MM> ) {
MM> ...
MM> }
>>>>> On Thu, 13 Aug 2009 01:45:45 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> 1) add a method-attribute to the f:valueChangeListener-tag
You mean, have an attribute that means, "The value of this attribute
must be a MethodExpression that points to a method that conforms to the
signature of ValueChangeListener.processValueChange()"? If so, then yes
I agree, and we should add it for all the attached objects where it
makes sense.
MM> 2) get Unified-EL to also support passing the formal parameters (see
MM> my mail to the spec lead)
Which I still don't understand. Can you please explain explicitly?
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] Autoupdate / always render
by Jim Driscoll
So, I got a chance to discover more about RichFaces today, attending a
tutorial by Max Katz.
Autoupdate can also be thought of as "always render" - it's the process
of marking out certain id's to always be rendered on any ajax request.
I can now say that, no, we don't support autoupdate functionality -
while a page author doesn't really need this functionality, it's
possible to imagine a use case for it as a component library author -
and in that case, while there's hacky things you can do to almost get
there, it won't really be possible with the existing APIs.
Since in an earlier message, I said that I wasn't aware of anything in
particular that couldn't be done with the API, well, here's one use case.
Adding such an API would be pretty easy:
void jsf.ajax.addAlwaysRender(String id)
I'll file a spec RFE for this (there seems to not be one!), but I was
wondering:
What's the context/history behind this not being included in JSF 2.0?
Can anyone elaborate?
Jim
P.S. Filed bug 629 on this topic.
14 years, 7 months
Re: [jsr-314-open] AJAX library in JSF 2.0
by Lincoln Baxter, III
The only enhancement I would push for at this time is the ability to
call a server side action method and return a result to the page
javascript. That's really the only thing I see missing:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=613
Not sure where it stands right now.
--Lincoln
On Sun, 2009-09-13 at 23:53 +0200, Jim Driscoll wrote:
> On 9/13/09 8:26 PM, Ryan de Laplante wrote:
> > What I'm
> > asking is why did the EG not standardize more of what the many JSF AJAX
> > frameworks have created and improved up on over the years. I'm certainly
> > not suggesting you invent new APIs. I'm saying many APIs exist, are
> > proven and battle tested already.
>
> What APIs are you thinking of? I could better answer if I had specific
> examples. The examples that come to my mind (push, queuing, request
> aggregation) don't really fit into that category - they're either very
> library specific, or (IMO) still unproven.
>
> > I am not very knowledgeable or experienced in AJAX, even with the
> > component libraries for JSF 1.2. Still, from my perspective it looks
> > like only the fundamentals were standardized. Not enough to be fully
> > usable in a full featured UI component library, and therefore it will go
> > mostly unused until it standardizes more of what the major UI component
> > libraries need.
>
> Among my examples in my blog, I've implemented a polling component,
> editable text, created a passable shuttle component, and integrated in
> the YUICalendar widget. I've even got a clunky Comet example I'll be
> publishing this week. In fact, I've not yet come across a use case that
> CAN'T be solved with the existing framework. And ICEFaces has certainly
> indicated that they'll be building their very fancy and capable push on
> top of the existing APIs in their new release.
>
> Perhaps if you could suggest specific page actions that can't be
> implemented using the existing framework, or better, that the existing
> structure forbids, we could have a more in depth discussion on those
> points. I'm sure there must be some, I just don't know what they are.
> Push, certainly, needs to be standardized, but that doesn't seem to be
> what the AJAX4JSF guys are doing - and we had good reason for leaving
> that out this round. And as I mentioned, I've already got that
> implemented (badly) using the current APIs, without changes to the base
> API - and the ICEFaces guys haven't been complaining that I've heard.
>
> >> The goal of the JSF Ajax framework is to provide an easy to use set of
> >> basic functions which will be built upon by other members of the JSF
> >> ecosystem.
> > I hope that AJAX4JSF is modified so that it builds on top of the JSF
> > standardized APIs instead of being a complete replacement for them.
>
> That's something that can best to achieved by their customers lobbying
> the AJAX4JSF people.
>
> AFAIK, there's nothing to stop them specifically from adopting the
> current API set - other than their reluctance to rewrite an existing
> codebase. But that's based on the one link that you sent on - you'd
> have to ask them directly if that's true.
>
> Jim
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
14 years, 7 months
[jsr-314-open] h:outputScript target="head" is rendered in body when partial state saving is used and there is a postback
by Dan Allen
---------- Forwarded message ----------
From: Leonardo Uribe <lu4242(a)gmail.com>
Date: Sat, Sep 12, 2009 at 11:03 PM
Subject: [jsr-314-open] h:outputScript target="head" is rendered in body when partial state
saving is used and there is a postback
To: jsr-314-comments(a)jcp.org
Hi
I have notice a failure when <h:outputScript target="head" ....> is used and
there is a postback, that requires change something in the spec.
Suppose the following scenario
<h:head>
</h:head>
<h:body>
<h:outputScript name="jsf.js" library="javax.faces" target="head"/>
<!-- some other stuff -->
</h:body>
The renderer documentation of h:outputScript and h:outputStylesheet says
this:
"....The implementation of this renderer must have a @ListenerFor annotation
attached to it, at the class level, declaring PostAddToViewEvent.class as
the value of the systemEventClass attribute. The presence of this annotation
on a renderer implies the renderer implements ComponentSystemEventListener,
which this renderer must do. The implementation of processEvent() must
extract the UIComponent from the argument event and look for the presence of
the key "target" in the component's attribute Map. If and only if such a key
is present, the implementation of processEvent() must pass the component to
UIViewRoot.addComponentResource()...."
Now imagine the user are submitting a form and there is a validation error.
In that case there is a postback so the same view is rendered. The first
request build a view like this:
<h:head>
<h:outputScript name="jsf.js" library="javax.faces" target="head"/>
</h:head>
<h:body>
<!-- some other stuff -->
</h:body>
but the next one restore this if partial state saving is used:
<h:head>
</h:head>
<h:body>
<h:outputScript name="jsf.js" library="javax.faces" target="head"/>
<!-- some other stuff -->
</h:body>
the reason why this happens is clear looking the documentation of
UIComponent.getChildren():
"...After the child component has been added to the view, if the following
condition is not met:
FacesContext.isPostback() returns true and
FacesContext.getCurrentPhaseId() returns PhaseId.RESTORE_VIEW..."
This is valid if we are using jsf 1.2 state saving, because we save and
restore the whole tree, so the components created are already on the view.
But when we use partial state saving, we do this operation:
restored view = apply delta on (fresh view from VDL.buildView() + added
components after that - removed components after that)
The conclusion is: All components that relies on
ComponentSystemEventListener listening PostAddToViewEvent to be relocated in
some way (h:outputScript, h:outputStylesheet, composite:insertChildren,
composite:insertFacet (because we need the whole tree built before move
components, otherwise nested composite components will not work correctly) )
are incompatible with partial state saving. Its more, if the affected
components are moved outside/inside/between NamingContainer or
UniqueIdVendor instances the state will not be correctly restored.
The solution from my point of view is relax the restriction on
UIComponent.getChildren() (maybe adding a faces context attribute saying the
current view is being built using partial state saving), so when partial
state saving is used, PostAddToViewEvent will be published.
I'll appreciate a lot any comment.
regards
Leonardo Uribe
14 years, 7 months
Re: [jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature
by Ed Burns
>>>>> On Wed, 09 Sep 2009 11:57:44 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> On 8 Sep 2009, at 21:48, Dan Allen wrote:
>> On Sun, Sep 6, 2009 at 9:46 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>> Why don't we specify that only bundled resources are required to be
>> supported, and that a container may portably support installed
>> libraries?
>>
>> That's precisely what I had in mind.
>>
>>
>> Mojarra and other implementations would be able to provide this
>> support via a vendor specific SPI.
>>
>> Should the SPI be part of the spec or something the implementation
>> provides? Perhaps Mojarra can introduce an SPI that we later promote
>> in an MR?
PM> This would be the approach I would take.
I'm not fond of reducing the flexibility that we already have. Ryan has
implemented something that he's satisfied with. Ryan, can you please
share the details so we can further discuss the options for ammending
the specification?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] Faces continues processes lifecycle even when facesContext.responseComplete() has been called
by Lincoln Baxter, III
If the current response has already been completed before RESTORE_VIEW
phase (eg, because a PhaseListener called
facesContext.responseComplete() beforePhase ), Faces continues to
attempt lifecycle processing. I'm thinking that this should be handled
by halting lifecycle processing as defined in the API -- Is this a bug
or a something we need to discuss? What do you guys think?
/**
* <p>Signal the JavaServer Faces implementation that the HTTP
response
* for this request has already been generated (such as an HTTP
redirect),
* and that the request processing lifecycle should be terminated as
soon
* as the current phase is completed.</p>
*
* @throws IllegalStateException if this method is called after
* this instance has been released
*/
public abstract void responseComplete();
Caused by: java.lang.IllegalStateException
at
com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:639)
at
com.sun.faces.context.FacesContextImpl.getCurrentPhaseId(FacesContextImpl.java:515)
at
javax.faces.event.ExceptionQueuedEventContext.<init>(ExceptionQueuedEventContext.java:148)
at
javax.faces.event.ExceptionQueuedEventContext.<init>(ExceptionQueuedEventContext.java:101)
at com.sun.faces.lifecycle.Phase.queueException(Phase.java:152)
at com.sun.faces.lifecycle.Phase.queueException(Phase.java:145)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:105)
at
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
14 years, 8 months
[jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature
by Ed Burns
Thanks to Ryan Lubke for bringing this up and authoring the first draft
of this email.
Recall the resource versioning scheme we have that enables runtime
upgrades of component resources without redeployment. A valid resource
identifier has the following parts. Optional parts are in square
brackets.
[libraryName/][libraryVersion/]resourceName[/resourceVersion]
Recall also that the default ResourceHandler supports loading resources
in an "exploded" fashion, from the <web app root>/resources directory,
and also from the classpath via entries in the META-INF/resources
directory.
Summary of Issue
-----------------------------------
Derivation of library and or resource versions is currently dependent on
the URL type exposed when searching for classpath resources. Within
Mojarra, we can properly find versions if the URL protocol is 'file' or
'jar'.
URLs with a file protocol can be used to construct a File instance with
which we can use standard Java File IO to find the versions.
URLs with a jar protocol allow access to the JAR file itself with which
we can use the standard JAR apis to navigation through the JAR and find
versions.
If the URL protocol is of any other type, we really have no way to
derive the version information in a portable manner.
It just so happens that there are several cases when it's not possible
to meet the version scanning requirements in all containers and in all
deployment scenarios. For example, in glassfish, if you deploy your
resource in an OSGi bundle, we don't see jar: or file: URLs. In another
example, JBoss AS has its own loading scheme thit also is not jar: or
file:. Therefore, we cannot guarantee the version scanning feature will
work in all cases.
Options to resolve the issue
--------------------------------------
1. Update the specification to state that versioned resources are only
supported when they are included as resources under /resources
2. Update the specification to state that only classpath resources
included in the web application will be searched. This means that
resources installed to the server classpath will not be considered.
Implementations could then explode the resources found within the
JAR files included in the application to a temporary directory. The
classpath searching algorithm would then search this temporary
directory instead. Doing this for server classpath resources may be
impossible depending on the container.
ACTION: Please choose one of the two options above or suggest another.
Silence implies consent with option 2. Please reply in a timely
fashion.
Sincerely,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
[jsr-314-open] [Fwd: Re: Browser Dependencies]
by Lincoln Baxter, III
TH> "One of the more subtle things about VEE is that you can also get them on
an AJAX request. I don't think anyone's addressed that yet."
Has this been addressed yet?
--Lincoln
-------- Forwarded Message --------
From: Tim Holloway <timh(a)mousetech.com>
To: lincolnbaxter(a)gmail.com
Subject: Re: [jsr-314-open] Browser Dependencies
Date: Mon, 07 Sep 2009 15:03:16 -0400
Hi Lincoln,
Sorry to take so long. I've been wrangling pixels in CSS. As much work
as coding, and a lot less fun. I didn't realize that my JSF forms were
silently adding 16 pixels to the bottom of their (non-)display area.
Favors like that I could have done without.
When I saw Ed Burns capture the error page on ViewExpiredException, I
thought, "Why didn't I think of that?" Turns out I did, but without the
JSF2 parts. Unfortunately, I think that some of the wierdness in my
filter may be because I'm trying to use both the container and the
filter to trap that exception.
Pity I can't try the JSF2 approach just yet, but first they need to get
it info production!
One of the more subtle things about VEE is that you can also get them on
an AJAX request. I don't think anyone's addressed that yet.
Speaking of JSF2, have you seen this?
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
It's a nice rundown. I'm not sure if their ideas on
bookmarkable/parameterized URLs are as tidy or as complete as
PrettyFaces, though.
Best Regards,
Tim
On Thu, 2009-09-03 at 23:08 -0400, Lincoln Baxter, III wrote:
> FYI - new blog entry by ed burns:
>
> http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefull...
>
>
> On Sun, 2009-08-30 at 13:25 -0400, Tim Holloway wrote:
> > On Sun, 2009-08-30 at 11:33 -0400, Lincoln Baxter, III wrote:
> > > Hmm, I do see value in that, but let me dump some thoughts and see
> > > what you think:
> > >
> > > I suppose it depends on the scope of the bean in which you are storing
> > > the query-param. If the bean is session scoped, then it will remain
> > > valued until the session expires (or it is unset manually.) If it is
> > > request scoped, it will need to be supplied each request. PrettyFaces
> > > could, I suppose, overwrite the value in the session or application
> > > scope with a default value, but that might create issues itself.
> > >
> > Yup. Request Scope at least starts out with a known value. The problems
> > are with session and application scope. But I'd forgotten (for about the
> > 3d time!) that PrettyFaces has to match on all items - and in the order
> > illustrated - anyway. So the whole idea is probably moot.
> >
> > BTW, I don't think you ever formally indicated in the docs whether
> > PrettyFaces does first-fit or best-fit on URL patterns. One of the URLs
> > on my demo site has a "noise" component, and so I wanted to be able to
> > match with or without the extra chunder, but I couldn't find a way to do
> > that, so I had to make the core URLs distinct.
> >
> > I do admit to a bad habit of trying to treat Pretty URLs as cavalierly
> > as I would raw URLs. Which really isn't nice of me. :)
> >
> > > Values can be set to defaults using initializers in the class file, or
> > > via an action method.
> > > Request values (query params) can be pulled out of the
> > > externalContext.getRequestMap() to see if anything was set (if you
> > > need to know). Pattern parameters wouldn't really work because
> > > something has to be at that part of the URL.
> > >
> > > I'm not sure the malicious attack issue would be solved by default
> > > values -- URL input is just as sensitive as form input, and is subject
> > > to the same risks and requirements for validation. Unfortunately,
> > > validation is manual with PrettyFaces because it would be very complex
> > > to put in. But I use action methods to do my validation at the
> > > RESTORE_VIEW default action method phase:
> > >
> > I had doubts myself. Just figured that any time there was a possibility
> > for unexpected input, someone would find some way to do something nasty.
> >
> > >
> > > if (!ALL.equals(featureFilter) &&
> > > storyFeatureOptions.contains(featureFilter))
> > > {
> > > for (Iterator<Story> iterator = result.iterator();
> > > iterator.hasNext();)
> > > {
> > > Story story = iterator.next();
> > > if (!
> > > story.getFeature().getName().equals(featureFilter))
> > > {
> > > iterator.remove();
> > > }
> > > }
> > > }
> > >
> > > Thoughts? Did I understand your point?
> > > --Lincoln
> > >
> > > On Sat, 2009-08-29 at 19:42 -0400, Tim Holloway wrote:
> > > > the value of "pagesize" will be indetermite when the action fires
> > > > and
> > > > there's no obvious way to detect the missing parameter(s) short of
> > > > manually picking apart the action URL (which kind of defeats the
> > > > purpose
> > > > of PrettyFaces). So being able to set a default pagesize seems like
> > > > a
> > > > useful thing to be able to do.
> >
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
14 years, 8 months
Re: [jsr-314-open] Metadata complete jar files
by Dan Allen
Absolutely.
Btw, this feature appears in other areas of the platform and should
obviously be consistent.
- Dan Allen
Sent from my Android-powered G1 phone:
An open platform for carriers, developers
and consumers.
On Sep 3, 2009 6:25 PM, "Pete Muir" <pmuir(a)redhat.com> wrote:
Hi Andy
On 3 Sep 2009, at 15:58, Andy Schwartz wrote: > Gang - > > Section 11.5.1 of
the spec defines the...
I think this is the correct approach, and the way it should always have
been.
> > Note that while the annotation scan is typically a one time hit (during
application startup), ...
14 years, 8 months