On 12/22/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 12/22/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > >From: David Geary <[EMAIL PROTECTED]> > > > This is from a blog entry about my Shale presentation at Javapolis at > > > http://blog.dannynet.net/: > > > <snip/> > > > Off the top of my head, I don't see why we couldn't define dialog > > > structure > > > with filesystem conventions and flow with custom tags in JSP pages. <snap/>
C/C is good, atleast RoR has been fun to play with. If anyone comes up with a C/C scheme for the Shale dialog manager, I'm sure it'll be useful. Having said that, for me, which of the C's would take precedence tends to vary by the nature of the undertaking, depending on factors such as size of "dialogs" and number of channels. > > > > I think that this approach would limit your reuse. Part of the benefit of > > the dialog is that you can reuse views and wire them together in different > > workflows and add processing logic between the navigation of the pages. If > > you hard wire a jsp to a specific dialog using some kind of annotation, you > > would loose the ability to reuse this view in another process flow. > > > +1. The suggested approach would also necessitate getting the page author > involved in flow related coding, instead of just the application architect. > The current scheme requres zero code in a JSP page. > <snip/> And that becomes quite important, for say, multi-channel applications, where page author skills are channel specific, but the app architect gets to stay channel agnostic (otherwise those flows might have redundantly surfaced across all channels/modalities). > I think that another benefit of defining the dialog in one place is that you > > can visualize the overall flow. If this metadata was disbursed into various > > view fragments, it would be hard to validate and hard to justify the need of > > a dialog manager. > > > You need not limit yourself to visualizing ... constructing a page flow > graphically with a tool also becomes very easy. (Creator currently does a > simplified version of this for standard JSF navigation -- and many folks > start on the Page Navigation editor and flesh out all their navigation, > before they ever start coding individual pages). > <snap/> Ah, that modeling thing? ;-) I'm sure hand-authoring is a sign of competence, but pictures, anyone? Like this rendition of the Shale log-on dialog: http://jakarta.apache.org/commons/sandbox/scxml/usecases/shale-dialogs/log-on-dialog.jpg Or stepping back at looking at the development cycle, so the middleware XML configurations appear to be *mere* outputs from the modeling layer (see page 2 of PDF): http://people.apache.org/~rahul/CommonsSCXML.pdf What has that PDF got to do with the topic on hand? For that, we tilt our heads a little until: http://jakarta.apache.org/commons/sandbox/scxml/usecases/scxml-in-shale-dialogs.html More on that will come. -Rahul > > > > > david > > > > Gary > > > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
