Hi everyone, It was great seeing you all in Ghent!!!! :)
See comments below.. On Sat, 16 Nov 2002, Sylvain Wallez wrote: > > My feeling (I won't say "opinion" since I don't master all the details) > is that the flow is becoming a first-class Cocoon citizen : it not only > calls business logic and sends pages depending on the logic result, but > it's also giving information to build these pages, and it also appears > that we want to master it's relationship with sitemap mounting, and > later blocks. > > So we need a kind of "flow-values" object (don't know if it's the > interpreter or something else) that would be available to components > invoked to display the page, be it routing components like matchers and > selectors or sitemap components like generators and transformers. I agree that flow should be considered a "first class Cocoon citezen" but I have some reservations about global flow variables being available to sitemap routing components. Flow is designed to simplify the sitemap by reducing the amount of routing components required and by moving business logic out of the sitemap. Having global flow script variables available to routing components might encouarage users to move the flow/routing control back into the sitemap. Perhaps this is a "best practice" issue, that we dont have to enforce? Ideally, with business logic moved to the flow controller, one would only need to use selectors after a generator has been set. > > First, storing it in the session doesn't seem to be a good idea to me, > as flow values are request specific. We have however two ways of storing > it : > - as a request attribute > - as a new entry in the object model. > > As I said above, the flow is becoming a first-class citizen, and we have > to define how these values propagate not only to subsitemaps, but also > to "cocoon:" sources. For this, my preference goes to adding a new entry > in the object model, which will be easier to manage, eventually through > flow-related additional attributes on <map:mount>. Yes, a method is needed to regulate flow scope with regard to mounted sub sitemaps. We may need something like <map:mount ... propagate-flow="true" > As we discussed earlier, this would be better than having a propagate on the flow tag itself, because this way one can control propagation to individual sub sitemaps Other Issues and Ideas: 1. Renaming The Flow Send Functions. Its clear from speaking with others that the naming of the flow script "sendPage" functions is quite confusing...because infact "sendPageAndContinue" has nothing to do with continuations. I propose: "sendPage()" be moved to "sendPageAndWait()" "sendPageAndContinue()" be moved to "sendPage()". 2. Dynamic Flow Loading. The way I see it, the flow controller managers the flow through a set of available "views" (pipelines in our case). However, its quite possible that in certain situations the flow through this particular set of views will need to differ. For example, the flow through the views for a user with the profile of "administrator" might be different than for that of "user". I suggest we consider providing the ability for dynamicially loaded flow contollers depending on some variable (via inputmodules?).. This would mean that the individual flow scrips would be simpler because they do not have to cater for all possible situations. This would also provide a simple mechanism for flow polymorphism and SoC. Ok. I think thats enough for now. :) Regards, Michael Melhem --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
