[jsr-314-open] Components

Fri Oct 16 02:03:16 EDT 2009

I prefer to not only define page abstraction but go further from 
html-oriented component set to functional one, that should include 
layouts, layout managers and controls that would give a life to original 
pluggable renderkit idea. We have already done one step in that 
direction with behaviors that use user interface events abstractions.
For example, richfaces 'page' component does not define head/body but 
operates with logical parts such as 'header' 'footer' 'sidebar'. How 
these parts are rendered is up to current renderer or 'theme'.

Growing market of special devices, such as iPhone, Android or even ebook 
readers, makes necessity of special render kits more actual.

On 10/15/2009 10:00 AM, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091015/b0a00dac/attachment.html 