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"
/act
call resource="display error message for connection"
/act
call resource="display error message for conditions"
/matchFor flow, the pattern is:
function useCase1() {
userDate = new UserData();
do {
send_start_page_and_optional_condition_errors(userData);
userData = read_parameters_back();
done = check_conditions(userData);
} while (!done);
if (do_something_with_connection(userData)) {
send_query_result_page();
} else {
send_connection_error_page();
}
}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.
Chris.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
