[jsr-314-open] Components

Thu Oct 15 13:00:04 EDT 2009

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> 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>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/6a42a4f5/attachment.html 