Re: [dialog] Basic button functionality
Doh. Wrong list again. On 8/24/06, Sean Schofield [EMAIL PROTECTED] 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
Wrong list, sure, but since you opened up the can of worms...Is Shale really planning on getting into the HTML-renderingbusiness?-- AdamOn 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: Doh.Wrong list again.On 8/24/06, Sean Schofield [EMAIL PROTECTED] 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
From: "Adam Winer" [EMAIL PROTECTED] Wrong list, sure, but since you opened up the can of worms...Is Shale really planning on getting into the HTML-renderingbusiness? What do you mean by "HTML-rendering business"? We have custom components that do rendering. Clay has been around better than a year now and provides rich view composition using various templating options. Clay is a component in of itself that simple builds a subtree of components using a mechanism other than JSP tags. The clay component renders it children. When using full html (tapestry like) views or full xml (tiles like)views, the clay component is the only child under the view root so it pretty much renderers the full page. -- Adam Gary
Re: [dialog] Basic button functionality
On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: No I'm not proposing we deal with generating HTML rendering businessas far as dialogs are concerned.[I'll post a more detailedexplanation on the shale dev list where that belongs.]@Adam: If you're not already subscribed to shale dev we'd love to have you over there.Specifically, we could benefit from your insightregarding dialogs.I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Craig@Everyone Else: This goes for you too.If you're using JSF you'll want to check out Shale which just builds on JSF and provides a lot ofcool stuff missing from the spec.SeanOn 8/24/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Adam Winer [EMAIL PROTECTED] Wrong list, sure, but since you opened up the can of worms... Is Shale really planning on getting into the HTML-rendering business? What do you mean by HTML-rendering business? We have custom components that do rendering.Clay has been around better than a year now and provides rich view composition using various templating options.Clay is a component in of itself that simple builds a subtree of components using a mechanism other than JSP tags.The clay component renders it children.When using full html (tapestry like) views or full xml (tiles like) views, the clay component is the only child under the view root so it pretty much renderers the full page. -- Adam Gary
Re: [dialog] Basic button functionality
I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That's how I took his meaning and I totally agree with both of you. That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Exactly what I'm suggesting (see my comments on the shale-dev list.) Craig Sean
Re: [dialog] Basic button functionality
This is especially important as coping with all different button, link and form components is a nightmare already. Adding additional components can only be adding to the problem here. The combination of ADF-Faces, Tomahawk and the RI is (as of today) impossible, e.g, if we don't cope for the special behaviour specific to one framework somehow. regards, Martin On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That's how I took his meaning and I totally agree with both of you. That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Exactly what I'm suggesting (see my comments on the shale-dev list.) Craig Sean -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Re: [dialog] Basic button functionality
On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That's how I took his meaning and I totally agree with both of you. That was exactly my meaning. Frameworks like Clay that compose *other* renderers are great, and no problem. -- Adam That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Exactly what I'm suggesting (see my comments on the shale-dev list.) Craig Sean
