We have a lot of flowscripts that typically assemble request parameters and information from the session and then create new Java objects which are sent to "createX" or "saveX" methods on DAO objects. These functions are usually around 20 lines of code, sometimes longer. In theory we could delegate these to Java objects, but if we pass in the request object then the Java objects would need to know about Javascript to unwrap the request. Here's an example of one of our flowscript functions:

function doAddNormalCallEntry() {
var callDialog = null;
var callData = null;
importPackage (Packages.com.jentro.manager.callcenter.serverapi );
var roleData = getUserRoleData();
var callStarted = cocoon.session.getAttribute("prepared-call-date");
var customerId = cocoon.session.getAttribute("current-user-id");
var message = getParameter("call");
var callEntry = new CallEntryData();
callEntry.setMessage( message );
callEntry.setStarted( new Packages.java.util.Date() );
callEntry.setColor( Packages.com.jentro.manager.callcenter.CallEntryColorCode.BLACK );
try {
callDialog = lookup( CallCenterHistoryDialog.ROLE );
callData = callDialog.addCallEntry( roleData, callStarted, customerId, callEntry );
}
catch (exception) {
setError( exception);
}
finally {
release( callDialog );
}
}


Do you think this is too much logic for a flowscript function? If so, how would you deal with it?

John

Ugo Cei wrote:

Look at the Javaflow block for this, but if I were you, I would reconsider this choice. The "proper" way of using flowscript is only as a means to script the flow of pages and you should tuck away all business logic inside Java objects. It is certainly *not* recommended to do your app "mostly in javascript".

If you are coming to the GT, my talk on Tuesday will also deal with proper ways of partitiong application logic in a Cocoon application.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to