From andy.schwartz at oracle.com Sun Aug 16 04:45:29 2020 Content-Type: multipart/mixed; boundary="===============1122020497243989305==" MIME-Version: 1.0 From: Andy Schwartz To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open] Components Date: Thu, 15 Oct 2009 13:25:50 -0400 Message-ID: <4AD75B1E.7070308@oracle.com> In-Reply-To: 19758da0910151000s111b4c8s7102133b4c87a05d@mail.gmail.com --===============1122020497243989305== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 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 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: > > > > > > > > > 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 and could be an interesting = > trail to follow. > > -Dan > > On Thu, Oct 15, 2009 at 12:53 PM, 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 > > 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-c= omprehensive-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 --===============1122020497243989305==--