cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: [RT] Flowmaps
Date Wed, 19 Jun 2002 19:05:11 GMT
On 6/18/02 2:00 AM, "Piroumian Konstantin" <KPiroumian@protek.com> wrote:

>> 6. Multi-page forms are not dominating, and continuation
>> based compared to
>> even driven (GUI-like) programming approaches.
>> 
>> I used to program GUIs a lot, I think for certain things,
>> event-driven is
>> better than using continuations. I do think however that
>> continuations have
>> a place, especially for multi-page forms. Now I think it
>> depends a lot on
>> the application, whether these forms are prevalent or not.
> 
> So, what about a general interface to flow controller (be it a flow script
> or a flow map) that will allow to use any implementation you like? I know,
> I've already ask about this before, just want to remind about it. And as
> I've already said, though, I like the idea of continuations very much, but I
> can't and don't want to use your JS-based implementation in our product, but
> would like to plugin our XML-based flow engine (it is also supports
> something like continuations - we call it 'history' here).
> 
> And what about a 'flowlet' term instead of flowscript or flowmap? ('Flowlet'
> was copyrighted a while ago by Oak Groves, but the company exists no more
> and I don't know if there will be any legal issues with this name).

As Reinhard already pointed out in a different email, the flow code is built
as a component. The main interface is Interpreter.java: you can implement
your own component that follows this API. I'm open to changes in the API to
accommodate a different implementation of the flow layer, as long as the
semantic is similar. If you need a different semantics, perhaps a different
component which implements your own API will better suit you.

>> 11. With respect to how to put a back button on a page, I
>> think I replied to
>> this some time ago. The idea is to use the
>> <jpath:continuation select="1"/>
>> which selects the previous continuation.
> 
> Did you mean: <jpath:continuation select="-1"/> ? And, BTW, why
> <jpath:continuation /> and not <flow:continuation />? I think that JXPath
> logicsheet has more general use and can be used separately to access the
> data from request/session attributes.

I essentially reused the logicsheet, changing the namespace would have
required a different logicsheet to be implemented. We can change that, no
problem.

>> 
>> 13. Piroumian asks how to cancel a continuation.
> 
> I'd say: Konstantin asks ... (our Exchange server swaps my first and last
> names on a random basis ;))

Oops, sorry about this, it's really embarrassing sometimes. I'll give you a
beer when/if we meet ;)

>> 
>> As I mentioned in several ocasions, sendPage() returns the saved
>> continuation. If you want to cancel the continuation just
>> invoke on it the
>> invalidate() method. It will cancel all the receiver and all the
>> continuations that inherit from it.
> 
> What about a method that will cancel all the continuations tree (including
> parent nodes)? Maybe an 'invalidateAll()'? E.g. when user click on a
> 'Cancel' button in the wizard.

The problem is that you don't want to invalidate continuations starting from
a child in the tree, since you may miss branches. Instead what you do is to
keep track of the top level continuation for your transaction, and then
cancel the whole subtree. Here's an example:

function buy()
{
  var transaction;

  transaction = sendPage("shoppingCart.html", ...);

  sendPage("shippingAddress.html", ...);

  sendPage("creditCardInfo.html", ...);

  sendPage("invoice.html", ...);

  // Send all the request data to the back-end systems for processing

  // Invalidate the previous pages, so the user cannot go back to them
  transaction.invalidate();

  // sendPageAndContinue is similar to sendPage, but it doesn't create any
  // continuation
  sendPageAndContinue("shippmentDetail.html", ...);
}


Note that this example doesn't explicitly handle the cancel operation. Such
an operation would cause the home page to be displayed for example, thus
allowing the user to come back to the process later. If you want to handle
this explicitly, you'd need to write the code instead like this:

function buy()
{
  var transaction;

  transaction = sendPage("shoppingCart.html", ...);

  if (sendPageAndCheck(transaction, "shippingAddress.html", ...))
    return;

  if (sendPageAndCheck(transaction, "creditCardInfo.html", ...))
    return;

  if (sendPageAndCheck(transaction, "invoice.html", ...))
    return;

  // Send all the request data to the back-end systems for processing

  // Invalidate the previous pages, so the user cannot go back to them
  transaction.invalidate();

  sendPageAndContinue("shippmentDetail.html", ...);
}

function sendPageAndCheck(page, data)
{
  sendPage(page, data);
  if (request.getParameter("action") == "cancel") {
    transaction.invalidate();
    sendPageAndContinue("transactionCancelled.html");
    return true;
  }
  return false;
}

>> 14. Another question Piroumian has is how to validate against business
>> logic. Since JavaScript is tightly integrated with Java, you
>> can call Java
>> logic from the flow script to do the business logic
>> validation. This way you
>> can invoke whatever logic you want. If this is too generic,
>> then provide
>> some use case and I'll try to sketch a solution.
> 
> I know that you can call Java from JS, but where do you get all the needed
> objects? A simple example would be fine to have. E.g. when the feedback
> wizard from XMLForm sample gathers all the needed data then some business
> call should be made to store the data in a DB, send an email (maybe
> transformed by a stylesheet and sendmail logicsheet), or something like
> that.
> 
> A more interesting example for me would be an EJB call (how would you get
> the InitialContext, lookup the EJB, etc.).

For a database or EJB call, you usually have a Java factory class which you
need to invoke to obtain actual objects. You usually create your own Java
classes that manage these things for you, and provide either a static method
or allow the class to be instantiated to gain access to the backend.

You can also do everything in JavaScript, but beware that you're moving the
business logic in JavaScript, where it shouldn't be. This is great for rapid
prototyping however. Here's how you'd write in it JavaScript (beware, not
tested):

importPackage(java.sql);

Class.forName("org.gjt.mm.mysql.Driver").newInstance();
Connection conn  = DriverManager.getConnection(
                   "jdbc:mysql://localhost/test?user=...&password=...");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT field from MyTable");
...


The EJB sample would look similar, where you use JNDI to lookup your EJB
bean and access it:

importPackage(javax.ejb);
importPackage(javax.naming);
importPackage(my.very.own);

Context ctx = getInitialContext();
SomeBeanHome beanHome
  = (SomeBeanHome)ctx.lookup("my.very.own.SomeBeanHome");
SomeBean bean = beanHome.create();
...

>> 20. My job - thanks Stefano for bringing it up. Here's my
>> shameless plug :)
>> If you think of using Cocoon for building Web apps or Web
>> services, and you
>> need support in doing so, I am providing consultancy for
>> doing it, anytime,
>> anywhere.
> 
> What about a 'Job opportunities' page on Cocoon site? I'd like to do more
> Cocoon-related work too if there were sponsors for that. ;)

Sounds like a good idea!

> Thanks for all your answers and your _very_ interesting and cognitive work!

You're more than welcome!

Greetings,
Ovidiu

-- 
Ovidiu Predescu <ovidiu@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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


Mime
View raw message