2:26 p.m.
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> ...
8:52 p.m.
New subject: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to support newsemantic HTML5 tags
While I see the benefit of components that will provide semantical/
structural information about the view, I don't think we need every
HTML(5)-tag as a component but rather tags, that are able to represent
the structure of a document in a more abstract way. Also I don't think
renderkit authors would be thrilled to see that many new standard
components they would have to support in case we add every possible
HTML-tag. (But we could probably ask both ;) )
As I don't think we will be able to come up with a tagsoup that will
cover 80% of the needs of users and renderkit developers, a possible
way to give for example early adaptors of HTML5 a simple solution,
would be to make composite-component libraries "renderkit(mode)" aware
and a simple way to declare/match these modes. So a compcomp author
could provide two (or more) libraries with implementations of
<my:nav>, which will translate depending of the user-agent/outputtype
to either <nav>, <ul class="nav"> , <pdf:toc>, ... effectively
creating different view files for different presentations, agreeing on
the coupling of presentation and view files with Lincoln.
Imre Oßwald
On 14.12.2009, at 21:26, Lincoln Baxter, III wrote:
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> ...
>
9 a.m.
New subject: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to supportnewsemantic HTML5 tags
IO > (But we could probably ask both ;) )
For MyFaces it would be pretty easy as we use a Maven plugin to generate most of the
artifacts and all those new Renderer would be incredibly similar and small. As for other
renderkit kits for the h:* out there, they could simply associate them with a
BlockRenderer and InlineRenderer in their faces-config's render kit declaration until
they decide to make them more evolved.
IO > make composite-component libraries "renderkit(mode)" aware
I don't get what's the effective difference between that suggestion and making the
default render kit agent aware instead and/or provide 2 render kits and make a better use
of the calculateRenderKitId method. I don't think we're giving enough thought and
putting enough effort in "pluggable render kit" idea. Such strategy could
probably be used as well to handle JavaScript degradation more seamlessy and elegantly as
well. If we standardize the agent awareness mechanism and find a way to know its effective
capabilities (that last one is harder, especially for sciprt support though... the script
would most likely have to send a secodn request on the server to notify it that script are
indeed suppotred on the client). Anyway, even if the specification itself makes no use of
that information(for now) , more advanced frameworks could exploit it and switch between
rich/standard, HTML 4.01/5 and do what you can (IE)/do anything (all others) modes.
Briefly, I don't think the specification itself should abuse of the composite
component, those should be mostly for the end users to ease the component creation, I
don't really think the specification implementors nor library vendors require that
reduced complexity that come with a small performance overhaul.
Regards,
~ Simon
________________________________
From: jsr-314-open-bounces(a)jcp.org on behalf of Imre Osswald
Sent: Mon 12/14/2009 9:52 PM
To: jsr-314-open(a)jcp.org
Subject: Re: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to supportnewsemantic HTML5
tags
While I see the benefit of components that will provide semantical/
structural information about the view, I don't think we need every
HTML(5)-tag as a component but rather tags, that are able to represent
the structure of a document in a more abstract way. Also I don't think
renderkit authors would be thrilled to see that many new standard
components they would have to support in case we add every possible
HTML-tag. (But we could probably ask both ;) )
As I don't think we will be able to come up with a tagsoup that will
cover 80% of the needs of users and renderkit developers, a possible
way to give for example early adaptors of HTML5 a simple solution,
would be to make composite-component libraries "renderkit(mode)" aware
and a simple way to declare/match these modes. So a compcomp author
could provide two (or more) libraries with implementations of
<my:nav>, which will translate depending of the user-agent/outputtype
to either <nav>, <ul class="nav"> , <pdf:toc>, ... effectively
creating different view files for different presentations, agreeing on
the coupling of presentation and view files with Lincoln.
Imre Oßwald
On 14.12.2009, at 21:26, Lincoln Baxter, III wrote:
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://ocpsoft.com/>
http://scrumshark.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://ocpsoft.com/>
> http://scrumshark.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> ...
>
9:34 a.m.
New subject: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to support newsemantic HTML5 tags
Imre Osswald wrote:
While I see the benefit of components that will provide
semantical/structural information about the view, I don't think we
need every HTML(5)-tag as a component but rather tags, that are able
to represent the structure of a document in a more abstract way. Also
I don't think renderkit authors would be thrilled to see that many new
standard components they would have to support in case we add every
possible HTML-tag. (But we could probably ask both ;) )
As I don't think we will be able to come up with a tagsoup that will
cover 80% of the needs of users and renderkit developers, a possible
way to give for example early adaptors of HTML5 a simple solution,
would be to make composite-component libraries "renderkit(mode)" aware
and a simple way to declare/match these modes. So a compcomp author
could provide two (or more) libraries with implementations of
<my:nav>, which will translate depending of the user-agent/outputtype
to either <nav>, <ul class="nav"> , <pdf:toc>, ...
effectively
creating different view files for different presentations, agreeing on
the coupling of presentation and view files with Lincoln.
If we had to choose I would prefer to stay away from creating new
components for this use case.
Ed Burns wrote:
>>>>> On Mon, 14 Dec 2009 13:48:18 -0500, Simon Lessard
<Simon_Lessard(a)dmr.ca> said:
>>>>>
SL> We might have agree to disagree, the "name of the tag created" does
SL> make the whole difference imho, it's not just about how it look.
Though I'm delighted to see all the traffic on this topic, I have to
weigh in and oppose adding many more tags. The design focus of JSF
views has always been to mix template text and components. In my
opinion, this is widely seen as a strength for server-side UI
technologies such as JSF.
I do remember in the JSF 1.0 development days some EG members thought
the direction should be to use JSF tags/components in the view (only).
But times ahve certainly changed, and I do agree that template text and
components is a very nice combination.
-roger
5491
days inactive
5492
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Imre Osswald -
Lincoln Baxter, III -
Roger Kitain -
Simon Lessard