cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: Best practice for "database" manipulation?
Date Tue, 17 Feb 2004 10:31:06 GMT wrote:
>>Other than that, my advice is to put your database access into a java 
>>class (better: Avalon components) and access it from flow. If 
>>you cannot 
>>or don't want to use flow, use actions to access it.
> Hmm. Could you give a more detailed example of how this would look like with
> either flow or actions? I do have some Java classes now that do the actual
> database connection, which I now call from my XSP page. So it would be very
> helpful if you could write down a (set of) sitemap pattern(s) with a round
> trip (i.e. put query into "DatabaseConnection", put result through Woody on
> screen, put result back into "DatabaseConnection").

Well, I can't really help on the Woody part.

For an action, tha pattern is

match pattern="use case 1"
    act type="guard that conditions are satisfied"
       act type="do something with connection"
          call resource="display results handed down from action through 

                         eg. request attributes"
       call resource="display error message for connection"
    call resource="display error message for conditions"

For flow, the pattern is:

function useCase1() {
   userDate = new UserData();
   do {
      userData = read_parameters_back();
      done = check_conditions(userData);
   } while (!done);
   if (do_something_with_connection(userData)) {
   } else {

If the logic is contained in avalon components, you'd need to obtain 
them first (AFAIR cocoon.newInstance(MYCOMPONENT.ROLE)) and release them
afterwards. Remember to release components before creating a 
continuation, though.

> I don't like the idea of handling _everything_ in flow (like the petstore
> example), which would make me look in two places (flow and sitemap) to find
> out what's going on. I do use flow with Woody, but then I prefer to use and
> reuse generic functions where all the variables (which
> template/binding/definition and where to redirect to) are passed in as
> parameters from the sitemap. I guess that I prefer flow to actions because
> it's easier to debug and modify.

The key is to use flow _only_ to call your business logic (which is in 
avalon components) in correct order and react to exceptions (error 
conditions, user faults).

Personally, I would try to avoid redirects where possible and hide a 
complete use case (or user story) under a single URL.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message