Re: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
by Lincoln Baxter, III
It would be nice if it "just worked", and jsf would automatically add/detect
he right place to link scripts & stylesheets.
I'm all for almost anything that removes developer responsibilities and
makes jsf easier to use.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 15, 2009 11:44 AM, "Roger Kitain" <Roger.Kitain(a)sun.com> wrote:
Yeah we'd have to revisit the way we do resource relocation possibly - or
make it more intrinsic.
Andy Schwartz wrote: > > Branching off the HTML5 thread... > > Jason Lee
wrote: >> >> On 12/15/09 ...
15 years
Re: [jsr-314-open] Where's Ed Burns this week?
by Dan Allen
Ed,
Thanks for the update and good luck!
I encourage all of you on this list to submit at least one question, if you
have time available. The rigorousness and accuracy of the JSF certification
exam reflects on the quality of the JSF specification.
Is there a cut off date, Ed? (I can't see from the post because java.net is
currently down).
-Dan
On Mon, Dec 14, 2009 at 5:38 PM, Ed Burns <Ed.Burns(a)sun.com> wrote:
> I'm going heads-down trying to help create the new Sun Certified JSF
> Developer exam (and accompanying course) so I'll be slower than usual to
> respond to emails.
>
> If you need an immediate response, call me on my phone below.
>
> If you want to help out with the exam, submit questions here:
> <http://bit.ly/jsf2certexam>.
>
> Thanks for your understanding!
>
> Ed
>
> --
> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
>
--
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
15 years
[jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408
by Martin Marinschek
Hi,
I just ran into a new issue with 2.0: a condition-change in the test
attribute of a c:if in invoke-application doesn't lead to a changed
component tree, as the tag-handlers are not reevaluated before render
response.
In Facelets old, they were evaluated --> therefore, this is a
backwards compatibility issue.
That now is really a show-stopper for us with regards to 2.0 - the
first real one we encounter.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years
[jsr-314-open] [2.0.MR1-699-ViewParamHint] implicit navigation hint includeViewParams should be faces-include-view-params
by Dan Allen
Same story as issue 698. I noticed this during a presentation, and haven't
remembered to submit until now. I should have caught this before final
draft.
When using implicit navigation, you can pass flags through the query string
that
alter the behavior of the navigation. The first is a redirect flag, the
second
is a hint to include view parameters in the outgoing query string.
- faces-redirect
- includeViewParams
As you can see, there are two problems with the includeViewParams flag.
First,
it uses camel case instead of hyphen delimiters between words and it is not
prefixed with faces-.
When this feature was being discussed, there was a concern that the hints
would
collide with query string parameters used by the application. As a result, a
prefix was added to the redirect hint, making it faces-redirect. However,
includeViewParams was not updated.
Here's the following change that needs to happen in the spec:
includeViewParams ==> faces-include-view-params
And in use:
/entry?faces-redirect=true&faces-include-view-params=true
In the long run, we need to find a cleaner (perhaps type-safe) way of
indicating
an implicit navigation. Using the query string really isn't great. Perhaps
under
the covers the implicit navigation is communicated this way, but we provide
a
Java API that generates this in toString()
return new Navigation("entry", true, true);
-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
15 years
Re: [jsr-314-open] [jsf2.next] Proposal to support new semantic HTML5tags
by Lincoln Baxter, III
+1 to Simon, I prefer individual tags for claritys sake.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 14, 2009 10:12 AM, "Simon Lessard" <Simon_Lessard(a)dmr.ca> wrote:
Hi,
I would highly prefer adding all tags in the h: namespace, else some pages
might end up with just too many imbricated panelGroup to be easily readable.
Furthermore the renderer will be more complex and there would be a, albeit
small, performance overhaul as the attribute has to be evaluated. The only
thing that won't be supported with tags is dynamic change of the layout, but
semantically it makes no sense anyway. I think it would also be time to add
<h:paragraph/>,< h:fieldSet/>, <h:legend/>, briefly every single valid HTML
tags.
Regards,
~ Simon
________________________________
From: jsr-314-open-bounces(a)jcp.org on behalf of Jim Driscoll
Sent: Fri 12/11/2009 5:41 PM
To: jsr-314-open(a)jcp.org
Subject: [jsr-314-open] [jsf2.next] Proposal to support new semantic
HTML5tags
HTML5 has a number of new semantically meaningful tags. See here for a
painless introduction: ht...
15 years
Re: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to support newsemantic HTML5 tags
by Lincoln Baxter, III
While I think the concept of pluggable render kits is interesting, I wonder
if the amount of overhead required to successfully provide a new render kit
for a different content type, using the same facelet layout, is too high,
and if anyone is actually using the functionality. Is it a feature we push
that nobody is going to use?
Most sites host a separate domain to handle this type of accessibility case,
eg: .mobi, or they just use a swappable stylesheet, which is a far simpler
solution.
Accessibility for text to speech is already provided by HTML/CSS.
I think presentation is intrinsicly coupled to the view files except for
trivial use cases, or extremely over-complicated architectures.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 14, 2009 1:46 PM, "Simon Lessard" <Simon_Lessard(a)dmr.ca> wrote:
Well, 2 reasons:
1. It's along the line of Dan suggestion about Facelet and not pushing
direct html to the output, a different render kit might have to intercept
the ResponseWriter to tranform some of those new tags to something else. New
tags allow just that, giving the opportunity to encode the view in just
about anything. Maybe a PADF render kit using iText (althoguh that one could
deal with the HTML), or renderer generating TeX, that in turn gets turned to
PDF using some of the available engines in the endDocument call.
2. Most importantly, semantic and accessibility. A view remains a document
and providing every basic components in the HTML kit enhance that toolbox
and allows developer to add whetever they want to their view, really
expressing what is ment to be there. I'm prety sure this would also come
(especialy?) handy in composite componnet development. As for the
accessibility part, <p> != <div> != <fielset> for a screenreader or any
other accessibility enabled device. As for the header, we could provide
auto-depth detection if not overriden using a level/depth attribute. In
pretty much all project I had to work on we had to redevelop pretty much all
those components because Facelets was not an option at the time (and
Facelets would have been to HTML coupled anyway).
Regards,
~ Simon
________________________________
From: jsr-314-open-bounces(a)jcp.org on behalf of Lincoln Baxter, III
Sent: Mon 12/14/2009 1:30 PM
To: jsr-314-open(a)jcp.org Subject: Re: [jsf2.next] WITHDRAWN
Proposal to support newse...
I'm not sure I really see the need for special tags like this. What are the
advantages of turning ev...
http://ocpsoft.com <http://ocpsoft.com/>
http://scrumshark.com <http://scrumshark.com/>
Keep it simple. On Dec 14, 2009 1:12 PM, "Dan Allen" <dan.j.allen(a)gmail.com>
wrote: > > JD> ...
15 years
[jsr-314-open] [ADMIN]: Cay Horstmann
by Ed Burns
>>>>> On Mon, 14 Dec 2009 10:55:27 -0500, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> +1
AS> And, yeah, I am hoping to follow up on the other threads just as soon as
AS> I can. This one was a no-brainer though! :-)
Cay, you've been given POST privs. Please confirm you have signed the
JSPA and that JCP.org has your signature on file.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] Fwd: Additional nominations
by Martin Marinschek
Originally, Gary VanMatre was going to represent Apache together with me. I
haven't heard much from him recently, however. Werner Punz has just been
voted in by the MyFaces PMC as another representative (he had write access
to our mailing list before) - and Leonardo Uribe as well as Matthias
Wessendorf should have write access to our mailing list, IMHO.
regards,
Martin
On Mon, Dec 7, 2009 at 11:56 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> Keep the posts coming. I'm updating the list after each message.
>
> -Dan
>
>
> On Mon, Dec 7, 2009 at 5:45 PM, Stephen Kenna <kenna(a)us.ibm.com> wrote:
>
>>
>> I'm representing IBM.
>>
>> Regards,
>> Stephen Kenna
>>
>> *
>> stephen kenna ibm websphere
>> architecture & development*
>> websphere platform jsf, jcdi, & jsp architect
>> *address:* 4205 s miami blvd, durham, nc 27703
>>
>>
>> From:
>> Dan Allen <dan.j.allen(a)gmail.com>
>> To:
>> jsr-314-open(a)jcp.org
>> Date: 12/07/2009 03:56 PM Subject:
>> Re: [jsr-314-open] Additional nominations
>> Sent by:
>> jsr-314-open-bounces(a)jcp.org
>> ------------------------------
>>
>>
>>
>> This all brings up another important matter. It would be really nice
>> if we all knew who is actually on the EG. The jcp.org only maintains a
>> list of individuals and corporate entities. But really, at the end of
>> the day, we need to know who the people are. Down the road we need to
>> get that resolved, but we need a more short term solution.
>>
>> I've taken a stab at identifying the individuals on this page:
>>
>> http://www.javaserverfaces.org/specification
>>
>> But as you can see, there are gaps in my knowledge and I might even
>> have incorrect names there. Feel free to post in response to this
>> thread either identifying yourself if you aren't listed or speak for
>> someone else whom I have overlooked. I have also started a section for
>> the extended EG. It's important to have this transparency.
>>
>> -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
>>
>>
>>
>
>
> --
> 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
>
--
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
15 years
[jsr-314-open] [ADMIN] Target milestones in issuetracker of record
by Ed Burns
DA> On Dec 11, 2009, at 18:20, Dan Allen <dan.j.allen(a)gmail.com> wrote:
DA> Can we get an MR milestone in the issue tracker? Currently there is only
DA> 2.0 and 2.next. But there are issues which need to be filed against the MR
DA> (of course you can call which issues are allowed in there, but I think we
DA> still need the milestone).
DA> On Sat, Dec 12, 2009 at 1:18 AM, <Ed.Burns(a)sun.com> wrote:
EB> Sure, I'll add that next week.
I've added milestones for 2.1 - 2.4. I've deleted 2.next. Instead of
2.next, we should use "unscheduled" as the target milestone if we don't
know the target milestone.
I've deleted the 2.next target milestone field and moved all issues in
it to "unscheduled".
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] [jsf2.next] Proposal to support new semantic HTML5 tags
by Jim Driscoll
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?
15 years
