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 <[EMAIL PROTECTED]> wrote:
Sigh... every once and a while I send stuff to myfaces dev instead of here. ---------- Forwarded message ---------- From: Sean Schofield <[EMAIL PROTECTED]> Date: Aug 24, 2006 10:40 AM Subject: [dialog] Basic button functionality To: MyFaces Development <[email protected]> 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
