On 15 Nov 2001, at 21:26, Gerald Richter wrote: > There are many nice ideas (and I have a lot of them too), but it takes also > a lot of time to implementing them and as long as nobody pays me for that > (which is fortunately sometimes the case :-), I have to do things that I > need for my projects first and keep the other nice features for the time > that is left. I says this here, because I could imagine that implementing > something like you have in mind, would be really cool, but also would be a > lot of work. Haveing this said, I really like to hear your ideas and discuss > them and as far as we come up with good solutions try to integrate them into > Embperl!
I appreciate the busy problem and all the great stuff you've done with Embperl! I think it is part of the human condition to be too busy to get it all done in one lifetime. Let me know how difficult it looks after you read the rest of this. [- snipped -] I posted a very similar question on the ModPerl list and someone else summarized my request very nicely. This may help: > On 15 Nov 2001, at 15:33, Perrin Harkins wrote: > > The original e-mail was confusing, but I think what he's after is not > so much the ability to call pages as subs but rather the ability to > abstract away the fact that a sub might actually involve multiple user > interactions (present a form, get a response, present another form, > etc.) with breaks in actual execution. In other words, he wants to > think of program execution in terms of a linear user session (as you > would with a GUI app) rather than a series of separate requests. He summarized it just right. I'd like to have an abstraction that effectively removes the stateless nature of this. HTML was not made as a 2-way thing so using it is painful some times. Can it be made more like a typical programming scenario? A typical example: 1) Top level page calls another page to present a form. Execution of the calling page is stopped (actually suspended) waiting for the return to happen. 2) The form is presented to the user and processing stops while waiting for the reply. 3) The user submits the page either to the calling page or to another one (doesn't matter). Validation happens. 4) Other pages could be called either as modules (like step 1) or like they are called now. 5) Final page executes a "return" statement and processing returns to the top level calling page and continues where it left off. In order to implement this: The calling page needs to be able to continue execution when the call is returned. Pages that are called need to know that they are not to drop out the bottom and return to the calling page but to stop instead. The called page needs to pass on the return-to information or a "stack" needs to be implemented for the session so that the eventual return causes execution to go back to the top-level calling page like you would expect. > Is your idea, chaining these pages together, so that one page would only be > displayed if the previous one is done ? Or is a module as see it only a > part of a page, so you can have lets say a user add form and a mail form or > what ever on the same page ? The idea is that a group of pages become a module, with a single entry point and a single return point. Flow of control among the pages in a module would be done normally (as done right now), including the possibility of calling other modules. > Is your idea mainly for input forms or do you have other sort of > objects in mind ? If yes, what ? Not form specific at all. Just a generic control structure that makes a group of stateless transactions behave like a regular subroutine in a modular language. Generic is more useful. > > Scott wrote: > > I realize this is a stateless arena and implementing this would > > require some magic but think Embperl (and you) are able to > > make that kind of magic. Is this possible or does the stateless > > nature of this make it impossible? More modularity would be > > SO nice in this environment! Do you still think this is possible? > Gerald wrote: > Yes, this is possible and especially for form validation I have some plans > in mind, which I can hopefully release before the end of the year, which > will allows you to specify validation rules and what should happen if the > validation fails. Typically, I just have a form call itself for validation with appropriate conditionals. What do you have in mind here? Cordially, Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
