You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/08/24 16:40:26 UTC
[dialog] Basic button functionality
I think it would be highly desirable to provide some sort of basic
button functionality ("previous, next, ok and cancel"). I'm not
saying we render buttons on the dialog for the user, but I am saying
that most dialogs have certain things in common that we should just
incorporate into the basic functionality. JSF can already give you
most of what you need for dialogs without using Shale - lets try and
enhance things in a way that would make it worthwhile for our users.
On my last job I used dialogs extensively, but as I think about it,
the most important functionality was added on top of what was
provided. We had several dialogs that involved a series of steps.
Some of the steps were common between multiple dialogs but we also had
cases where the user could later revisit just a single step.
So in some cases the "foo screen" needed a next button (when used in
the multi step dialogs) but in other cases you just want an "ok" and
"cancel" button (as in the single step dialog case.) The existing
dialog functionality was helpful because I could easily examine the
transitions but it took a long time to work out some of the more
complicated details.
I was going to try and sketch out some ideas here in the email but I
changed my mind. I'm going to put some very rough code into the
sandbox. Instead of using the sandbox for a staging area for near
complete code, we could use it to sketch out some rough ideas. Why
not?
Craig and I both agree it would be nice to have this wrapped up in a
few weeks so we can release before Apache Con. David would probably
also like to make sure his book isn't out of date so we'll have to
move very quickly on this.
Sean
Re: [dialog] Basic button functionality
Posted by Adam Winer <aw...@gmail.com>.
Wrong list, sure, but since you opened up the can of worms...
Is Shale really planning on getting into the HTML-rendering
business?
-- Adam
On 8/24/06, Sean Schofield <se...@gmail.com> wrote:
>
> Doh. Wrong list again.
>
> On 8/24/06, Sean Schofield <se...@gmail.com> wrote:
> > I think it would be highly desirable to provide some sort of basic
> > button functionality ("previous, next, ok and cancel"). I'm not
> > saying we render buttons on the dialog for the user, but I am saying
> > that most dialogs have certain things in common that we should just
> > incorporate into the basic functionality. JSF can already give you
> > most of what you need for dialogs without using Shale - lets try and
> > enhance things in a way that would make it worthwhile for our users.
> >
> > On my last job I used dialogs extensively, but as I think about it,
> > the most important functionality was added on top of what was
> > provided. We had several dialogs that involved a series of steps.
> > Some of the steps were common between multiple dialogs but we also had
> > cases where the user could later revisit just a single step.
> >
> > So in some cases the "foo screen" needed a next button (when used in
> > the multi step dialogs) but in other cases you just want an "ok" and
> > "cancel" button (as in the single step dialog case.) The existing
> > dialog functionality was helpful because I could easily examine the
> > transitions but it took a long time to work out some of the more
> > complicated details.
> >
> > I was going to try and sketch out some ideas here in the email but I
> > changed my mind. I'm going to put some very rough code into the
> > sandbox. Instead of using the sandbox for a staging area for near
> > complete code, we could use it to sketch out some rough ideas. Why
> > not?
> >
> > Craig and I both agree it would be nice to have this wrapped up in a
> > few weeks so we can release before Apache Con. David would probably
> > also like to make sure his book isn't out of date so we'll have to
> > move very quickly on this.
> >
> > Sean
> >
>
Re: [dialog] Basic button functionality
Posted by Sean Schofield <se...@gmail.com>.
Doh. Wrong list again.
On 8/24/06, Sean Schofield <se...@gmail.com> wrote:
> I think it would be highly desirable to provide some sort of basic
> button functionality ("previous, next, ok and cancel"). I'm not
> saying we render buttons on the dialog for the user, but I am saying
> that most dialogs have certain things in common that we should just
> incorporate into the basic functionality. JSF can already give you
> most of what you need for dialogs without using Shale - lets try and
> enhance things in a way that would make it worthwhile for our users.
>
> On my last job I used dialogs extensively, but as I think about it,
> the most important functionality was added on top of what was
> provided. We had several dialogs that involved a series of steps.
> Some of the steps were common between multiple dialogs but we also had
> cases where the user could later revisit just a single step.
>
> So in some cases the "foo screen" needed a next button (when used in
> the multi step dialogs) but in other cases you just want an "ok" and
> "cancel" button (as in the single step dialog case.) The existing
> dialog functionality was helpful because I could easily examine the
> transitions but it took a long time to work out some of the more
> complicated details.
>
> I was going to try and sketch out some ideas here in the email but I
> changed my mind. I'm going to put some very rough code into the
> sandbox. Instead of using the sandbox for a staging area for near
> complete code, we could use it to sketch out some rough ideas. Why
> not?
>
> Craig and I both agree it would be nice to have this wrapped up in a
> few weeks so we can release before Apache Con. David would probably
> also like to make sure his book isn't out of date so we'll have to
> move very quickly on this.
>
> Sean
>
Re: [dialog] Basic button functionality
Posted by Sean Schofield <se...@gmail.com>.
Here is some more explanation about the button idea. I'm still
working on a few pieces of code to show what it would look like.
Since Adam asked on myfaces-dev about whether we're talking HTML
generation I thought I would explain further ...
What I'm proposing is a mechansim that assumes certain standard
features such as prev and next buttons. I'm making the assertion that
many (if not most) dialogs have some combination of prev, next, ok
and cancel buttons. Given this assumption, can we provide some kind
of mechanism that will help us to intelligently navigate the sea of
dialogs?
I'm thinking the user provides their own HTML template for dialogs.
It contains all of the buttons that you might typically find (prev,
next, etc.) What would be helpful is if the *rendered* attribute
could plug into the dialog mechanism so we can determine which buttons
to display.
Let me describe what things looks like now without this type of
solution. Youve got these pages for dialogs, and they handle all of
the pretty HTML and layout. The data comes from beans, navigation is
handled by JSF and all is right with the world. Now you need to reuse
one of these pages in another dialog. Shale dialog (as it stands now)
provides you the navigation to say that when the user clicks next go
to such and such a step. Each dialog can be configured to have its
own rules for what to do on "next."
The question is, how does the user signal their intention to go to the
next step? Well you could have a next button, but what one of your
dialogs is a single step dialog? You don't want a "next" button in
this case, you just want an "ok" button. The view doesn't know
anything about dialogs or what sequence the pages will be displayed
in.
To me, its much easier to say we need this "foo screen" and develop
it. Then you plug it into dialogs wherever you need it. Without
having the abillity to make rendering decisions based on the presence
of certain transitions you are stuck hard coding two views for the
same page - one with a next button and one without. Of course you
could use tiles, facelets, clay or whatever to minimize duplicating
your HTML but you still end up with tightly coupling a dialog vie with
a specific flow.
Sean
On 8/24/06, Sean Schofield <se...@gmail.com> wrote:
> Sigh... every once and a while I send stuff to myfaces dev instead of here.
>
> ---------- Forwarded message ----------
> From: Sean Schofield <se...@gmail.com>
> Date: Aug 24, 2006 10:40 AM
> Subject: [dialog] Basic button functionality
> To: MyFaces Development <de...@myfaces.apache.org>
>
>
> I think it would be highly desirable to provide some sort of basic
> button functionality ("previous, next, ok and cancel"). I'm not
> saying we render buttons on the dialog for the user, but I am saying
> that most dialogs have certain things in common that we should just
> incorporate into the basic functionality. JSF can already give you
> most of what you need for dialogs without using Shale - lets try and
> enhance things in a way that would make it worthwhile for our users.
>
> On my last job I used dialogs extensively, but as I think about it,
> the most important functionality was added on top of what was
> provided. We had several dialogs that involved a series of steps.
> Some of the steps were common between multiple dialogs but we also had
> cases where the user could later revisit just a single step.
>
> So in some cases the "foo screen" needed a next button (when used in
> the multi step dialogs) but in other cases you just want an "ok" and
> "cancel" button (as in the single step dialog case.) The existing
> dialog functionality was helpful because I could easily examine the
> transitions but it took a long time to work out some of the more
> complicated details.
>
> I was going to try and sketch out some ideas here in the email but I
> changed my mind. I'm going to put some very rough code into the
> sandbox. Instead of using the sandbox for a staging area for near
> complete code, we could use it to sketch out some rough ideas. Why
> not?
>
> Craig and I both agree it would be nice to have this wrapped up in a
> few weeks so we can release before Apache Con. David would probably
> also like to make sure his book isn't out of date so we'll have to
> move very quickly on this.
>
> Sean
>
Fwd: [dialog] Basic button functionality
Posted by Sean Schofield <se...@gmail.com>.
Sigh... every once and a while I send stuff to myfaces dev instead of here.
---------- Forwarded message ----------
From: Sean Schofield <se...@gmail.com>
Date: Aug 24, 2006 10:40 AM
Subject: [dialog] Basic button functionality
To: MyFaces Development <de...@myfaces.apache.org>
I think it would be highly desirable to provide some sort of basic
button functionality ("previous, next, ok and cancel"). I'm not
saying we render buttons on the dialog for the user, but I am saying
that most dialogs have certain things in common that we should just
incorporate into the basic functionality. JSF can already give you
most of what you need for dialogs without using Shale - lets try and
enhance things in a way that would make it worthwhile for our users.
On my last job I used dialogs extensively, but as I think about it,
the most important functionality was added on top of what was
provided. We had several dialogs that involved a series of steps.
Some of the steps were common between multiple dialogs but we also had
cases where the user could later revisit just a single step.
So in some cases the "foo screen" needed a next button (when used in
the multi step dialogs) but in other cases you just want an "ok" and
"cancel" button (as in the single step dialog case.) The existing
dialog functionality was helpful because I could easily examine the
transitions but it took a long time to work out some of the more
complicated details.
I was going to try and sketch out some ideas here in the email but I
changed my mind. I'm going to put some very rough code into the
sandbox. Instead of using the sandbox for a staging area for near
complete code, we could use it to sketch out some rough ideas. Why
not?
Craig and I both agree it would be nice to have this wrapped up in a
few weeks so we can release before Apache Con. David would probably
also like to make sure his book isn't out of date so we'll have to
move very quickly on this.
Sean