On 9/17/05, David Baird <[EMAIL PROTECTED]> wrote:
> There's also a roadmap at http://maypole.perl.org/?TheRoadmap. We've
> not made too much progress on it yet, I suspect because hacking
> Maypole is *hard*. If we can simplify the core, we might make more
> progress on the new features.
>
Speaking of the roadmap, In regards to forms and processing which is
still inadequate if not broken at the moment, Where are you guys on
this? I have cleaned up SuperModel.pm and fixed code and stupid
things that long needed fixing. Now it is a general, powerful, and
fairly clean solution to form processing and uses neither
CGI::Untaint or FromCGI. It is almost backward compatible. I
will post a demo site this week where you can see it and AsForm in
action along with a few model classes that have many relationships,
and the latest SuperModel.pm. I'd figure I 'd start the discussion
now. My view, still unchanged, is I would like to see the
functionality you see in the demo to be core Maypole.
I think Maypole should fix this by the next release like the Roadmap says.
I think a sensible solution for the time being is to release AsForm as
Class::DBI::AsFormImproved (I would like to collaborate on that and
add the features we want from all of ours and maybe make a Maypole
specific version if we need to ) and add needed code to
Maypole::Model::CDBI to not use CGI::Untaint or FromCGI. I am going
to clean out SuperModel so it has just what I feel should be base
Model::CDBI functionality for any Maypole app so you can see what my
idea of that is.
Alternatively , release a Maypole::Model::CDBI::SuperModel (I like
that name ) so that people could continue to use either. This may be
good if we want to break some backward compatibility some time.
Notable changes in SuperModel are :
I renamed "untaint_create_all_fromcgi" (or whatever . I cant even
remember the name it was so long) to "create_from_cgi" . It will
return an object with cgi_update_errors. Instead of the $h it takes
$r as the first object and creates the untaint object for you.
This is so it can recurse through the data in case of foreign inputs.
Also, Dave H. you will love this - It could use a Maypole hook to
specify a more sensible error message for the colums. Probably
something in $r->config->table->{$col}->{untaint_error} and
{required_error} . :) Hey, if you are going to be bad, you might as
well be consistently bad.
Validation is done is a sub like FromCGI's validate but with some
Maypole hooks. $r->config->{$table}->{required_cols} , ..{all_cols}
and {ignore_cols } are used if no hash of these variabeles is passed
to create_from_cgi. If the hash assignment is passed, then it sets
those fields (maybe :) ).
In create_from_cgi , No CDBI objects are created until all data is
untainted and there are no errors. In the proof of concept before ,
it would find out if we had errors by calling create_from_cgi. :)
This was problamatic when you were creating 5 objects for a customer.
I finally fixed it. This opens up the easy addition of
"update_from_cgi" which I should finish tomorrow.
I believe the only change for all this to Maypole api would be that
you need to pass $r instead of $h to create_from_cgi and
untaint_from_cgi.
--
pjs
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
