slashcode-development

RE: [Slashcode-development] $form data

[Gaulin, M. <mg...@gl...>]

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

Re: [Slashcode-development] $form data

[James M. <jm...@tr...>]

Disclaimer, I haven't looked in depth at the slashcode core for ages.
(By the way, can we stop bracing for impact anytime soon?).  So what
follows might be out of date compared to the current best practices...


My preferred methods are

parse form for key,value pairs

pass those as an args hash

OR

on creation of handler object, pass the results of get_form (the form)
as one of the hash arguments ('form'=>$form), then in the object
initialization, populate what I need from $form (or save the whole
thing if I am being lazy, and fetch what I need later).  Actually, in
retrospect, I do that, as in 

in parent handler

my $form = getCurrentForm();
...
my $handler = $ops->{$op}->{'class'}->new('form'=>$form,
                                          'user'=>$user,
                                          'op'=>$op);

Inside of handler base class, I have

sub _init {
 ...
 $self->{'_form'}=$args{'form'}; # actually handled in my parent class
                                 # as hash_init
 ...
}

then in my base class I also have

sub form {
    my ($self,$key) = @_;
    if(defined ($key)){
        return $self->{'_form'}->{$key} ;
    }
    return undef;
}

If the child class knows what key it wants (jeez, it better, it is
handling the form response after all), then it just says

my $key = 'superSecretFormKey';
my $value = $self->form($key);

 
There was an earlier comment about Java handling oop in a cleaner way,
or something like that.  I think about the handler and the message
container in oop terms too, its just that my message container is a
hash, which is infinitely flexible for stuffing messages.  When I
programmed an MVC in Java, my generic data object was just a glorfied,
hard-to-use wrapper around a hashtable.  

So in response to your argument, I pass the entire form.  I guess that
sorta maps onto the theory that your code for getting the messages
from the web browser and sending them along to the actual back end
handlers should know as little as possible about what the back end is
doing, what the browser is doing.  As long as the 'op' in the form
resolves to a class in my handler, then I create the class, with the
contents of the form, and call a generic method 'process' that all of
my handler classes implement.  If $form->{'op'} is meaningless, or if
$user->{'seclev'}<$form->{'op'}->{'class'}->minimum_seclev (or
whatever), then I bounce the reply to the default page (usually just
the menu).  What is that called, a transparent contoller?

The handler class has to parse, untaint (I really have no idea what
tainting is, but I need to learn), and approve of the contents
of the form.  If it isn't an int, the handler has to complain.

I've never used Slash::Utility::Environment::filter_params.  Couldn't
you inherit from that class, and override the method filter_params to
additionally parse your data?  But then, if you are only looking at
your data, what is the point of using SlashUtilityEnvironment class?
I guess it would be good if there are generic params you might also be
using.  again, I haven't ever looked at that class.  

(Btw, you can also shove javascript in your template file to validate
form data using the client's CPU cycles if you want, but personally I
try to use javascript as little as possible.  Just for stupid stuff
like scrolling animations of random pictures which sets my laptop
bubbling at 60% cpu....)

my two cents,
james

At approximately Fri, Dec 17, 2004 at 07:54:38AM -0500, Shane wrote:
> What's the general concensus on checking and passing form data?
> 
> If you browse through slash-src, as well as 3rd party released code, 
> people do it many different ways. An example:
> 
> you have a form, and you create a pulldown in the form using 
> Slash.createSelect. it's passing back what's supposed to be an integer, 
> let's call it intID for simplicity's sake. In your perl script, you 
> 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 
> Slash::Utility::Environment::filter_params and have it do the work for 
> you?
> 
> Obviously, a lot of this "just depends" on what you're coding for. But 
> considering that for everything I've ever coded for slash, I've done 
> 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 
> vars to filter_params, so I often find that I don't bother with it, and 
> then forget about it.
> 
> I thought I might drum up some discussion, so let's see what y'all 
> think.
> 
>   Shane
> 
> 
> 
> --__--__--