9:18 a.m.
>>>> 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.
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
9:26 a.m.
New subject: [jsr-314-open] [jsf2.next] Proposal to support newsemantic HTML5tags
On 12/15/09 9:18 AM, Ed Burns wrote:
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 think I agree with Ed here. At first, I thought adding a plethora of
new tags might be a good idea for those case where you might want to
interact with that particular DOM element on the client using various
JSF facilities. I think, though, the concern of an avalanche of tags
might be off-putting, actually feeding into the complaints from some
camps (I'm looking at you, Wicket people :) of tag soup. For those
cases where you do need access to a DOM element, "wrapper" components
(such as the now-and-sadly-defunct Woodstock's webuijsf:markup:
|<webuijsf:markup tag="div" style="color:blue" /)| would probably
suffice. Granted, it doesn't look as intuitive on the page, but in... I
forget how many years of doing JSF, I've rarely needed such a component.
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
10:17 a.m.
New subject: [jsr-314-open] [jsf2.next] Proposal tosupport newsemantic HTML5tags
Well, I did need them in every single project I worked on in the past 4 years and web
designers do use them. Anyway, I guess I'm in minority here so I'll drop the issue
and we'll just create our own taglib internally and for us and our customers and not
the use (or rather continue not using) the h: namespace.
Regards,
~ Simon
________________________________
From: jsr-314-open-bounces(a)jcp.org on behalf of Jason Lee
Sent: Tue 12/15/2009 10:26 AM
To: jsr-314-open(a)jcp.org
Subject: Re: [jsr-314-open] [jsf2.next] Proposal tosupport newsemantic HTML5tags
On 12/15/09 9:18 AM, Ed Burns wrote:
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 think I agree with Ed here. At first, I thought adding a plethora of new tags might be
a good idea for those case where you might want to interact with that particular DOM
element on the client using various JSF facilities. I think, though, the concern of an
avalanche of tags might be off-putting, actually feeding into the complaints from some
camps (I'm looking at you, Wicket people :) of tag soup. For those cases where you do
need access to a DOM element, "wrapper" components (such as the
now-and-sadly-defunct Woodstock's webuijsf:markup: <webuijsf:markup
tag="div" style="color:blue" /) would probably suffice. Granted, it
doesn't look as intuitive on the page, but in... I forget how many years of doing JSF,
I've rarely needed such a component.
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com <http://blogs.steeplesoft.com/>
12:05 a.m.
New subject: [jsr-314-open] [jsf2.next] Proposal tosupport newsemantic HTML5tags
On Tue, Dec 15, 2009 at 11:17 AM, Simon Lessard <Simon_Lessard(a)dmr.ca>wrote:
Well, I did need them in every single project I worked on in the
past 4
years and web designers do use them. Anyway, I guess I'm in minority here so
I'll drop the issue and we'll just create our own taglib internally and for
us and our customers and not the use (or rather continue not using) the h:
namespace.
I don't think it's such a bad idea for a component library (I welcome it to
be open source) to implement every HTML tag. Then, users have an option to
use it, and that's great! I wouldn't want it in the standard HTML tag
library because it is too easily perceived as being a burden and requirement
(we would really catch flack for it then). But there is no reason to hide it
internally. Using a component library certainly doesn't mean you think JSF
is deficient. Really that's the whole idea (I'm probably speaking to the
choir here).
-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
10:30 a.m.
New subject: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
Branching off the HTML5 thread...
Jason Lee wrote:
On 12/15/09 9:18 AM, Ed Burns wrote:
> 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 think I agree with Ed here. At first, I thought adding a plethora
of new tags might be a good idea for those case where you might want
to interact with that particular DOM element on the client using
various JSF facilities. I think, though, the concern of an avalanche
of tags might be off-putting, actually feeding into the complaints
from some camps (I'm looking at you, Wicket people :) of tag soup.
I've been wondering whether the requirement to use <h:head> instead of
plain old <head> (eg. in order to pick up the jsf.js when using
<f:ajax>) might be an annoyance for folks who prefer the .xhtml/template
text approach of view definition. If this is annoying, we could
consider removing this requirement, eg. might be able to transparently
turn HTML <head>/<body> into the corresponding components. However, I
don't have a good feeling for whether this issue is significant... It
is not an issue for my use cases since we tend to stick to higher-level
component abstractions rather than template text, but while we are on
the topic of components vs. template text it seemed like a good time to
raise this question.
Andy
10:43 a.m.
New subject: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
On 12/15/09 10:30 AM, Andy Schwartz wrote:
I've been wondering whether the requirement to use <h:head>
instead of
plain old <head> (eg. in order to pick up the jsf.js when using
<f:ajax>) might be an annoyance for folks who prefer the
.xhtml/template text approach of view definition. If this is
annoying, we could consider removing this requirement, eg. might be
able to transparently turn HTML <head>/<body> into the corresponding
components. However, I don't have a good feeling for whether this
issue is significant... It is not an issue for my use cases since we
tend to stick to higher-level component abstractions rather than
template text, but while we are on the topic of components vs.
template text it seemed like a good time to raise this question.
I've not heard
anyone complain about, but someone like Kito or David who
do a lot of training might have a better feel for the response to that.
In these case, I can see a real value-add, as they make something else
(resource relocation) much easier, so I don't mind them. It seems that
scanning the template for <head> might be an expensive and error-prone
process, but I guess that delves into implementation issues.
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
10:44 a.m.
New subject: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
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 9:18 AM, Ed Burns wrote:
>> 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 think I agree with Ed here. At first, I thought adding a plethora
> of new tags might be a good idea for those case where you might want
> to interact with that particular DOM element on the client using
> various JSF facilities. I think, though, the concern of an avalanche
> of tags might be off-putting, actually feeding into the complaints
> from some camps (I'm looking at you, Wicket people :) of tag soup.
I've been wondering whether the requirement to use <h:head> instead of
plain old <head> (eg. in order to pick up the jsf.js when using
<f:ajax>) might be an annoyance for folks who prefer the
.xhtml/template text approach of view definition. If this is
annoying, we could consider removing this requirement, eg. might be
able to transparently turn HTML <head>/<body> into the corresponding
components. However, I don't have a good feeling for whether this
issue is significant... It is not an issue for my use cases since we
tend to stick to higher-level component abstractions rather than
template text, but while we are on the topic of components vs.
template text it seemed like a good time to raise this question.
Andy
5489
days inactive
5490
days old
jsr-314-open-mirror@lists.jboss.org
6 comments
6 participants
participants (6)
-
Andy Schwartz -
Dan Allen -
Ed Burns -
Jason Lee -
Roger Kitain -
Simon Lessard