cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Klaasen (TeleRelay)" <tr-tklaa...@telerelay.com>
Subject RE: [RT] Managing Flow and Resources
Date Tue, 11 Dec 2001 09:07:36 GMT


> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org] 
> Sent: dinsdag 11 december 2001 0:31
> To: cocoon-dev@xml.apache.org
> Subject: RE: [RT] Managing Flow and Resources 
> 
> 
> > -----Original Message-----
> > From: ovidiu@orion.rgv.hp.com 
> [mailto:ovidiu@orion.rgv.hp.com]On Behalf
> > Of Ovidiu Predescu
> > Sent: maandag 10 december 2001 23:12
> > To: Berin Loritsch
> > Cc: cocoon-dev@xml.apache.org
> > Subject: Re: [RT] Managing Flow and Resources
> 
> <snip/>
> 
> > When you have forms whose result can branch the flow, you 
> can use the
> > control flow statements, like "if", "while" etc. Here's a 
> non-trivial
> > example of continuations at work.
> >
> > function shopping-cart()
> > {
> >   set-default-pipeline("my-pipeline");
> >   send-page("show-shopping-cart.xml");
> >   operation = request.getParameter("operation");
> >   if (operation == "continue-shopping")
> >     send-page("continue-shopping");
> >   else if (operation == "buy")
> >     buy();
> >   else if (operation == "update-quantities")
> >     update-quantities();
> > }
> >
> > function buy()
> > {
> >   credentials = get-user();
> >   ship-to-address(credentials);
> >   charge-credit-card(credentials);
> > }
> >
> > function get-user()
> > {
> >   // get-user() returns only with valid credentials.
> >   // If no valid credentials are found, this function never returns.
> >
> >   for (count = 0; count < 3; count++) {
> >     send-page("get-username.xml");
> >
> >     user = request.getParameter("username");
> >     passwd = request.getParameter("password");
> >
> >     usersDB = UsersDatabase.newConnection();
> >     if (!usersDB.isUserKnown(user, passwd))
> >       registration();
> >     else
> >       return userDB.credentialsForUser(user, passwd);
> >   }
> >
> >   // This shows the user a sorry page with a single link that
> > points to Home.
> >   // This is an example of a non-local exit, where the 
> computation will
> >   // continue at a different location in the program.
> >   send-page("sorry-page.xml");
> > }
> >
> > function ship-to-address(credentials)
> > {
> >   send-page("ship-to-address", "my-pipeline",
> >             {"address" = credentials.getAddress()});
> >   change = request.getParameter("change");
> >   if (change)
> >     return change-address(credentials);
> >   else
> >     return credentials.getAddress();
> > }
> >
> > function registration()
> > {
> >   // Register a new user
> >   send-page("register.xml");
> >
> >   while (true) {
> >     username = request.getParameter("username");
> >     if (usersDB.isUserKnown(username))
> >       send-page("user-already-known.xml", {"username" = username});
> >     else
> >       break;
> >   }
> >
> >   passwd = request.getParameter("password");
> >   usersDB.registerNewUser(username, password);
> >
> >   send-page("registration-successful.xml"});
> > }
> >
> > function change-address(credentials)
> > {
> >   // Function to change the address. Returns the address 
> the user chose
> >   ...
> > }
> >
> > function charge-credit-card(credentials)
> > {
> >   // Charge the credit card of the user
> >   ...
> > }
> >
> > function update-quantities()
> > {
> >   ...
> > }
> >
> > This example shows how Java objects are used to perform critical
> > functions like connecting to the user's databases, checking for new
> > users and registering them.
> 
> <snip/>
> 
> > Also I don't like to express logic in XML, it's not what it was
> > designed for. We need a programming language, so why use an 
> XML syntax
> > to express this? The attempts to use XML to implement a programming
> > language are taking XML too far, where it wasn't designed to work.
> 
> If and when our little flowmap specification language remains 
> as beautifully
> terse and human-readable as Ovidiu's example above, I do not 
> see a need for an
> XML syntax.

However, XML allows you to enforce some limitations on the users. Java
does not. As you can already see in the example above IMHO, it gets very
difficult to cling to and enforce the SOC principle. The shopping-cart()
function seems to be flow control, but the change-address() is already
business logic IMO.

Of course, the very intelligent programmers who are developing this from
the start, will be able to enforce the SOC for themselves, but newcomers
who learn by trial-and-error (as we all do) will have serious
difficulties to grasp it, even if they want to. Me too (is this
English?) had serious difficulties to grasp the SOC in Struts eg, and I
even thought there wasn't one for quite a while. But then again, maybe
that says more about my capabilities than anything ;-) Anyway, Struts is
also based mainly on java-code, and genericity and SOC is very hard to
achieve.

On the other hand, XML indeed isn't developed for logic. So maybe we
should start on an limititions-enforcable programming language LEPL ;-)

> What we could do to support user adoption is 
> provide plenty of
> already implemented functions, and perhaps maybe later a 
> Visio-like GUI to
> draw the flow.

If you're into Cocoon, you don't like GUI development (except maybe
Bruno Dumon ;-)). It is a whole different world. So the chances are slim
there will stand up anybody to make a GUI.

My 0.02EUR
tomK

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message