[jsr-314-open] [#jsf2next] Converers on Input/Output components.
by Ed Burns
>>>>> On Thu, 10 Dec 2009 02:13:33 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> As a side note, I like the subject filter [JSF2.NEXT] for forward-looking
DA> issues. It keeps it open (JSF 2.1 only works until JSF 2.1 is out). Plus, it
DA> matches our twitter hash tag #jsf2next ;)
Heck, we should just use #jsf2next as the header. Twitter didn't exist
when the email subject guidelines were written!
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
Re: [jsr-314-open] [ajax] My AI on PartialResponseWriter.
by Jim Driscoll
Ah, I get what you're up to now. Yes, this is a valid use case.
However, I really don't like the idea of allowing this fashion of usage,
and would prefer we provide the ability to do that through other means.
Calling encodeAll for another component from within a component that
won't render the result inside itself is a quite different case than
would be allowed in a non-Ajax component, and as such would degrade
ungracefully. There's also the problem of that encouraging a rather
sloppy coding style. And finally, we'll be buffering the output of the
component, which could be problematic from a performance perspective.
But nothing immediately springs to mind as an alternative. I'm sure we
could always add one, but maybe that usage really is the simplest way -
let me think about it, and dink around with the code a bit.
I'd actually wanted to allow startUpdate for the purpose of modifying
part of the page which isn't directly corresponding to a JSF component -
which is another use case that we must support.
Jim
On 12/10/09 4:32 PM, Ken Paulsen wrote:
>
>
> Jim Driscoll wrote:
>> Thanks for the description - sorry to make you type it out, but you'll
>> see why, I think, in the comment below.
>>
>> On 12/10/09 2:15 PM, Ken Paulsen wrote:
>>>
>>> Hi Jim,
>>>
>>> This is what I was imagining as a >1 deep nesting:
>>>
>>> * PartialViewContextImpl calls writer.startUpdate for componentX
>>> * PartialViewContextImpl calls componentX.encodeAll()
>>> * componentX calls writer.startUpdate for componentY b/c it knows
>>> componentY must change if it changes
>>
>> So far, so good. But: calling writer.startUpdate doesn't actually call
>> componentY.encodeAll(). Is that assumed in your example? When is the
>> encode going to be called? And by what means?
> No I did not assume startUpdate would call encodeAll().
> PartialViewContextImpl calls encodeAll for X. During the encoding of X,
> it calls startUpdate/encodeALL/endUpdate for Y, and Y calls
> startUpdate/encodeAll/endUpdate for Z. X and Y are assumed to be smart
> Ajax-enabled components with known associated components that they
> auto-update during PartialRequests.
>
> Thanks!
>
> Ken
>>
>>> * componentY calls writer.startUpdate on componentZ b/c it knows...
>>> * componentY calls writer.endUpdate
>>> * componentX calls writer.endUpdate
>>> * PartialViewContextImpl calls endUpdate
>>>
>>> For ordering, I would suggest a depth first traversal (i.e. add the
>>> buffered output at the end* call).
>>
>> Yeah, a method scoped queue would make sense if this use case makes
>> sense.
>>
>> Jim
14 years, 4 months
[jsr-314-open] [ajax] My AI on PartialResponseWriter.
by Jim Driscoll
Below, here's a description of the changes I'd like to make to the
PartialResponseWriter - describing the problem, and the changes that I'd
like to make in broad detail.
This is one of the AIs I had from our Ajax breakout meeting.
Please comment within a day or two, I'll write up a formal proposal with
the exact proposed language to go in once I know I'm not spinning my
wheels on a DOA idea.
To save time, section 4 is the only part you may have a problem with -
since it's the only part that changes current behavior... but we do
have to address the issue somehow, so if you hate this idea, please
propose another that also works...
Jim
----------
Problem Description:
PartialResponseWriter has very little JavaDoc or spec associated with
it. Users are finding it difficult to use as a result. Additionally,
the implicit call to startUpdate means that writing out other XML
directives from a custom component is quite difficult.
The JavaDoc preample says:
PartialResponseWriter decorates an existing ResponseWriter to support
the generation of a partial response suitable for Ajax operations. In
addition to the markup generation methods inherited from
javax.faces.context.ResponseWriter, this class provides methods for
constructing the standard partial response elements.
The individual method summaries say such things as:
void startUpdate(String targetId)
Write the start of an update operation.
And
void startEval()
Write the start of an eval operation.
And
void startDocument()
Write the start of a partial response.
Currently, what to do if you were to call a startXXX method while
already in a startXXX method is unspecified.
The spec (section 13.4.4.1) simply says:
Writing The Partial Response
JavaServer Faces provides javax.faces.context.PartialResponseWriter to
ensure the Ajax response that is written follows the standard format as
specified in Section 1.3 “XML Schema Definition for Partial Responses”
Implementations must take care to properly handle nested CDATA sections
when writing the response. PartialResponseWriter decorates an existing
ResponseWriter implementation by extending
javax.faces.context.ResponseWriterWrapper. Refer to the
javax.faces.context.PartialResponseWriter JavaDocs, and the JavaScript
documentation for the jsf.ajax.response function for more specifics.
Proposal:
We need to tighten up the spec in several ways:
1) Add comments to the JavaDoc that PartailResponseWriter will typically
have startDocument and startUpdate called before the component can get
ahold of it. Note that this is to allow interoperability with
components that are not instrumented for Ajax.
2) Expand description in 13.4.4.1 to describe that an error will be
thrown if:
startDocument is called more than once on a response.
any method is called after endDocument.
any method is called before startDocument
3) Add a description to the spec of what methods will typically be
called before the client receives the PartialResponseWriter in
RenderResponse. Describe when this is not so (render = @none).
4) Allow for the calling of other methods besides startUpdate within a
normal component’s Render Response.
a) I propose that we treat all calls to the following methods as having
their content placed on a queue, to be written out after the endUpdate
is called:
delete
redirect
startEval/endEval
startUpdate/endUpdate
startExtension/endExtension
startInsertBefore/endInsert
startInsertAfter/endInsert
startError/endError
updateAttributes
b) nesting is only one deep - i.e., since the startUpdate is already
called, if you call startEval, it will be an error to call anything
other than endEval before calling any other method from this list...
5) Update JavaDoc to indicated paired methods -
startEval/endEval
startUpdate/endUpdate
startExtension/endExtension
startInsertBefore/endInsert
startInsertAfter/endInsert
startError/endError
It will be an error, and an exception will be thrown, to call one
method without the other.
Concluding statement:
While the description of this behavior (in particular the queuing) may
be a little difficult, I believe that this behavior most closely matches
what users are expecting when they currently use the API. If this
approach is accepted by the EG, I’ll write up the formal changes.
14 years, 4 months
[jsr-314-open] [www.javaserverfaces.org] A couple of things
by Kito Mann
Two things:
(1) Where should we place a link to o the AJAX JSF Matrix?
(http://www.ajaxjsf.com/)? I'm going to continue talking to Thomas
about integrating it with JSFCentral, but in the meantime, it'd be
nice to have a link to it.
(2) For the Getting Started section, I see two problems: (a) it only
talks about JSF 2, and (b) it doesn't give you any info if you're not
using Maven. Resolving (b) is simple enough, but for (a), we need to
decide if we're only going to talk about JSF 2. I think leaving out
1.2 is a bit strange, but it may not be a bad strategic move. People
are still starting or enhancing 1.2 projects, though.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
14 years, 4 months
Re: [jsr-314-open] [www.javaserverfaces.org] A couple of things
by Ed Burns
>>>>> On Thu, 10 Dec 2009 01:01:17 -0500, Lincoln Baxter III <lincolnbaxter(a)gmail.com> said:
LB> [ Read this paragraph if in a hurry ]
LB> I've updated the http://www.javaserverfaces.org home page, and done a
LB> little reorganization on some others. I've word smithed a little and
LB> attempted to present main points with concise descriptions. This will
LB> continue to evolve, not only as we decide what information we want to
LB> present, but also learn to express what our vision for JSF is.
Big fan of the "executive summary" section.
FYI, I brought javaserverfaces.org and the logo contest up at the
non-technical meeting for the team responsible for the Java web tier.
(Sun calls this kind of meeting a "p-team" meeting.) Transparency works
in many ways, and that also means transparency to the componany
sponsoring the JSR. Naturally, there was support for these ideas and
the spirit behind them, but I can't commit to any official position
regarding the current implementation of these ideas.
In terms of technical content, I don't like using com.sun.faces as the
groupid for the maven archetype It should be
groupId: javax.faces
artifactId: jsf-api
version: 2.0
scope: provided
We should mention that the preferred way to install a JSF impl it is to
put it into your container's lib dir, and describe also the
non-preferred way to put it into WEB-INF/lib.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
[jsr-314-open] [community] feedback from #devoxx #jsf2next presentation
by Dan Allen
After Devoxx, I never stopped to look back for published feedback about the
3 hour JSF 2 university presentation that Andy, Pete and I gave at Devoxx. I
finally did, and to my pleasant surprise, the feedback was very positive.
Here are some clips:
"The course was divided into 3 sections: View (Andy), Controller (Dan) and
Model (Peter). What I liked about there presentation style was the fact that
they showed how something was in JSF 1.x, how they improved it in JSF2.0 en
what they should improve in JSF 2.next. The presentation given by Peter Muir
was the best of the 3. He was very enthusiastic and explained why JSF
shouldn’t concern (very much) about the model. I’ve learned a lot in this
presentation." [1]
"Of particular value was the deep dive into the JSF 2.0 spec, with 3 key JSF
people, Dan Allen, Peter Muir, and Andy Schwartz introducing various aspects
of the related specs. I thought they all spoke great: very clearly and with
in depth knowledge of their subject matter." [2]
"It was also cool to be told that these 3 speakers weren't just there to
tell us about the JSF spec (and other related specs), but to invite us to
become part of the process. Sure, that's what one is always told in sessions
of this kind, but here it seemed to be really in earnest, with nothing more
being needed than an account on java.net to log feature requests for JSF
2.0." [2]
"So yesterday I had a BOF with the JSF spec leads (well the 3 key persons:
Dan Allen, Peter Muir and Andy Schwartz) and we could in a very relaxed
setting ask them some questions about the JSF 2 spec. So we could find out
how and why they made some decisions. The question I asked them: "Why is JSF
2 not more focused on components so that I can mix and match components of
3rd party providers?". The answer was that they are looking into that and
that a lot of problems one has with that right now is how resources are
loaded: all 3rd parties made something on their own. So now all the AJAX
stuff needs to be gathered and then they will look into that. Good answer,
I'm glad that they are aware of what lives in the community." [3]
And here are the three amigos in action:
[image:
?ui=2&view=att&th=1257a2836edd963c&attid=0.1&disp=attd&realattid=ii_1257a2836edd963c&zw]
I also found feedback about Antonio's Java EE 6 presentation.
"The first presentation was again a 3 hours during class about the Java EE6
platform by Antonio Goncalves and Alexis Moussine-Pouchkine....It was the
best presentation I’ve seen on Devoxx this year. They explained most of the
new features in EE6 (validation, jsf, EJB3.1,EJB Lite, JSF2.0,
Servlet3.0,JAX-RS 1.1,JPA2.0,..) and gave an example for each feature. I’m
very excited about JavaEE6. It’s a lot easier and has a lot of cool
features. They told us that Java EE6 (and GlassfishV3) will be released in
December. I can’t wait." [1]
I should also mention that it was during Devoxx that Sebastian Hennebrueder
published his "JSF 2 - evaluation and test" [4] novel-sized entry. Thanks to
coodination by Andy, the very next day four JSR-314 EG members representing
three companies sat down with him and listened to his concerns. Now if that
doesn't show sign of life from the EG, I don't know what does. We are
continuing to work with Sebastian to weave his ideas into the design
discussions for #jsf2next.
[1] http://dev.eek.be/2009/11/devoxx-university-2009/
[2] http://java.dzone.com/news/devoxx-day-1-university-day-1
[3] http://ctpjava.blogspot.com/2009/11/devoxx-day-2.html
[4] http://www.laliluna.de/jsf-2-evaluation-test.html
I suppose I should now turn this into a blog entry :)
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years, 4 months
[jsr-314-open] [ADMIN] Resend of JSR-314 EG email practice
by Ed Burns
Rather than copy and paste the whole email, which may be found at [0],
I'm only including the bit about our email process.
EB> Please send all mail in ASCII, not HTML. If you must, non ASCII
EB> attachments are ok, but generally it's better to put that sort of
EB> thing as an attachment to an issue in the issue-tracker.
EB> As mentioned above, everyone needs a java.net user id. We'll be using
EB> the javaserverfaces-spec-public [5] and javaserverfaces-spec-eg [6]
EB> projects. In the spirit of JCP 2.6, we intend to use the former more
EB> than the latter, since the latter is private to EG members only.
EB> We'll use the javaserverfaces-spec-public issue tracker for all
EB> issues. Generally only the spec leads will be submitting issues here,
EB> but you may be asked to submit one yourself for expedience. We'll use
EB> the javaserverfaces-spec-eg issue tracker to host the development of
EB> the spec document itself.
EB> We may have occasional conference calls if the need arises.
EB> Reference Implementation and TCK
EB> The official reference implementation for JSR-314 is being developed
EB> out in the open on the java.net project called javaserverfaces.
EB> Please let us know if you have a problem with this practice. The TCK
EB> will be developed by Sun internally.
EB> Email practices
EB> During JSR-127, we used the following conventions, and they seemed
EB> to work reasonably well, especially for the purposes of looking back
EB> over the archive.
EB> The subject line of All core discussion threads will be prefixed
EB> by [TargetVersion-IssueNumber-ShortName]. TargetVersion is
EB> optional and is assumed to be JSFv2.0 if omitted. Having this
EB> convention covers us if we end up talking about something targeted
EB> at JSFv2.1 or 3.0. IssueNumber is the issue number in the
EB> javaserverfaces-spec-public issue tracker. If we need to refer to
EB> an issue in the EG private tracker, prefix the number with "EG".
EB> ShortName is a WikiWord that enables us to look at the email
EB> subject line and quickly recall the topic of the thread. For
EB> example, Subject: "[43-XMLSchema] Status"
EB> If you want to originate a thread, send it to the EG prefixed by
EB> [NEW] in the subject line. If the spec lead sees the need for an
EB> issue tracker issue, we'll put it in the issue tracker, re-subject
EB> the email to be prefixed with [IssueNumber-ShortName], and
EB> discussion will continue on that thread, NOT the thread with [NEW]
EB> in the title.
EB> Put [ADMIN] at the start of the subject line for all schedule and
EB> administrative related emails (such as this one).
[0] http://archives.java.sun.com/cgi-bin/wa?A2=ind0903&L=JSR-314-OPEN&T=0&O=D...
EB> [1] http://www.jcp.org/en/jsr/detail?id=314
EB> [2] http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad
EB> [3] http://wiki.java.net/bin/view/Projects/Jsf2Requirements
EB> [4] http://archives.java.sun.com/jsr-314-eg.html
EB> The archive for the open list is
EB> http://archives.java.sun.com/jsr-314-open.html, though it appears to not
EB> be working yet.
And it appears not to be working again! Dan's working on it.
EB> [5] https://javaserverfaces-spec-public.dev.java.net/
EB> [6] https://javaserverfaces-spec-eg.dev.java.net/
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
Re: [jsr-314-open] [JSF2.NEXT] Converers on Input/Output components.
by Ed Burns
>>>>> On Thu, 10 Dec 2009 02:11:50 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> On Thu, Dec 10, 2009 at 1:45 AM, Kito Mann <kito.mann(a)virtua.com> wrote:
>> How does Seam implement this?
>>
DA> As soon as I read the words "converter chain", it set off a little itch in
DA> my brain somewhere. Sure enough, Seam has a converter chain.
DA> http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/ui/src/ma...
DA> I'm pretty sure somewhere I have even written about it, but that memory has
DA> sort of faded.
This issue is worthy of consideration.
DA> I can't believe we didn't push for this in JSF 2.0, but let's just say that
DA> we were already advocating on too many fronts and we simply didn't
Dan, can you please add an issue to the issuetracker?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
[jsr-314-open] [JSF2.NEXT] Converers on Input/Output components.
by Lincoln Baxter III
Converters are a great tool, and I use them all the time -- problem is,
I sometimes need to use more than one converter (rich text processing,
for example) and that leaves me having to write my own converter chain
class, instantiating that class in a bean, then binding it to my Facelet
component through EL.
This seems like a lot of work, when what I'd really like to see is
chaining support out of the box. I see two potential issues to prevent
this:
Object -> String
String -> Object
Right now, chains only operate on strings. which could cause some
confusion, potentially, but I see reasons to enable multiple converters
per component, and convert (in list style) in the order in which the
converters were added.
We allow multiple validators, but not multiple converters. This caveat
recently bit me as Kito found out, I was converting URLs into <a> tags
as part of a comment output component. In order to accomplish this, I
was disabling encoding on the component itself, so that the converted
output <a> tag would not be rendered as text. I had attached a converter
prior to the link converter that was supposed to take care of the
escaping. Problem is... the last converter added in the Facelets file
wins because only one is allowed, so my site was (until I fixed it)
vulnerable to XSS attacks - a BIG problem.
I propose adding converter chaining, by default, to UIComponent. In
effect, turning converters into filters. This isn't a hard change,
doesn't add much complexity, but does fix one of those things that
people end up having to do themselves (Seam provides a ConverterChain,
and I did some Googling to find that many other people are doing this
themselves.) This is low hanging fruit that we can pick.
Thoughts?
---
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years, 4 months