Re: [jsr-314-open] [JSF 2.1 NEW] composite component namespace simplification
by Dan Allen
Oops, I was getting my URLs and URNs mixed up. Thanks for the correction.
I'm torn. The fewer characters do make it easier for my brain to remember
and also gives an indication that the namespace is somehow different. I
don't think it would hurt as an alternative syntax. Those who prefer URLs
can just stick with them. Depends on whether we want to introduce this
variance, and thus one more thing to explain.
Another option would be to allow users to alias one namespace to another so
they can control how covenient it is. Just brainstorming.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
and developers.
On Dec 8, 2009 7:06 AM, "Pete Muir" <pmuir(a)redhat.com> wrote:
I would argue against this, on the basis of learnability. Anyone who has
used XML schema immediately understands the current scheme and can transfer
their domain knowledge about XML across. David's proposed syntax is a
complete deviation from the standard. Dan's is a bit better, as it is a
valid URI [1], but it still isn't a URN [2].
To make it a valid URN (which arguably this should have been in the first
place ;-), it could be:
urn:faces:components:util
But is that really more readable? Perhaps my brain is just addled by URLs
;-)
[1] http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
[2] http://en.wikipedia.org/wiki/Uniform_Resource_Name#URN_Syntax
On 7 Dec 2009, at 22:07, Dan Allen wrote: > I like the idea, but I'm
wondering if we can still ret...
14 years, 4 months
[jsr-314-open] [2.0.MR1-698-RedirectParam] view-param is supposed to be redirect-param
by Dan Allen
I've been meaning to file this issue for a while. I always seem to remember
when I am on stage giving a presentation, but not when at my computer :(
The <view-param> element that was introduced as a child of the <redirect>
element was supposed to be called <redirect-param>. Unfortunately, something
got
lost in translation and the terminology for "view parameters" got mixed up
with
redirect parameters. (I take the blame for not following up with a review of
this
topic in the spec document prior to final release).
I'll explain the difference. A view parameter is a mapping between a request
parameter and a bean property and is associated with a particular view ID.
If
you are linking or redirecting to that view ID, you can have those mappings
run
in reverse to build a query string. This is activated with the "include view
parameters" switch on the link (UIOutcomeTarget) component or <redirect>
element.
A redirect parameter in the navigation is equivalent to an <f:param> on a
button
or link. It is a manual setting, which may (or may not) override the value
of a
view parameter. A perfect example is when you want to create a link to the
previous page of a paginated list. You manually override "page" so that it
is
one less than the current page. <f:param name="page" value="#{nav.page -
1}"/>
<view-param> has no business being a child of <redirect> and should be
renamed
to <redirect-param>.
<navigation-case>
<from-action>#{editor.save}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/entry.xhtml</to-view-id>
<redirect>
<redirect-param>
<name>id</name>
<value>#{entry.id}</value>
</redirect-param>
</redirect>
</navigation-case>
If you wanted to let view parameters manage the value of the "id" request
parameter, it would be:
<navigation-case>
<from-action>#{editor.save}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/entry.xhtml</to-view-id>
<redirect include-view-params="true"/>
</navigation-case>
/entry.xhtml
<f:view>
<f:metadata>
<f:viewParam name="id" value="#{entry.id}"/>
</f:metadata>
...
</f:view>
See the difference?
-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] [ajax] Fwd: JSF Ajax Meeting Minutes
by Jim Driscoll
FYI, these are the minutes from the Ajax meeting we held on Nov 24th.
I'm still working off this list of issues, btw.
Jim
-------- Original Message --------
Subject: [jsr-314-open] JSF Ajax Meeting Minutes
Date: Tue, 24 Nov 2009 11:03:10 -0800
From: Jim Driscoll <Jim.Driscoll(a)Sun.COM>
To: jsr-314-ajax-ext(a)sun.com
Nov 24th, JSF Ajax Meeting minutes
Attending
Nick
Alex
Jay
Ted
Andy
Roger
Jim
During the meeting, we primarily went over the following list of issues:
http://www.jboss.org/community/wiki/JSFAjaxpointsfordiscussionwithEG
First up: PartialResponseWriter should be more intelligent about
handling new elements when inside a component. spec bug 658.
One idea: if a new element is started, write it out after the update is
finished writing. This is a small spec change that could be a spec
clarification, and a fix to the impl (the impl fix may take a little
while - it's liable to be somewhat risky change). (AI: Jim will write
up a tentative proposal)
Other idea (from Alex): Allow for some override of PartialViewContext,
to allow for a more robust rendering options. There were some concerns
about multi-libarary compatability, and this would be an attempt to
allow for better multi-libarary interop. Alex tentatively agreed to
flesh out this idea, if the above proposal does not meet RichFaces' needs.
There's a request for a new event - after complete, and after each
individual dom update (success happens after *all* dom updates). We'll
need more details (I'll add a new spec RFE for this).
Errors - in the event that 3 updates happen, if the 2nd fails, the third
should still be attempted. This falls into the level of spec
clarification, and impl fix. I'll file appropriate bugs.
Add request options to event payload. Alex will take AI to elaborate.
Add begin, complete, success constants. ex: jsf.ajax.BEGIN ? I'll add
a spec RFE.
Add ability to abort a request before XHR is created: from the begin
event, a token could be aquired, and an abort() function called. Jim
will take the AI to write this up.
Response XML needs a version attribute. I'll file a spec RFE.
Add ability to skip response processing - prehaps an abort like begin?
(Jim AI)
Support for request timeout (will file as spec RFE) Can be quite
serious, since a network error can result in a hung app. Would like a
config param (from the server) on a per-app basis, js api for
per-request. Since this is so serious in effect, I'll also file a impl
RFE as well.
Form serialization should happen at the last possible second (just
before the begin event), not on submission time. There was wide
agreement that this is a problem, and requires a spec change. May only
be a spec clarification - I'll have to check the spec to be sure.
Regardless, this is a spec bug, and I'll file it.
Be able to get a list of all registered JSF events. (and, while we're
at it, the ability to deregister an event)... This will probably
require two new functions client-side. Jim will file RFE on spec.
Address IE freeze for inline script eval - either setTimeout or
execScript. (Jim will file impl bug).
Add ability to append <style> tag as part of the component. (Jim will
file as impl bug)
The group agreed to meet at the JSF Summit (without Alex,
unfortunately), tentatively on Thursday.
Please reply-all with any corrections or additions to these minutes.
Jim
14 years, 4 months
[jsr-314-open] Quebec Trip report
by David Geary
I just got done with two days of training in Quebec City (you can follow my
exploits, if you're interested, at twitter.com/davidgeary). The first day
was advanced JSF 1.2, and I watched students' eyes glaze over as I covered
the complexities of custom components, renderers, converters, and
validators. Java code, XML configuration, encoding, decoding, etc. -- you
know the drill. One of the developers had used Rails, and he looked
downright depressed. But I knew day 2 would be different. Oh yeah.
Because day 2 was all JSF 2, and it was an entirely different story. I
started with an overview of the new features in JSF 2, and then dove deeply
into Facelets, templates, composite components, and Ajax. Students were
blown away. Blown. Away.
What was a fairly sullen group on day one turned into a rambunctious group
of excited developers on day two. Could they use JSF with WebLogic 10? they
wanted to know. What about RichFaces, when will that support JSF 2?, they
asked. Until we upgrade to JSF 2, can we do this templating stuff with the
open source version of Facelets?. The Rails guy was all smiles. This is
pretty cool, eh? I said (eh, if you don't know, is Canadian for hunh). Oh
yeah, they said. Oh yeah.
As I was covering JSF 2, I could feel the excitement building in the room.
Lots of smiles, lots of laughter, and excited chatting and whispers in the
incredibly beautiful language that is Quebec French, between students. It
was really phenomenal.
Early in the morning, the blizzard started. I'm teaching class, and, out the
window, snow is coming down like hell, in all different directions because
of the fierce winds that accompanied a major snowstorm that dumped nearly a
foot of snow on the ground during class. I started out with 11 students, and
by the time I finished class at the end of the day, I had ... 10 students!
I'm telling you, those guys were mesmerized by JSF 2. Even though the
weather gave them good reason to leave class early, only one guy, who had
kids that he had to pick up because les ecoles etait fermer, left class
early.
I got done with the material, and told them that they were free to go, that
they probably should go because of the storm, but that I'd be happy to
answer questions, and even with the intense blizzard raging outside, they
all stuck around for another 1/2 hour, brainstorming with me about how they
could upgrade from 1.2 to 2.0, given their current situation.
For me, this training, unlike any other I've ever done, was almost a
religious experience. For us, it's validation that all the hard work we've
put into JSF 2 is paying off.
A bientot,
david
14 years, 4 months
Re: [jsr-314-open] Fwd: Nomination for Matthias Wessendorf
by Lincoln Baxter, III
Sounds like we have the start of a consensus. How do we proceed?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 13, 2009 12:55 AM, "Martin Marinschek" <mmarinschek(a)apache.org>
wrote:
sorry to be late to the table, but a sure +1 from me.
regards,
Martin
On Mon, Dec 7, 2009 at 8:39 PM, David Geary <clarity.training(a)gmail.com>
wrote: > > +1, no braine...
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
14 years, 4 months
[jsr-314-open] Fwd: [jsf2.next] Proposal to support new semantic HTML5 tags
by Martin Marinschek
So the new tags don`t add any new attributes in comparison to a normal
span/div?
regards,
Martin
On Fri, Dec 11, 2009 at 11:41 PM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
> HTML5 has a number of new semantically meaningful tags.
>
> See here for a painless introduction:
>
> http://www.techradar.com/news/internet/why-html5-is-here-today-and-not-20...
>
> Block tags include:
>
> article
> aside
> footer
> header
> nav
> section
>
> Inline tags include:
>
> details
> figure
> mark
> time
>
> Then, there's the canvas, audio and video tags.
>
> We can actually support many of these tags with only a minor change in to
> the panelGroup tag.
>
> In addition to the currently allowed "inline" and "block", I would add the
> following:
>
> span
> div
> article
> aside
> footer
> header
> nav
> section
> figure
> mark
>
> details and time deserve their own tags, I think, as do canvas, video and
> audio, and are not part of this proposal.
>
> We may wish to consider deprecating inline and block. We've never
> deprecated attribute values before, but hey, first time for everything.
>
> Note that for backward compatibility with particularly lame (IE) browsers,
> a shiv needs to be included in the page, as found here:
>
> http://code.google.com/p/html5shiv/
>
> Whether this would be included automatically, should, I think, be
> implementation specific.
>
> Please comment on this proposal, and I'll add it to the spec issue tracker
> after we have consensus.
>
> Jim
>
> P.S. Molly's HTML 5 talk at Rich Web was a good one - can you tell?
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
14 years, 4 months
[jsr-314-open] Fwd: Nomination for Matthias Wessendorf
by Martin Marinschek
sorry to be late to the table, but a sure +1 from me.
regards,
Martin
On Mon, Dec 7, 2009 at 8:39 PM, David Geary <clarity.training(a)gmail.com>wrote:
> +1, no brainer. :)
>
> 2009/12/7 Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
>
> Hi everyone,
>>
>> I'd like to nominate Matthias for access to our list. He's a huge name in
>> the community and has regularly provided design input for the spec.
>>
>> Opinions?
>>
>> Lincoln Baxter III
>> http://ocpsoft.com
>> http://scrumshark.com
>> Keep it simple.
>>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
14 years, 4 months
