[jsr-314-open] Fwd: Components

[Martin Marinschek]

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 at oracle.com>
Date: Thu, 15 Oct 2009 10:15:03 -0700
Subject: Re: [jsr-314-open] Components
To: jsr-314-open at jcp.org, dan.j.allen at gmail.com,
mmarinschek at apache.org, Jim.Driscoll at sun.com, Andy
<andy.schwartz at oracle.com>

I like the way that the jsr-314-open at 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 at 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 at sun.com
> <mailto:Jim.Driscoll at 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-comprehensive-list-components
>
>     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