3:33 p.m.
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-comprehen...
Jim
4:12 p.m.
Hi Jim,
after looking at another component-set, I think you left out a few - I
posted the following list as a comment.
Essential:
* singleRowSelect (radio-button in a table, small thing, but essential)
* subform
* sorting on the table
* some more layouting support (at least colspan/rowspan support )
Nice to have:
* reorder, filter columns on a table
* tree-table
* layouting support: a sophisticated layout manager
* something to remember the current focus of elements on postback,
and the scroll-state (should this be handled in a component?)
* multi component validator (component?)
* range-field (from/to)
* progress bar
* wait page (component?)
regards,
Martin
On 10/14/09, Jim Driscoll <Jim.Driscoll(a)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-comprehen...
Jim
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
11:53 a.m.
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(a)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-comprehen...
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
noon
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(a)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(a)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-comprehen...
>
> 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
12:25 p.m.
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(a)gmail.com
<mailto:dan.j.allen@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(a)sun.com <mailto:Jim.Driscoll@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-comprehen...
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
12:42 p.m.
On Thu, Oct 15, 2009 at 1:25 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
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.
What's funny is that most of us have probably written our own doctype tag
one way or another.
<x:doctype type="xhtml" compliance="strict"/>
-Dan
--
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
12:45 p.m.
Dan Allen wrote:
On Thu, Oct 15, 2009 at 1:25 PM, Andy Schwartz
<andy.schwartz(a)oracle.com <mailto:andy.schwartz@oracle.com>> wrote:
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.
What's funny is that most of us have probably written our own doctype
tag one way or another.
<x:doctype type="xhtml" compliance="strict"/>
FWIW, both Trindiad (tr:document) and ADF Faces (af:document) have a
document component/render that picks the appropriate doc type (in a
render kit-specific manner), rather than have the page author specify
this manually.
Andy
-Dan
--
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
1:03 a.m.
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(a)gmail.com
<mailto:dan.j.allen@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(a)sun.com <mailto:Jim.Driscoll@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-comprehen...
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
3:58 p.m.
Growing market of special devices, such as iPhone, Android or even ebook
readers, makes necessity of special render kits more actual.
I agree that we are going to finally see this idea of multiple render kits
come to
fruition. It didn't happen before because frankly, the mobile
platforms and the availability of smartphones on major networks sucked. With
Android and iPhone going crazy, people's face time with smartphones is
growing to match their time in front of laptops/desktops.
So yeah, it's time.
-Dan
--
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
6:15 a.m.
Hi Dan,
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.
Date, time and color: input, yes, if we find a good way to do this
mostly without javascript, I am not against this.
However, color input is something I have never used in any application
at all, and date and time input are notorically hard to get right in
the browser. Very hard. All the javascript which is out there for
doing this is mostly... very bad.
regards,
Martin
2:18 p.m.
However, color input is something I have never used in any application
at all
I could live without it. Probably more relevant for desktop applications.
, and date and time input are notorically hard to get right in
the browser. Very hard. All the javascript which is out there for
doing this is mostly... very bad.
Surely we could do better than
<h:inputText value="#{bean.date}"><f:convertDateTime
pattern=""/></h:inputText>
Let's find a happy medium.
-Dan
--
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
12:51 a.m.
That extended set of components recall me an idea that had discussed
before JSF 2.0 started: divide JSF API part from components. JSF api
library itself contains about one half of implementation in components
code, that is unusual amid most Java specifications.
I think that the only base functions, like command, input, select should
be defined in API.
On 10/14/2009 01: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-comprehen...
Jim
4 p.m.
We were discussing this offline a bit. I made that point the <f:*> tags and
the major UIComponent types (which Alex already mentioned) may belong in the
core spec and the <h:*> tags, plus any layout sets we add, would belong in
the component spec. Seems reasonable to me. Given how big the JSF spec is,
it might be easier to manage if it was in two (or more) parts.
-Dan
On Fri, Oct 16, 2009 at 1:51 AM, Alaxander Smirnov <asmirnov(a)exadel.com>wrote:
That extended set of components recall me an idea that had discussed
before
JSF 2.0 started: divide JSF API part from components. JSF api library itself
contains about one half of implementation in components code, that is
unusual amid most Java specifications.
I think that the only base functions, like command, input, select should be
defined in API.
On 10/14/2009 01: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-comprehen...
>
> 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
6:11 a.m.
Hi guys,
We were discussing this offline a bit. I made that point the
<f:*> tags and
the major UIComponent types (which Alex already mentioned) may belong in the
core spec and the <h:*> tags, plus any layout sets we add, would belong in
the component spec. Seems reasonable to me. Given how big the JSF spec is,
it might be easier to manage if it was in two (or more) parts.
This would certainly make a lot of sense. And we already reached
conclusion on this list that we should split off the components into a
separate spec. Ed agreed, with the remark that he would want someone
with experience in leading a successful specification effort (I am not
quoting, but this is basically what he said) to be the lead of such a
spec. However, given the current (merger) situation, I am not sure
where we are with regards to new specs being given a chance.
In the meantime, I definitely agree with the discussion on the rest of
this thread: filling the wide gaps is a lot better than defining a lot
of javascript hocus pocus in the specification.
For me, the gaps are:
- file upload (should be easy to do with Servlet 3.0)
- subform (and an interface for forms)
- sortable table (very basic, but very useful for RAD)
- eventually, a basic server side tree (with a sophisticated model
which we all can agree on and a basic rendering we all can do better
within our component libraries)
- a radio-button which works in a table
regards,
Martin
6:23 a.m.
So I am trying to summarize based on the discussion:
- date and time input
- color input
- structured text input (phone number etc.)
- document-tag
- file upload (should be easy to do with Servlet 3.0)
- subform (and an interface for forms)
- sortable table (very basic, but very useful for RAD)
- eventually, a basic server side tree (with a sophisticated model
which we all can agree on and a basic rendering we all can do better
within our component libraries)
- a radio-button which works in a table
- some more layouting support in panelGrid / new layouting components
regards,
Martin
1:01 p.m.
I think iteration components, like dataTable, repeater and tree that all
would be created in the single hierarchy are good place to start.
We already started discussions and development for these components if
RichFaces project and will be glad to contribute them to JSF spec,
especially in cooperation with ADF/Trinidad that already have a similar
classes. I've not took a dip look into other libraries, but suspect that
most of them have a similar solutions.
On 10/18/2009 04:23 AM, Martin Marinschek wrote:
So I am trying to summarize based on the discussion:
- date and time input
- color input
- structured text input (phone number etc.)
- document-tag
- file upload (should be easy to do with Servlet 3.0)
- subform (and an interface for forms)
- sortable table (very basic, but very useful for RAD)
- eventually, a basic server side tree (with a sophisticated model
which we all can agree on and a basic rendering we all can do better
within our component libraries)
- a radio-button which works in a table
- some more layouting support in panelGrid / new layouting components
regards,
Martin
5541
days inactive
5547
days old
jsr-314-open-mirror@lists.jboss.org
15 comments
6 participants
participants (6)
-
Alaxander Smirnov -
Alexander Smirnov
-
Andy Schwartz -
Dan Allen -
Jim Driscoll -
Martin Marinschek