Re: [jsr-314-open] Groovy support
by Ed Burns
>>>>> On Wed, 18 Mar 2009 04:07:08 -0400, Kito Mann <kito.mann(a)VIRTUA.COM> said:
KM> So, after perusing the spec, I noticed that there's no mention
KM> specifically of Groovy. And I don't see much on the Groovy site
KM> itself indicating when/if the Groovy JSR will ever be finished. Any
KM> insight?
Right, as you know, at nearly every JSF 2 talk I give, I implore the
audience to pepper Mr. La Forge with annoying emails about completing
the JSR. Until it is completed, we can't explicitly mention Groovy.
The spec language we currently have is as specific as I can get.
Do you have another suggestion?
Ed
15 years
Re: [jsr-314-open] [Fwd: [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?]
by Andy Schwartz
Gang -
Need to bring this up one more time... Last week we found that our choice of implementations for "wrapping" f:ajax/f:validateBean has implications for delta state saving, so wanted to describe the problem here and see whether we can agree to a solution.
Some quick background on the delta state saving strategy - I'll defer to Ed and Ryan on the API specifics and also on current status with respect to 20 specification. The solution that Ryan has been working on is very similar to the Trinidad approach that we've discussed in the past. Roughly speaking, we're looking at:
1. Facelets tag handlers are applied and we build up the component tree.
2. Once a component has been "populated" (attributes set, attached objects attached), we lock the component state down.
3. From that point on through state saving, we keep track of modifications (attributes modified, atached objects added/removed).
4. At state saving, if nothing has changed (the most common case by far), we have no state to save - our saved state is null.
5. If the component has been modified, we save state. The amount of state that we save for the modified component is implementation specific. The goal is to only save the deltas, though there may be cases where we may save the full state for a specific component instance.
6. At restore time, we first build up the component tree by applying the Facelets tag handlers.
7. Components which did not save any state are fully initialized - don't need to restore any state.
8. Components which did save state restore it over the initialized component instance.
That's it in a nutshell. The end result is that the total size of saved state per component/page is reduced significantly. One really nice part of this solution is that this is all completely transparent to the application developer - ie. the page author does not need to make any changes to take advantage of this optimization.
So, what does this have to do with f:ajax/f:validateBean? The issue has to do with the timing of our current implementations.
In the f:ajax implementation, we apply "inherited" AjaxBehavior instances at tag handler execution time. So, by the time that we reach #2 above, components that are wrapped inside of an f:ajax tag have the appropriate AjaxBehavior instances attached.
With our current f:validateBean implementation, we do not apply "inherited" validators until the encode phase, which, of course, is after we've locked down the component state (ie. after #2). As a result, these validators are treated as component modifications/deltas - and as such impact the amount of state that we save.
In order to avoid this penalty, I would like to propose that we standardize on a tag handler-time solution for both f:ajax and f:validateBean - ie. I would like to see f:validateBean migrated over to a strategy that matches our current f:ajax behavior. My guess is that the implementation changes should not be all that challenging, though I have only taken a superficial look at the f:validateBean wiring. The spec changes should be minimal.
Are people okay with this proposal - ie. okay with standardizing on the f:ajax wrapping behavior? Seems to me that this was the EG's preference back when we discussed f:ajax wrapping behavior last year, so hope that this is acceptable now.
Dan -
I think that you are most familiar with the current f:validateBean implementation. Assuming that you are okay with the proposal, would you be willing to take a look at what we do for f:ajax and maybe sync up with Ryan to discuss what it would take to convert this over to the f:ajax strategy? The f:ajax approach is fairly simple:
- When we encounter f:ajax, we create an AjaxBehavior and push it onto a stack.
- When we encounter a ClientBehaviorHolder component that can accept the AjaxBehavior instance, we create/configure a new AjaxBehavior instance and attach it to the ClientBehaviorHolder
- When we reach the end of the f:ajax tag, we pop the AjaxBehavior stack.
Note that for creating/configuring the AjaxBehavior instances, we use the technique that you hinted at in a previous email - ie. we use the intial AjaxBehavior instance as a template and save/restore its state to configure new instances.
I am actually out of the office this week - just checking email intermittently. I'll do my best to help/answer questions on this, though there may be some gaps between my access to email.
Andy
-------- Original Message -------- Message-ID: <49B67A17.8070609(a)oracle.com>
Date: Tue, 10 Mar 2009 10:32:55 -0400
From: Andy Schwartz <andy.schwartz(a)oracle.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: JSR 314 Open Mailing list <JSR-314-OPEN(a)JCP.ORG>
Subject: [jsr-314-open] [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Gang -
In JSF 2.0 we are introducing two core tags that wrap/enhance component
subtrees: f:ajax and f:validateBean.
f:ajax is used to enable Ajax behavior for a subtree, eg:
> <h:panelGroup>
> <!-- Turn on Ajax for the two input texts -->
> <f:ajax event="valueChange">
> <h:inputText value="foo"/>
> <h:inputText value="bar"/>
> </f:ajax>
> </h:panelGroup>
f:validateBean is used to enable bean validation for a subtree, eg:
> <h:panelGroup>
> <!-- Turn on bean validation for the two input texts -->
> <f:validateBean validationGroups="Group1, Group2"/>
> <h:inputText value="foo"/>
> <h:inputText value="bar"/>
> </f:validateBean>
> </h:panelGroup>
Of course, both tags can also be used in their nested form to enable
Ajax/bean validation on a single component.
We currently use different implementation strategies for the "wrapping"
behavior.
f:ajax uses a handler execution-time solution. AjaxHandler maintains a
stack that keeps track of the current nested state of <f:ajax> tags.
Before apply child handlers, AjaxHandler pushes the current Ajax-related
info onto this stack. When child/descendent handlers are applied,
ComponentTagHandlerDelegateImpl checks this stack to get at the current
Ajax-related state and performs the necessary work to wire up an
AjaxBehavior to the component. Finally, after child handlers have been
processed, AjaxHandler pops the stack, and we're done.
The end result of the f:ajax solution is that once handlers have
finished executing, we have a fully configured component tree. No
further processing is necessary to apply "inherited" Ajax behavior.
f:validateBean uses a solution which is split between tag/handler
execution-time, validation-time and render-time.
BeanValidatorHandler/ValidatorTagHandlerDelegateImpl set up well known
properties on the parent component's attribute map (eg.
BeanValidator.VALIDATION_GROUPS_KEY,
UIInput.DEFAULT_VALIDATOR_IDS_KEY). These are used during later
lifecycle phases (eg. BeanValidator.validate(), UIInput.encodeEnd()) to
determine which inherited validators to apply and how these validators
should be configured (eg. what validation groups to use).
The end result of the f:validateBean solution is that the handlers only
do part of the job - we need to do additional work during later
lifecycle phases to take advantage of the information that has been
stored away by the handlers.
While these two different strategies may at first seem like
implementation details, and thus not especially significant, the choice
of implementation does have impact on both our API and on spec'ed
behavior (or, on behavior that should be defined by the spec).
In terms of API, for f:validateBean the choice of implementation leaks
through a bit into the API in the form of the property keys that are
used to communicate between the handler implementations and the
component/validator implementations.
In terms of behavior, the different implementation strategies and up
with subtly different results which may cause confusion.
For example, in the following f:ajax case:
> <h:panelGroup>
>
> <!-- Turn Ajax on for this one -->
> <f:ajax event="valueChange">
> <h:inputText value="foo"/>
> </f:ajax>
>
> <!-- But not for this one -->
> <h:inputText value="bar"/>
>
> </h:panelGroup>
This should work as expected. That is, Ajax should be enabled for the
"foo" inputText, but not for the "bar" input text.
In a similar f:validateBean case:
> <h:panelGroup>
>
> <!-- Turn bean validation on for this one -->
> <f:validateBean validationGroups="Group1, Group2"/>
> <h:inputText value="foor"/>
> </f:validateBean>
>
> <!-- But not for this one -->
> <h:inputText value="bar"/>
>
> </h:panelGroup>
Unless I am missing something in the spec/implementation, I believe that
the validation-related properties are going to end up being attached to
the parent panelGroup when the BeanValidatorHandler is applied. Which,
if I understand this correctly, means that the validation will be
applied to both the "foo" and the "bar" inputText. If this is the case,
this is definitely not the desired behavior.
I suspect that similar problems would arise when we've got multiple
<f:validateBean> under a single parent, eg:
> <h:panelGroup>
>
> <!-- Turn on Group1 validation for this one -->
> <f:validateBean validationGroups="Group1"/>
> <h:inputText value="foo"/>
> </f:validateBean>
>
> <!-- Turn on Group2 validation for this one -->
> <f:validateBean validationGroups="Group2"/>
> <h:inputText value="bar"/>
> <f:validateBean/>
>
> </h:panelGroup>
Though I haven't had a chance to test this out - just based on code
inspection seems like this would be a problem. (Though our <f:ajax>
implementation strategy handles this case just fine.)
Since there may be other subtle inconsistencies, it would make sense to
try to unify our implementation strategies across these two core tags.
Of course, I am biased towards the <f:ajax> approach. Seems to have
better behavior in terms of targeting only the wrapped subtrees, has
less exposure in the public API, and also just seems cleaner to me to
produce a fully configured component tree as a result of handler execution.
Looking at the code, I didn't notice anything that would make it
difficult to re-factor the <f:validateBean> code to use a handler-time
strategy like <f:ajax>. I think our users would benefit from the
consistency. Any thoughts on whether we should/can go this route? Did
I miss anything in the <f:validteBean> behavior that would prevent us
from using a handler-time solution?
Andy
15 years
[jsr-314-open] default converter for java.util.Date type
by Dan Allen
Issue 494 (
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=494)
seemed to have fallen off the map, but since I just implemented a solution
in Seam, I have decided to bring it back up. It's really inconvenient not to
have at least a default converter for the type java.util.Date. While
certainly dates inputs are something which vary widely, it's tedious in the
early stages of an application to have to plug a DataTimeConverter on every
input that accepts a date.
The solution is as simple as registering DateTimeConverter with the class
java.util.Date and accepting the defaults. The developer can simply specify
a nested <f:convertDateTime> to override. The main limitation is that there
is no way to know if the developer intends to capture a date or date + time
since the type java.util.Date doesn't provide this information. Thus, we
capture date and let the user specify a converter otherwise.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
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.
15 years
Re: [jsr-314-open] support for html entities
by Ed Burns
>>>>> On Fri, 27 Mar 2009 17:29:24 -0700, Alexandr Smirnov <asmirnov(a)EXADEL.COM> said:
AS> It is possible. I've done that one time for Facelets ( even with
AS> properly source encoding support ). The issue still exists in the
AS> Facelets BugZilla : https://facelets.dev.java.net/issues/show_bug.cgi?id=111
AS> As I see in the JSF 2.0 code there is same SAXCompiler as Facelets uses,
AS> therefore I can convert my old patch to the current implementation.
THat would be great, thanks.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
Re: [jsr-314-open] More spec issues
by Ed Burns
>>>>> On Fri, 27 Mar 2009 11:15:08 -0400, Simon Lessard <Simon_Lessard(a)DMR.CA> said:
SL> Hi all,
SL> I have a couple more issues I found while implementing the latest
SL> spec:
Thanks. Can you share with the EG if you're doing a complete new Impl?
This would be big news for me because AFAIK, Sun and Apache are the only
ones doing new JSF2 impls.
SL> * ViewHandler.FACELETS_VIEW_MAPPINGS_PARAM_NAME: The doc says that
I'll let others chime in on that one. The behavior as specified seems
useful to me.
SL> * ViewHandler.getPageDeclarationLanguage(): JavaDoc gives two
SL> default implementations, one invoking the factory from FactoryFinder
SL> (useful) and the throws UnsupportedOperationException
SL> one. Personally, I'd keep only the real method here as the
SL> processing doesn't involve any private/non standard API;
I see your point, but we did it this way to allow JSF 1.2 ViewHandlers
to easily be detected, so we'll leave this the same as well.
SL> * AjaxBehavior.getHints(): JavaDoc says it should return an emprt
SL> Set (like ClientBehaviorBase), making the method declaration in
SL> AjaxBehavior useless. However Mojarra returns a Set containing
SL> SUBMITTING, so I assume the code is right and the JavaDoc wrong
SL> here;
Roger integrted this one.
SL> * UIComponentBase.initialStateMarked(): This method is not defined
SL> in the JavaDoc while the two others from PartialStateHolder are.
I think this one's ok as is.
SL> * ExternalContext.getRequestCookieMap(): Can the return value be
SL> changed from Map<String,Object> to Map<String, Cookie> please?
We can't do that because Cookie is declared in the Servlet spec, and
Portlet people wouldn't be happy if we added that to our API.
SL> * PageDeclarationLanguageFactory.getPageDeclarationLanguage(String
SL> viewId): The JavaDoc says that ClassNotFoundException should be
SL> thrown when no valid PLD can be found. However,
SL> ClassNotFoundException is a checked exception and the method does
SL> not that this exception in its throws clause. The doc should either
SL> says to wrap it in a FacesException or add ClassNotFoundException to
SL> the throws clause;
I've removed the @throws ClassNotFoundException
SL> * ExceptionHandler.handle(): The spec specifies that this method
SL> should only throw a FacesException if an internal error occurs while
SL> handling the exception. However, it also says to throw either
SL> ServletException or PortletException depending on the environment
SL> and those are checked exception not declared in the throws
SL> clause. Mojarra wrap them in a FacesException, so the spec mighth
SL> ave to be ajusted to reflect that.
SL> That's all for now,
SL> ~ Simon
SL> ________________________________
SL> From: JSR 314 Open Mailing list on behalf of Ed Burns
SL> Sent: Fri 3/27/2009 10:30 AM
SL> To: JSR-314-OPEN(a)JCP.ORG
SL> Subject: Rename: PDL->VDL
SL> We have "View" everywhere else, so we should rename
SL> PageDeclarationLanguage to ViewDeclarationLanguage.
SL> I'm taking care of this now.
SL> Ed
SL> --
SL> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
SL> | homepage: | http://ridingthecrest.com/
SL> <HTML dir=ltr><HEAD><TITLE>Rename: PDL->VDL</TITLE>
SL> <META http-equiv=Content-Type content="text/html; charset=unicode">
SL> <META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
SL> <BODY>
SL> <P><FONT face=Arial size=2>Hi all,</FONT></P>
SL> <P><FONT face=Arial size=2>I have a couple more issues I found while implementing the latest spec:</FONT></P>
SL> <UL>
SL> <LI><FONT face=Arial size=2>ViewHandler.FACELETS_VIEW_MAPPINGS_PARAM_NAME: The doc says that the implementation should also read original Facelets' param for the purpose of defining mappings. I don't think that's a good idea. Facelets was not a standard up to that point and users shouldn't really expect no migration effort at all. I know that enforcing that param would allow xisting applications using facelet.jar to be deployed in 2.0 environment, but to my knòwledge, no other spec read some non standard context params (I may be wrong though). If we do enforce the original parameters, then we'll be stuck with it forever so at least let use only that one and not define a new one;</FONT></LI>
SL> <LI><FONT face=Arial size=2>ViewHandler.getPageDeclarationLanguage(): JavaDoc gives two default implementations, one invoking the factory from FactoryFinder (useful) and the throws UnsupportedOperationException one. Personally, I'd keep only the real method here as the processing doesn't involve any private/non standard API;</FONT></LI>
SL> <LI><FONT face=Arial size=2>AjaxBehavior.getHints(): JavaDoc says it should return an emprt Set (like ClientBehaviorBase), making the method declaration in AjaxBehavior useless. However Mojarra returns a Set containing SUBMITTING, so I assume the code is right and the JavaDoc wrong here;</FONT></LI>
SL> <LI><FONT face=Arial size=2>UIComponentBase.initialStateMarked(): This method is not defined in the JavaDoc while the two others from PartialStateHolder are.</FONT></LI>
SL> <LI><FONT face=Arial size=2>ExternalContext.getRequestCookieMap(): Can the return value be changed from Map<String,Object> to Map<String, Cookie> please?</FONT></LI>
SL> <LI><FONT face=Arial size=2>PageDeclarationLanguageFactory.getPageDeclarationLanguage(String viewId): The JavaDoc says that ClassNotFoundException should be thrown when no valid PLD can be found. However, ClassNotFoundException is a checked exception and the method does not that this exception in its throws clause. The doc should either says to wrap it in a FacesException or add ClassNotFoundException to the throws clause;</FONT></LI>
SL> <LI><FONT face=Arial size=2>ExceptionHandler.handle(): The spec specifies that this method should only throw a FacesException if an internal error occurs while handling the exception. However, it also says to throw either ServletException or PortletException depending on the environment and those are checked exception not declared in the throws clause. Mojarra wrap them in a FacesException, so the spec mighth ave to be ajusted to reflect that.</FONT></LI></UL>
SL> <P><FONT face=Arial size=2>That's all for now,</FONT></P>
SL> <P><FONT face=Arial size=2></FONT> </P>
SL> <P><FONT face=Arial size=2>~ Simon</FONT></P>
SL> <P><BR></P>
SL> <DIV dir=ltr>
SL> <HR tabIndex=-1>
SL> </DIV>
SL> <DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> JSR 314 Open Mailing list on behalf of Ed Burns<BR><B>Sent:</B> Fri 3/27/2009 10:30 AM<BR><B>To:</B> JSR-314-OPEN(a)JCP.ORG<BR><B>Subject:</B> Rename: PDL->VDL<BR></FONT><BR></DIV>
SL> <DIV>
SL> <P><FONT size=2>We have "View" everywhere else, so we should rename<BR>PageDeclarationLanguage to ViewDeclarationLanguage.<BR><BR>I'm taking care of this now.<BR><BR>Ed<BR>--<BR>| ed.burns(a)sun.com | office: 408 884 9519 OR x31640<BR>| homepage: | <A href="http://ridingthecrest.com/">http://ridingthecrest.com/</A><BR></FONT></P></DIV></BODY></HTML>
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
[jsr-314-open] support for html entities
by Dan Allen
I received a message from a JSF community member asking about the status of
the request to allow a broader range of HTML entities in Facelets views (
https://facelets.dev.java.net/issues/show_bug.cgi?id=96). Having been
reminded about this shortcoming, I can admit that it has been a huge pain to
have such limited support for entities. Can we get this fixed as a
implementation detail in Mojarra? It doesn't seem to me like a spec issue.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
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.
15 years, 1 month
Re: [jsr-314-open] Rename: PDL->VDL
by Ed Burns
>>>>> On Fri, 27 Mar 2009 10:38:17 -0400, Simon Lessard <Simon_Lessard(a)DMR.CA> said:
SL> If you're doing this kind of refactoring, then I think you should
SL> move the new "vdl" package to javax.faces.vdl rather than
SL> javax.faces.webapp.vdl. It would be better that way since the vdl is
SL> not by definition linked to the message transport layer
SL> (webapp). For example, it would be theoretically possible to load a
SL> view without being in webapp (assuming the vdl doesn't requires
SL> accept to a ServletContext) then serve it to the client using
SL> whatnot technology (assuming that technology has a FacesServlet
SL> equivalent).
I prefer to think of it as renaming, not refactoring, but the IDE button
is the same :). Anyhow, I think javax.faces.view is better. I'll do
that.
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month