[jsr-314-open] Partial Response writer in conjunction with the component API
by Dan Allen
>From the jsr-314-comments mailbox comes this message from Werner Punz
concerning the partial response writer and nested eval blocks.
(For future reference, the moderator of the 314-comments mailbox, which is
currently me, will forward approved messages using the introduction above).
---------- Forwarded message ----------
From: Werner Punz <werner.punz(a)gmail.com>
Date: Mon, Jul 13, 2009 at 4:40 AM
Subject: [jsr-314-open] Partial Response writer in conjunction with the component API
To: jsr-314-comments(a)jcp.org
Hello everyone I have a comment regarding the partial response writer in
conjunction with the component API.
Since this is a grey area I am not quite sure if it is possible to add that
behavior or not.
Following, currently the partial response is handled via a partial response
writer and a special lifecycle, so far so good and very clear.
But the issues arise if you want to combine it with the component api.
Here is the problem:
Usually the partial lifecycle automatically opens an update on the partial
response before working on the component tree or single components to be
rendered!
This is needed to gain backwards compatibility and still enable ppr on
legacy components, however there is an issue with this approach!
What if a component wants to render scripts explicitely or style changes.
MyFaces has covered the script part so far with an optimized auto eval on
the
updated dom tree, but wouldnt it be nice to allow eval blocks from the
component level as well, after all we have the api, and so far it only
really can be utilized
outside of jsf in this manner!
Lets have a detailed look:
Component has to be rendered under a PPR context:
the cycle opens an update with startUpdate and the id of the root component
to be updated!
The lifecycle then calls the encodeBegin on the parent component and that
one traverses into its sub components.
What happens now is that those subcomponents use startElement etc... to
render the html styles and scripts, they do not really
have a safe way to break out and add their own eval sections etc... although
the API is in place
(the only unsafe way would be to close implicitely the update section add
the eval section and reopening again by
parsing again the ppr data from the request and try to avoid any sideeffects
into the lifecycle, this way would not
be broken by my proposal)
What I would recommend as default behaviour, and this can be added since it
is not really specified anyway as far as I could see.
Allow the opening of other sections within an open section and render them
after the main section is closed (stacking embedded sections
and defer the rendering of them).
Example
startUpdate ....
startEval ....
endEval
..
endUpdate
would result in a
<update> ..
</update>
<eval>
</eval>
block
This behavior would give new components which then can check for being in a
ppr cycle a better rendering
behavior by being able to control their ppr behavior directly. It also would
not break compatibility to the
existing implementations, and probably as well would be within the scope of
the existing spec.
Kind regards
Werner Punz
Apache MyFaces
14 years, 9 months
[jsr-314-open] [ADMIN] Max Lanfranconi: Web Archive not updated
by Ed Burns
>>>>> On Thu, 18 Jun 2009 09:50:34 -0700, Max Lanfranconi <max(a)jcp.org> said:
ML> I believe this is working now.
ML> Sorry about the inconvenience.
The sending is working, but the mail archiving stopped around 18 June.
Imre Oßwald alerted me to this on IRC.
Max, can you please fix the mail archive for jsr-314-open?
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
[jsr-314-open] pdl docs change
by David Geary
Please change the description of f:event's listener attribute from:
Method expression pointing to a method expression of that will be called
when the listener's processEvent method would have been called.
To:
A method expression that JSF invokes when an event occurs. That event is
specified with the name attribute.
david
14 years, 10 months
Re: [jsr-314-open] Resolution? (Wrapping Text with a tag)
by Dan Allen
+1
On Wed, Jul 8, 2009 at 6:44 PM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
> In making the changes to the RI, I also discovered that h:inputText had the
> same behavior as h:outputText. Since the code was shared, and the behavior
> was if anything even more nonsensical in the inputText case, I changed the
> behavior for both.
>
> I'm closing the RI bug that this is associated with, and opening a spec
> issue:
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=585
>
> Please comment if you have any concerns. (We still have a day to fiddle
> with it before it goes live.)
>
> Jim
>
>
> On 7/8/09 11:59 AM, Jim Driscoll wrote:
>
>> As I stated in an earlier email, I'd like this wrapped up by today. This
>> isn't an arbitrary date: I'd like to make the RI changes today, so they
>> go out in our second Beta release - if we're going to change something
>> like this, it's best that it be in a Beta, not snuck into an FCS (or
>> even an RC), so we can actually get feedback before committing to the
>> behavior.
>>
>> We seem to have a (very) rough consensus that Andy's proposed solution,
>> not rendering children of outputText, is acceptable. So, I'll proceed on
>> implementing that solution today.
>>
>> If you have serious concerns about this direction, now would be the last
>> best chance to voice them.
>>
>> Jim
>>
>>
>> On 7/8/09 9:55 AM, Jim Driscoll wrote:
>>
>>>
>>>
>>> On 7/7/09 5:52 PM, Lincoln Baxter, III wrote:
>>>
>>>> I'm ok with #1 -- "does not render childre"n. I'm also for providing a
>>>> "backwards compatability switch" -- but it needs to be documented
>>>> clearly in the component PDL docs so that people are aware of it --
>>>> that'll cause unhappy customers.
>>>>
>>>
>>> The switch I had in mind was an implementation-specific switch - we have
>>> a few of those already in Mojarra. Since the behavior wasn't previously
>>> defined in the spec, it doesn't really make sense to document a switch
>>> to change back to previous behavior in the PDL, since the PDL is part of
>>> the spec, and there was no "previous behavior" in the spec.
>>>
>>> But I share your concern and frustration about getting folks to
>>> understand how to fix it if their existing apps break. Release notes are
>>> the usual place where we put such documentation.
>>>
>>> This is good in my eyes because it makes a piece of JSF more
>>>> intuitive, with the *OPTION* to do something counterintuitive yet
>>>> possibly necessary for a number of reasons - if we continue to make
>>>> improvements of this sort, then JSF will continue to improve.
>>>>
>>>> --Lincoln
>>>>
>>>> 1. Spec that h:outputText is a leaf component: children are not
>>>>>> rendered.
>>>>>>
>>>>>
--
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] Wrapping Text with a tag - what's the correct behavior?
by Jim Driscoll
Currently, when we wrap text in tag, like h:outputText, we get output
like this in mojarra:
<h:outputText id="foo" value="value">text!</h:outputText>
gives:
text!<span id="foo">value</span>
Eww. But, AFAICT, unspec'd, and we don't want you doing that, anyway.
And it seems it's always done it this way. (And to answer, yes, I
occasionally make this mistake when I'm marking up a page - some sort of
mental defect on my part, apparently.)
But when I then put an ajax tag there, like so:
<f:ajax>
<h:outputText id="foo" value="value">text!</h:outputText>
</f:ajax>
(not valid, think of this as pseudo-tag-code)
then I get:
text!<update id="foo">[CDATA[... span ]]</update>
Which, of course, is not a valid return - the text isn't allowed in the
schema to be there.
So, I've got a few different things we can do, but my preferred solution
is to ignore the wrapped text (i.e., don't traverse the children, don't
output anything under foo) for the *ajax* case only, and leave it alone
for the full response case, since I don't want to break any existing
odd-looking code.
I'd repeat this for all components like outputText, I haven't done the
homework yet there to see which components require it.
Thoughts? I don't think we should bother spec'ing this behavior, but
you may disagree.
Jim
14 years, 10 months
[jsr-314-open] f:event and composite components
by David Geary
I have a login component. Here it is, severly truncated:
<html xmlns="http://www.w3.org/1999/xhtml" ...>
<composite:interface>
<composite:attribute name="*validateMethod*"
method-signature="void
listener(javax.faces.event.*ComponentSystemEvent
e*) throws javax.faces.event.AbortProcessingException"/>
...
<composite:attribute name="*loginAction*"
method-signature="java.lang.String action()"/>
</composite:interface>
<composite:implementation>
<h:form ...>
<f:event type="postValidate" listener="#{cc.attrs.*validateMethod*
}"/>
...
<h:commandButton ... action="#{cc.attrs.*loginAction*}"/>
</h:form>
...
</composite:implementation>
</html>
The action method works, but the validate method does not. When I submit the
form, I get this mysterious error:
Unable to resolve composite component from using page using EL
expression '#{cc.attrs.validateMethod}'
So...
1. The expression #{cc.attrs.validateMethod} is in the defining page, not
the using page. The error message is also clearly wrong about being able to
evaluate the component, which is evaluated all over the place in the
defining page. I assume that the method cannot be evaluated, for some
reason.
2. According to the javadocs for f:event, the method signature for
validateMethod above should not be "...ComponentSystemEvent e...". Instead,
it should be "...ComponentSystemEvent...", but if I do that, I get another
mysterious error:
wrong number of arguments
(Note that wrong is not capitalized, and there is no hints as to what the
arguments are)
I don't think I'm doing anything wrong here, so I see no reason why mojarra
can't invoke my validate method when I submit the form. Also, the error
messages need to be rewritten--they are out of step with the usual
meaningful errors that we get nowadays from Facelets.
david
14 years, 10 months
[jsr-314-open] <composite:attribute> optional?
by David Geary
<composite:attribute> tags (without method-signatures) seem to be optional
with mojarra. Is that intended? Unless I'm mistaken, I don't believe the
spec or the docs say anything about that.
david
14 years, 10 months
