On 10/5/05, Timo Stamm <[EMAIL PROTECTED]> wrote: > Is support for flow oriented programming necesary? I think it is highly > desirable. With abstractions of data objects and editors (in the spirit > of the Code generator / Prototype generator thread), you can concentrate > on the most important part of most applications: the flow. If you don't > have to spread your business logic and work flow over several classes > and layers, you will simply increase the code quality.
The flow is important when you control a nuclear power station: you should drop the rods before cutting out cooling water. Contrary to that, "the most important part of most applications" is the data. Interactive applications obtain data, present data, search for data in persistent storage and persist new or updated data, not the flow. Who cares what the flow is, if the data is incorrect? Of course, we can synchronize model state with flow state, but what is the point? Our actions still depend on data and its state, not on the flow. In a sense, model has an implicit flow built in, because when you create new data, you can do this and this; when you save data you can do that and that. I don't want this discussion to become an advertisement of one's ideas and bashing of other's ideas, but I really don't see the point of the flow for interactive applications (most of them are CRUD-type applications), especially for web applications. Why? Because flow would be inevitably linked with views, views are pages, pages have addresses, which are accessible by a user. The user can navigate to any arbitrary view, and after that the flow would have to solve the problem: what to do, flow was in state A, but now user invoked state B, how to synchronize it? Do you want to sync view with model or model with view? Or maybe flow with model and view with flow? There is a lot of stuff that depend on each other, and flow, while somewhat formalizing the sequence of operations, brings in another stateful object, which should be synchronized with other stateful objects. I worked on the flow idea for quite some time, and decided that it is generally unproductive and unfriendly to restrain a user to an artificial flow, while he has an ability to navigate to any arbitrary view of the application. Indeed, why for flow sequence A->B->C, a user should be restricted to page A after visiting page B? State of the model, this is what important. So, I came up with idea of a wizard, which is kind of lightweight flow, but a specialized one. Flow in general defines a sequence of states or events, while wizard is an interface element, which facilitates proper creation or updating of an object. See the difference? Sequence of events vs. steps to build an object. Wizard steps are sequenced too, but this sequence is not the main governing mechanizm, it is just a guideline, which allows to split one big lump of input data into several smaller chunks. I prefer that application pages, elements etc to be unrestricted in general, and to control only minor parts of application, using short wizards. Because the whole wizard is executed in context of one web resource (in Wicket terms, one Page), then a user cannot navigate to an arbitrary view of the wizard, he can either leave the wizard, or enter it, then the wizard will render a view corresponding to its current state. Too much bashing/advertisement? ;-) Well, I am off to have a dinner... er, supper :-) Michael. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
