[jsr-314-open] Components

Thu Oct 15 13:25:50 EDT 2009

Dan -

Thanks for summarizing the thoughts below - it captures my thinking as 
well.  I am not especially interested in spec'ing a full blown rich 
component set, but I do think we have work to do to fill out some of the 
more gaping holes in the standard components.

Regarding a document component - yep, I would like to see this 
considered since the type of content (eg. HTML vs. XHTML) and the choice 
of dtd may vary by render kit, yet we do not have an abstraction that 
covers this today.  I think that this could live in the h:namespace as 
it is a slightly higher level abstraction for the <html> element.

Andy

Dan Allen wrote:
> Oh, and I almost forgot. We definitely need to abstract the idea of a 
> document so that we can get away from the <html> tag in the main 
> template. Presumably the document tag would fall into a new namespace 
> set that deals with structure (rather than HTML specifically).
>
> Roughly:
>
> <s:document>
>    <s:head>
>    </s:head>
>    <s:body>
>    </s:body>
> </s:document>
>
> I didn't put a ton of thought into that. I know Andy has gone deeper. 
> Toss.
>
> As for Martin's point about layout, again, looking at what Android has 
> done with <LinearLayout> and <RelativeLayout> could be an interesting 
> trail to follow.
>
> -Dan
>
> On Thu, Oct 15, 2009 at 12:53 PM, Dan Allen <dan.j.allen at gmail.com 
> <mailto:dan.j.allen at gmail.com>> 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
>
>
>
>
> -- 
> 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