On 1 Apr 2005, at 18:28, Sylvain Wallez wrote:
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.
In that case you can still pass <map:parameter name="blah" value="forms/{1}.xml> and use cocoon.parameters.blah in the flowscript.
Of course.
I was primarily reacting to your suggestion to encode filenames in flowscript :-)
As I said to Vadim, if the consensus is to remove handleForm, I do not really mind.
But I admit that from a lines of code POV, this becomes more verbose than the current situation.
Then if handleForm is to be retained, it should maybe contain error-checking to make sure that the sitemap has indeed supplied these parameters properly, thereby hopefully reducing verbosity in the handler function itself. Part of what triggered this rant, was that a colleague complained at unhelpful error messages when they left out one of the parameters.
Then I suggest you come up with consistent parameters naming and change this function yourself :-), I'm not against keeping it.
+1 :-)
And since we're at changing this, it would be good to attach this function to the Form Javascript class to prevent any name clashes.
<map:call function="Form.handleForm">
<map:parameter whatever but consistent/>
</map:call>
Good idea.
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM MEAlways check the label, folks !!!!! --------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
