cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: Rationalising CForms Flowscript Params
Date Fri, 08 Apr 2005 11:37:37 GMT

On 2 Apr 2005, at 09:34, Giacomo Pati wrote:

> On Fri, Apr 01, 2005 at 06:40:01PM +0100, Jeremy Quinn wrote:
>>
>> On 1 Apr 2005, at 17:21, Vadim Gritsenko wrote:
>>
>>> Jeremy Quinn wrote:
>>>> On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
>>>
>>> <snip/>
>>>
>>>>> I personally never used this "handleForm" function and consider it
>>>>> as some old legacy.
>>>> Hmmm, I disagree.
>>>> I never like to embed names of files or pipelines in flowscript
>>>> functions.
>>>> I always pass these in from the sitemap.
>>>> This way, the sitemap is the place where all paths, filenames, uris
>>>> are managed, or the location that consistently retrieves these from 
>>>> a
>>>> config, via input-modules.
>>>> I do not like to spread this around as it makes refactoring more
>>>> difficult.
>>>
>>> Then I suggest you come up with consistent parameters naming and
>>> change this function yourself :-), I'm not against keeping it.
>>
>> OK Vadim :)
>>
>> If there are other people using this function, I would rather have a
>> consensus on what the changes are.
>>
>> I do not actually mind if the consensus is to deprecate the function,
>> but I do think it is a bad idea to recommend keeping paths etc in
>> flowscripts .....
>

OK, I am working on the changes to Form.js to clean up the parameter 
names.

Form.prototype.handleForm = function() {
     // get the form definition
     var def = cocoon.parameters["definitionURI"];
     if (def == null) {
         if (cocoon.parameters["form-definition"] != null) {
             cocoon.log.warn("the form-definition parameter has changed 
to definitionURI");
             def = cocoon.parameters["form-definition"];
         } else {
             throw "Definition not configured for this form.";
         }
     }
     // create the Form
     var form = new Form(def);
     // set the binding on the form if there is one
     var bindingURI = cocoon.parameters["bindingURI"];
     if (bindingURI != null) {
         form.createBinding(bindingURI);
     }
     // get the function to call to handle the form
     var funcName = cocoon.parameters["function"];
     var func = this[funcName];
     // check the function exists
     if (!func) {
         throw "Function \"" + funcName + "\" is not defined.";
     } else if (!(func instanceof Function)) {
         throw "\"" + funcName + "\" is not a function.";
     }
     // call the function
     func.apply(this, [form]);
}

A couple of questions .....

Is everyone happy with function name: "Form.handleForm", and 
parameters: "definitionURI", "bindingURI" and "function"?

I am adding a cocoon.log.warn message to the old handleForm function to 
warn of it's deprecation. Is this the correct procedure?

Is everyone happy that the new function will temporarily use the old 
parameter "form-definition" if the new one is not provided, during the 
deprecation process, and issue a cocoon.log.warn if it used? Or is this 
FS?

Is cocoon.log.warn appropriate for deprecation messages? There is a 
deprecation log now, no? How do you write to it from FlowScript?

> I totally agree with Jeremy that passing over the input to the
> flow script from the sitemap is a good thing for refactoring but
> also for overview. I'm not so much concerned with the form and binding
> URIs as those are normally only used within the function called and
> pollutes the sitemap with mostly irrelevant constants but this is just
> my POV.

They are not always constants. Often people will build the names from 
part of the uri.

> But what I've learned is that especially passing over the URI of
> the "display-pipeline" in a consistent way can help clarify how a flow
> script connects back to the sitemap.

This is a more complex change IMHO.

AFAICS, unless we were to set the "templateURI" parameter on the Form 
object during the "Form.handleForm" function. Then have a new version 
of Form.showForm that does not take the templateURI parameter, there is 
no way this naming can be enforced.

Is this the way you would like to go?

regards Jeremy


--------------------------------------------------------

                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!
--------------------------------------------------------


Mime
View raw message