Hi all,
don't know if this mail made it to the list - but I guess Matthias
would want the EG to see it. Andy already answered with a hint towards
our discussion playground, which still doesn't really work AFAIK....
regards,
Martin
---------- Forwarded message ----------
From: Matthias Wessendorf <matthias.wessendorf(a)oracle.com>
Date: Thu, 15 Oct 2009 10:15:03 -0700
Subject: Re: [jsr-314-open] Components
To: jsr-314-open(a)jcp.org, dan.j.allen(a)gmail.com,
mmarinschek(a)apache.org, Jim.Driscoll(a)sun.com, Andy
<andy.schwartz(a)oracle.com>
I like the way that the jsr-314-open(a)jcp.org list is not open.......
so I am hijacking it .... sorry.
What I wanted to "add" is the following sentence:
I am agreeing with Dan on NOT adding all these extra components (incl.
the list from Jim's blog)!
inputDate, inputFile, maybe subform and also some sort of h:document
(internally using h:head/body)
would be what I'd like to see. But not adding a bunch of rich components
etc. That would add WAY to much
overhead to the spec.... Just my cent.
Oh, as I am frustrated about the openness, maybe one more comment...
Can't you guys just rename the "jsr-314-open(a)jcp.org" to be
"semi-open",
or to "no-comment-allowed-but-open-to-read" ?
Man, this is really frustrating...
Thanks!
Matthias
Dan Allen wrote:
When Andy and I spoke last week, we seemed to be in agreement about
the goal of this expanded set of components, which I will restate here.
To recap, the existing components set--specifically the form
elements--are roughly a 1-to-1 mapping with HTML. But by no means is
HTML a comprehensive set of core components. The way I see it is if
you were to take ~100 applications (web, Oracle Forms, mobile, paper,
etc) and try to find the components that show up a majority of the
time, excluding "rich" components like trees and menus, that should be
your core set of components. The reason I exclude the rich components
is because they have way too many configuration options to have a good
standard...they end up getting replaced anyway (feel free to argue
otherwise). The standard set should be expanded primarily in the area
of form inputs. But I can also see the defense for better table
support since it is of equal importance in web apps.
A perfect example of a missing component is a date input. Dates are
universal. You can guarantee that you are going to need one somewhere
in your app. Yet, it is missing from the core component set. You have
to take the lame and insufficient approach of using a converter with
an h:inputText. Of course, you will eventually want to style or even
replace the date input with some fancy version from ADF Faces,
RichFaces or ICEFaces. But the point is, you can at least get the
application going with the core component set. Thje developer is
hooked at that point.
Just to give you a feel for other types of components that might be
warranted, pick up an Android device or iPhone and flip through a
couple of apps. You'll notice some core components that you just
expect to be there but don't map with our "traditional" view of
inputs, painted in our minds by HTML. Inputs like phone number, date,
time, color, file upload. So let's work to cover the "lame if absent"
cases and then we can debate the cases that are on the fence.
-Dan
On Wed, Oct 14, 2009 at 4:33 PM, Jim Driscoll <Jim.Driscoll(a)sun.com
<mailto:Jim.Driscoll@sun.com>> wrote:
Andy had mentioned that there was interest in adding a few
components for JSF 2.next. And our audience mentioned that as well.
I thought it would be an interesting exercise to try to gather up
a list of what kinds of components already existed as either
existing JSF or JavaScript widgets, and I went a little overboard
- but hopefully you'll find it useful as something to stimulate
thought on the topic.
http://weblogs.java.net/blog/driscoll/archive/2009/10/14/almost-comprehen...
Jim
--
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