From: James M. <jm...@tr...> - 2004-12-18 21:15:04
|
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 > > > > --__--__-- |