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 |