Hi Chris, sorry for being so quiet during the last days. But finally I'd like to anwser your questions and point out a few comments to your thoughts.
Chris Finn wrote: > > Wow, this is impressive stuff, Daniela. As others > have mentioned, we too are interested and have done > some design work in this area. Rather than try to > match your eloquent description, I'll provide a > differential comparison, offer some ideas and and ask > a few questions. yepp, that's fine. Interesting issues indeed. > First, can you clarify a couple of issues for me? Sure, at least I'm trying to. :) > > Each transition is described by a unique name, a > > target state and the parameters that are > > required for this transition. These parameters are > > NOT necessary for the > > flow control itself, but they are for form handling > > and automatic generation of flow navigation > > elements. They result either from filling > > form fields or represent environmental data provided > > by the data generation classes. > > 1) Can you clarify "environmental data"? Is that > "data stored in the Session" or "data embedded in the > generated XML", or is it other data? It is data embedded in the generated XML. Where the origin of this embedded data lies, is open. It might stem from any kind of data store or reside in the session. > 2) Is it possible to have multiple actions take place > during the processing of a state? Good question. First, I was tempted to answer with "yes", because I was so used to the current action model of the sitemap, but the longer I think on this, the more I'm convinced that "no" might be the more approriate answer. I think it might result in a much clearer model if we assume that each hidden state is bound to exacly one action. If you need a second action to be executed, this should be done in a seperate state. But I'm not yet sure on this point. > 3) Is it possible (or have you found a need yet) to > support other types of return values from the Actions > in a state besides the "event" one? Hmm, no, we haven't found a need yet (have you?) and I'm not sure if there is one. The usual way to handle this is to store this kind of data somewhere else (e.g. in the session) and to retrieve it from this place when generating the page. But you can convince me otherwise. > 4) In our model, we are considering a > "select/when/otherwise" syntax for handling > conditional logic; however, I like the terseness of > your <if> logic. An open question is: what's the > minimum set of control structures we can get by with? Well, our model contains kind of an implicit "otherwise". If no event parameter matches, the requested page itself is generated. I don't know what syntax is more appropriate in the end, maybe it's just a matter of personal taste. > [...] > > 1) Multiple-flow applications. Although I personally > don't like sites that make use of these techniques > (because most of them do it poorly), handling things > like pop-up browser windows (window.open() in > Javascript) and framesets can cause headaches in > representing a linear application flow. The only way > I see around this is to embed "next-state" information > in the generated pages themselves--meaning that the > FlowHandler can't expect to maintain any state > information itself. Put another way, the "adornment" > of a produced page with the transitions (or links) has > to provide a pre-computed "next-state" recipe that the > FlowHandler can understand. Is that what you're > proposing? If so, we've reached that conclusion > independently. Correct. The FlowHandler doesn't hold the state information. The produced page itself contains links that point to a state and carry event parameters that are translated into transitions leading to subsequent states. I guess that's pretty much the same as you're talking about. > 2) Some transitions make sense to be driven by the > client. Consider a portal window with a smart > Javascript control that wants to use DHTML tricks to > update a stock ticker. The simplistic option would be > to do a complete refresh of the page with a page-flip. > A smart model would permit just the XML data that > needed to be interpretted (or perhaps, just the DHTML > that needed to be inserted in the page) to cut down > the flickering and large round trip. However, this is > a form of "subtransition" that you might like to > represent in a formal way. [We call these > subtransactions--the poor man's implementation is just > a refresh with different parameters in the URL.] I'd > like to think you could still represent this as part > of the flow (because it involves server requests). As > apps become more interactive, I think this needs to be > accounted for. Hmm, I think I'll have to digest this a little more and I'm not completely sure if I really got it. Maybe you could elaborate a little more? > 3) Flow adjustment based on conditional information. > Consider a site where after login, you must pass > through a click-through agreement. Furthermore, > assume that this click-through agreement may change > from time to time, and the knowledge of whether to > display this is controlled by a database setting. It > appears that your model handles this case well, as > long as the "insertion point" of this branch is known > beforehand. I don't think that it is a restriction that you have to know the insertion point. You meet this need when you define your flow quite naturally. Conditional branching itself is easy to handle with hidden states and conditional evaluation of the returned event parameter. Maybe you'd like to argue that for this case there's the need to have more than just the event parameter returned by a hidden state, e.g. maybe you're getting the URL for the subsequent page back from your database. But maybe it just isn't a good idea to want to do that. :) > 4) Reusable subflows. Okay, this is where I think > some problems could arise. Imagine an application > where you want to have a "reusable subflow"--a > sequence of screens which can be invoked from anywhere > in an application (or in a number of applications yet > to be written). This can be initiated from different > "Cocoon applications" (or subsites) or from a lot of > different pages. Rather than account for links to > these subflows everywhere, we need a way to make them > independent and reusable. Your latest email addressed > some of these reusabilit yissues--I'll discuss one Yeah, that could be tricky. I think you can handle subflows in a very simple way by just plugging them kind of "into" a state of the main flow. But I haven't been thinking about this point in too much detail yet. > idea below that is our way around it. Related to this > are common menus that appear on lots of pages--it'd be > nice to make these reusable in a clean way. Hm, are you talking about common menus just as a group of hyperlinks that you want to place on a number of pages? Or are these really links to pages that are part of a flow (carrying event parameters and so on)? I think it's important to distinguish between these two navigation types, and you might want to use a different menu generating mechanism for the both. > 5) Back button problems. Although I can't tell for > sure, it appears that the model you're describing > stores no state in the FlowHandler, so issues with the > back button might not arise in any of your proposed > use of this. If you're trying to maintain some state > or a stack of nested subflows, the back button can > mess up the attempts to retain any state. Yepp, right. > 6) Scalability: take a look at a site like Excite, > with approximately 100 or so transitions off the > initial page. Many of these links represent "reusable > subflows" that appear on other pages. The thought of > mapping the flow of an application like Excite is > daunting; I would argue that there has to be a way to > distribute some of the logic of transitions to the > page definition. Below, I describe one idea that > addresses it (but one which might make you cringe.) Hm, there it is again. If these transitions are just ordinary static "hyperlinks" to other pages and not part of a flow, I think, a different menu generation mechanism might be appropriate (like some kind of NavigationMenu Generator retrieving the menu structure from somewhere else - maybe similar to that dictionary you're talking about later in your mail). > [...] > > On "transition adornment": we believe that in the > generation step (either as part of the generation, or > as an action associated with generation), a standard > XML-blob of pre-built transition URLs should be > provided. Our presentation XSLs will know to look for > these and associate them properly (e.g., some may be > associated with specific content blobs, others, like > menus, may be associated with the page "globally"). > This adornment means that the presentation-developer > needs only stick the links in the right place and can > by and large bail out of screenflow concerns. I > hadn't thought of a transformer approach--to me, it > seems much more like an action that will provide some > aggregatable content. Well, I agree - partly. :) For most of the links, a generator is fine, but how do you determine to which part of the underlying XML data the link belongs? Maybe this doesn't apply to your application, because all links belong to some top level page element. But with a transformer you can insert the hyperlinks at the exact XML element where they belong to, even somewhere deeply nested in your data structure. By this, the XSL transformation becomes more efficient because link elements are located next to the data elements they belong to. > Why did we do this? Think of the excite page with 100 > links on it...it seemed just too complex to imagine a > single map describing the screenflow of a site like > Excite...and scaling that up to 10 or 20 similar > applications wanting to reuse states/transitions. By > distributing some of the transition information into > these XSP page descriptors, we can let people easily > glance at a page and know what it is trying to > accomplish, but defer what it actually *does* to the > definitions in the common dictionary. I see your point, you simply can't handle that kind of large-scale application by hand. Thanks a lot for your remarks, Dani --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
