Re: Rationalising CForms Flowscript Params
On 8 Apr 2005, at 12:37, Jeremy Quinn wrote:
OK, I am working on the changes to Form.js to clean up the parameter
names.
Form.prototype.handleForm = function() {
Form.prototype.handleForm was wrong, it should have been the static
form : Form.handleForm = function().
However this is not currently working with the
FOM_JavaScriptInterpreter.callFunction, so I am using the simple form
handleForm.
// 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.";
}
}
So handleForm now prefers the parameter 'definitionURI', but it will
still allow 'form-definition' while logging a warning. The form samples
sitemap is updated accordingly.
I am sorry to say that I could not work out why the call to the static
function Form.handleForm does not work. If someone manages to fix this,
then I will setup the function to use the static one instead.
BTW. I cannot commit changes to status.xml ATM.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
smime.p7s
Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
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:
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 !
smime.p7s
Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
On Apr 2, 2005 10:34 AM, Giacomo Pati <[EMAIL PROTECTED]> 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: > > > > > > > > > > > >>>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 . > > 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. 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. > > Ciao > > Giacomo > > -- > Giacomo Pati > Otego AG, Switzerland - http://www.otego.com > Orixo, the XML business alliance - http://www.orixo.com > > > If its of any interest, and more as a user than a cocoon developer. Defining the variables in sitemap is the only real means of developing in such a way that when common patterns can be abstracted that flowscripts can be reused, the only other attempt I've seen at reuse without using the sitemap to define resources resulted in the coupling of the file system to the code. Mark
Re: Rationalising CForms Flowscript Params
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: > > > > > > > >>>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 . 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. 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. Ciao Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
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: 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 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. Good idea. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
On 1 Apr 2005, at 17:21, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 1 Apr 2005, at 15:33, Sylvain Wallez wrote: 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 . regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
beatejung wrote:
hi,
i really agree with jeremy ...
maybe my opinion is not so important here because i do not made too many
experiences with cocoon yet, but i really like the parameters with
...
it is nice to use wild cards * and {1} and so on in the pipeline to create the
filenames and other pilelines i need. i like the flexibility i get.
in some cases i was so keen and added some other parameters just for my own
purposes like
You can access any parameter you want in the flowscript using
"cocoon.parameter.blah", so you do not really /need/ the handleForm
function. But we can consider keeping it (with more consistent names) as
a convenience for a common need.
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Rationalising CForms Flowscript Params
Vadim Gritsenko wrote: Jeremy Quinn wrote: On 1 Apr 2005, at 15:33, Sylvain Wallez wrote: 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 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. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Rationalising CForms Flowscript Params
Jeremy Quinn wrote: On 1 Apr 2005, at 15:33, Sylvain Wallez wrote: 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. Vadim
Re: Rationalising CForms Flowscript Params
Am Freitag, 1. April 2005 16:52 schrieb Jeremy Quinn:
> On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
> > Jeremy Quinn wrote:
> >> Hi All
> >>
> >>
> >>
> >> During the process of stabilising CForms could we please consider
> >> rationalising the parameters sent to forms.js from the sitemap?
> >>
> >> This really bugs me :
> >>
> >>
> >>
> >>
> >>
> >>
> >> Can we come up with better matching names for these please ?
> >> Names that have a similar case and/or hyphenation scheme?
> >>
> >> form-function, form-model, form-binding
> >> form-function, form-definition, form-binding
> >> formFunction, formModel, formBinding
> >> formFunction, formModelURI, formBindingURI
> >> function, modelURI, bindingURI
> >>
> >> etc etc.
> >>
> >> I do not really mind what they are, but they should at least look as
> >> if they are within the same concern.
> >>
> >> I propose that the old names are used if the new ones were not
> >> supplied but a deprecation notice is logged, then later they can be
> >> taken out.
> >
> > I propose that the "handleForm" shall be deleted, as IMO it really
> > doesn't make sense to specify all this information in the sitemap ;-)
> >
> > Compare this :
> >
> >
> >
> >
> >
> >
> > function myFunction(form) {
> >form.showForm("blah");
> > }
> >
> > and this, which does exactly the same:
> >
> >
> >
> > function myFunction() {
> >var form = new Form("model.xml");
> >form.createBinding("binding.xml");
> >form.showForm("blah");
> > }
> >
> > 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.
>
> regards Jeremy
>
>
>
>
>If email from this address is not signed
> IT IS NOT FROM ME
>
> Always check the label, folks !
>
hi,
i really agree with jeremy ...
maybe my opinion is not so important here because i do not made too many
experiences with cocoon yet, but i really like the parameters with
...
it is nice to use wild cards * and {1} and so on in the pipeline to create the
filenames and other pilelines i need. i like the flexibility i get.
in some cases i was so keen and added some other parameters just for my own
purposes like
so it is really very easy using one pipeline for many things and change with
some little efforts.
maybe we can have not less but more parameters with names like jeremy said?
regards beate
--
þíþí
Re: Rationalising CForms Flowscript Params
Sylvain Wallez wrote: Jeremy Quinn wrote: This really bugs me : I propose that the "handleForm" shall be deleted, as IMO it really doesn't make sense to specify all this information in the sitemap ;-) I personally never used this "handleForm" function and consider it as some old legacy. +1; and same here. Vadim
Re: Rationalising CForms Flowscript Params
On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
Jeremy Quinn wrote:
Hi All
During the process of stabilising CForms could we please consider
rationalising the parameters sent to forms.js from the sitemap?
This really bugs me :
Can we come up with better matching names for these please ?
Names that have a similar case and/or hyphenation scheme?
form-function, form-model, form-binding
form-function, form-definition, form-binding
formFunction, formModel, formBinding
formFunction, formModelURI, formBindingURI
function, modelURI, bindingURI
etc etc.
I do not really mind what they are, but they should at least look as
if they are within the same concern.
I propose that the old names are used if the new ones were not
supplied but a deprecation notice is logged, then later they can be
taken out.
I propose that the "handleForm" shall be deleted, as IMO it really
doesn't make sense to specify all this information in the sitemap ;-)
Compare this :
function myFunction(form) {
form.showForm("blah");
}
and this, which does exactly the same:
function myFunction() {
var form = new Form("model.xml");
form.createBinding("binding.xml");
form.showForm("blah");
}
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.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
smime.p7s
Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
Jeremy Quinn wrote:
Hi All
During the process of stabilising CForms could we please consider
rationalising the parameters sent to forms.js from the sitemap?
This really bugs me :
Can we come up with better matching names for these please ?
Names that have a similar case and/or hyphenation scheme?
form-function, form-model, form-binding
form-function, form-definition, form-binding
formFunction, formModel, formBinding
formFunction, formModelURI, formBindingURI
function, modelURI, bindingURI
etc etc.
I do not really mind what they are, but they should at least look as
if they are within the same concern.
I propose that the old names are used if the new ones were not
supplied but a deprecation notice is logged, then later they can be
taken out.
I propose that the "handleForm" shall be deleted, as IMO it really
doesn't make sense to specify all this information in the sitemap ;-)
Compare this :
function myFunction(form) {
form.showForm("blah");
}
and this, which does exactly the same:
function myFunction() {
var form = new Form("model.xml");
form.createBinding("binding.xml");
form.showForm("blah");
}
I personally never used this "handleForm" function and consider it as
some old legacy.
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Rationalising CForms Flowscript Params
Hi All During the process of stabilising CForms could we please consider rationalising the parameters sent to forms.js from the sitemap? This really bugs me : Can we come up with better matching names for these please ? Names that have a similar case and/or hyphenation scheme? form-function, form-model, form-binding form-function, form-definition, form-binding formFunction, formModel, formBinding formFunction, formModelURI, formBindingURI function, modelURI, bindingURI etc etc. I do not really mind what they are, but they should at least look as if they are within the same concern. I propose that the old names are used if the new ones were not supplied but a deprecation notice is logged, then later they can be taken out. Thanks regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
