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
> 
> 
> 
> --__--__--