You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Chris Clark <Ch...@teranet.ca> on 2003/07/11 19:41:57 UTC
JXForms Concerns/Questions
> I'm involved in a large development project that will involve a lot of large form filling out/processing. We are planning on using Cocoon and have laid out a UI model. Currently we're trying to decide on a form architecture and after looking at samples and docs, there are a few things we'd like to raise here--don't need to focus on "how-to's", but rather architectural implications.
>
> 1) Do you need a separate flowscript and therefore a separate sitemap for each JXForm? The samples imply that each form has to have a script and each script is associated with a sitemap. This would lead to a huge number of subdirectories and sub-sitemaps for our project which is not desirable. We can live with one java class/form as XMLForm seems to need, but one directory with a script and associated pages per form is unacceptable.
>
> 2) For a simple, one-page form, do you need to have a script? Is there a sample of a single-page form using JXForm?
>
> 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.
>
> 4) Is it possible to dynamically pre-populate a JXForm from a database? 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?
>
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.
And one specific question:
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
chris.clark@teranet.ca
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.
Re: JXForms Concerns/Questions
Posted by Christopher Oliver <re...@verizon.net>.
Ugo Cei wrote:
> Christopher Oliver wrote:
>
>> 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?
Yes, you're right.
>
> 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?
Agree. The page uri should be optional in Form.finish().
Re: JXForms Concerns/Questions
Posted by Ugo Cei <u....@cbim.it>.
Christopher Oliver wrote:
> 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).
>
>>>
>>
>> 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?
>>
>>
> I won't. Maybe others will.
>
>> 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:
>>
>> 8) JXForm documentation in general - is there any/where is it? (I
>> haven't been able to find anything.)
>>
> 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.
>
>>
>> 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
>> chris.clark@teranet.ca
>>
>> 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.
>>
>>
>>
>
Re: JXForms Concerns/Questions
Posted by Christopher Oliver <re...@verizon.net>.
Chris Clark wrote:
>>I'm involved in a large development project that will involve a lot of large form filling out/processing. We are planning on using Cocoon and have laid out a UI model. Currently we're trying to decide on a form architecture and after looking at samples and docs, there are a few things we'd like to raise here--don't need to focus on "how-to's", but rather architectural implications.
>>
>>1) Do you need a separate flowscript and therefore a separate sitemap for each JXForm?
>>
No. See the petstore example. You just need a separate function. All
your functions can be in one script.
>>The samples imply that each form has to have a script and each script is associated with a sitemap. This would lead to a huge number of subdirectories and sub-sitemaps for our project which is not desirable. We can live with one java class/form as XMLForm seems to need, but one directory with a script and associated pages per form is unacceptable.
>>
>>2) For a simple, one-page form, do you need to have a script? Is there a sample of a single-page form using JXForm?
>>
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()
}
>>
>>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).
>>
>>
>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?
>
>
I won't. Maybe others will.
>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:
>
>8) JXForm documentation in general - is there any/where is it? (I haven't been able to find anything.)
>
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.
>
>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
>chris.clark@teranet.ca
>
>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.
>
>
>