Yes, you do. Because there will be actions you take to process the form. These are triggered by the script.
function onePageForm(form) { var obj = new MyJavaObject(); form.setModel(obj); form.sendView("theOnlyPage.xml"); // A validated form has been submitted, // process the form here: obj.processForm() }
Don't you need to call form.finish() afterwards in order to clean up?
By the way, form.finish() takes an URI as a mandatory parameter and dispatches to it. I was thinking about implementing a parameterless version of form.finish that would just perform the necessary cleanup but not dispatch to a view. I need this to call a login form before showing a data entry form, in case the user has not already logged on. After login, I want to show the originally requested form and not a fixed one.
function login() {
// initialize a new form object
var form = new loginForm();
form.sendView("login");
// check credentials
form.finsh();
}function protectedForm(form) {
if (user == null) {
login();
}
form.setModel(...);
form.sendView("protected");
// etc...
}What do you think?
Ugo
3) Do you have to use javascript with flow or can you substitute something else (a java class)? We don't have any experience with javascript and were hoping to keep our development technologies limited to XML/HTML, XSLT and Java classes.
You can easily call any Java code from your flow script:
var map = new java.util.HashMap(); map.put("foo", "bar");
See: http://wiki.cocoondev.org/Wiki.jsp?page=JavascriptForJavaProgrammers
4) Is it possible to dynamically pre-populate a JXForm from a database?
Yes, of course. See the petstore sample and the below link:
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscript
The sample has the data hard-coded and as we're not javascript fluent, we don't know if it's possible.
5) We have some concerns with the continuation model's scalability. Making the assumption that there is something memory-resident on the server side, how does one clean up old continuation objects? what is the lifecycle? what is the memory footprint?
You can explicitly release continuations, or you can configure garbage collection for them based on a timer.
Continuations use relatively little dynamic memory (basically they just contain the program counter and a reference to an array of local variables for each call frame).
I won't. Maybe others will.
6) Regarding the recent discussions of refactoring JXForm and XMLForms and possible deprecation of the Cocoon XMLForm codebase. If we embark on an XMLForm development effort - which we were planning to do, we are concerned about impact to our project. Will the Cocoon committers consider continued support of XMLForms?
7) If XMLForms code base is retained, is the community considering refactoring enhancements in XMLForm.org code base back into Cocoon XMLForm codebase? We would be very interested in this.I'm sure any contribution will be considered. What enhancements are you interested in?
And one specific question:Sorry, there's nothing available yet (I can't promise, but maybe next week I'll have time to work on that). But I believe JXForms is nearly identical to the updated XMLForm syntax on xmlform.org.
8) JXForm documentation in general - is there any/where is it? (I haven't been able to find anything.)
Sorry for the length, but we're at a crucial decision point in our project and as Cocoon seems to be at a similarly crucial decision point, we felt it worthwhile to ask these questions.
Thanks, J. Chris Clark Senior Developer Teraview Development
Teranet Inc. 1 Adelaide St. E. Toronto, ON, M5C 2V9 416.360.8863x2413 [EMAIL PROTECTED]
Proud to be one of "Canada's Top 100 Employers 2003" http://www.teranet.ca/corporate/news/top100.html
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
