8:52 p.m.
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> ...
>