Michael Jouravlev wrote:
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.
With proper abstractions of data objects and editors you have already
cared about data. You can care about flow now.
You are right, data is most important. But quite often, flow is part of
the data integrity and I find myself checking various constraints before
performing an action the user has requested.
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?
Sometimes the flow is part of the data integrity.
[...]
I really don't see the point of the
flow for interactive applications (most of them are CRUD-type
applications), especially for web applications.
Yes, especially web applications are _lacking_ workflows. That's because
they are not trivial to manage.
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
Can he? If business logic says that the user can only publish an article
before it has been previewed, it would be irritating and maybe even
dangerous (not because of core meltdown, but because of data integrity)
to make the preview page accessible unless the preview page has been viewed.
A more common example is a login. In wicket, there is a method in the
page class you can utilize to implement a global login. In a
continuation-based framework, it would look like this:
initializeApp() {
boolean authenticated = login(askForUserCredentials());
if (!authenticated) {
initialize();
}
// ...
}
Now, that's a simple example. But imagine having not only one
constraint, but a dozen.
You can find a more complex example here:
http://www.rubygarden.org/ruby?ContinuationExplanation
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.
Of course it is unproductive to restrain the user to an artificial flow.
Nobody wants that and continuations certainly do not imply that.
But what if your flow is not artificial, but mandatory?
I prefer that application pages, elements etc to be unrestricted in
general, and to control only minor parts of application, using short
wizards.
I guess most applications have a menu or navigation (being mostly
unrestricted) which provides entry points to workflows.
Continuations and wizard components aren't mutually exclusive. If there
was support for continuations, or an emulation of continuations, a
wizard component would probably utilize it.
Too much bashing/advertisement?
We're barely touching the surface :-)
Timo
-------------------------------------------------------
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
