|
From: Gaulin, M. <mg...@gl...> - 2004-12-17 19:52:00
|
Hi Shane
I haven't written any plugins for slash yet, but I have done a lot of =
development on fairly big and extensible applications (though not in =
perl). To me, it seems a little dangerous for a plugin author to make a =
global decision about how a parameter is to be used... only the =
framework authors get to make global decisions. (That would suggest not =
adding it to Environment.pl) That said, an extensible framework library =
should make it easy to do common things (like validate parameters), so =
you might expect to see that stuff factored out into generic code, with =
the built-in stuff (like Environment.pm) using that generic code to get =
it's job done. That leaves the parameter validation up to the plugin =
author (presumably inside their own code) but it should only take a line =
or two to get the job done.
Your question about passing in the whole form or just the arguments =
picked out from the form is tricky... I like to handle user input =
validation and argument "marshalling" all at one layer in the code, near =
the "front", with the "working parts" below it taking explicit arguments =
(vs a bag of arguments). Sometimes you get into places where it doesn't =
make sense to make arguments out of everything, esp when they are lots =
of parameters or if there are an arbitrary number of them. In those =
cases I like to pull out the fixed arguments and pass them explicitly, =
along with the bag. There can also a separation of concerns issue here =
too, where there can be so many layers of code that extracting the =
arguments out of the bag early can lead to lots of (pointless) code =
changes whenever a new argument is added, just so they can be passed =
down to where they are really needed. Even in those cases though, I can =
usually define an object to cover many of the related arguments, and =
then the code changes from passing in lots of little things into passing =
in one bigger thing. (I program in java mostly these days, so the OOP =
stuff is cleaner than in perl, at least to me.)
So, yeah, there is no one right way, but there are certainly ways that =
are easier to live with in the long run. I like to use those.
Mark
-----Original Message-----
From: sla...@li...
[mailto:sla...@li...]On Behalf Of
Shane
Sent: Friday, December 17, 2004 7:55 AM
To: sla...@li...
Subject: [Slashcode-development] $form data
What's the general concensus on checking and passing form data?
If you browse through slash-src, as well as 3rd party released code,=20
people do it many different ways. An example:
you have a form, and you create a pulldown in the form using=20
Slash.createSelect. it's passing back what's supposed to be an integer,=20
let's call it intID for simplicity's sake. In your perl script, you=20
eventually need to pass this intID to a method in your perl module.
So do you:
pass the entire $form
pass part of the form, $form->{intID}
where do you do the integer-validity check? or do you patch=20
Slash::Utility::Environment::filter_params and have it do the work for=20
you?
Obviously, a lot of this "just depends" on what you're coding for. But=20
considering that for everything I've ever coded for slash, I've done=20
all of the above at one time or another for one reason or another.
The biggest pain, for me, is having to patch Environment.pm to add my=20
vars to filter_params, so I often find that I don't bother with it, and=20
then forget about it.
I thought I might drum up some discussion, so let's see what y'all=20
think.
Shane
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Slashcode-development mailing list
Sla...@li...
https://lists.sourceforge.net/lists/listinfo/slashcode-development
|