Cool. Most of the work is done. My boss is happy to give back to the community. I'll get the demo site up and some tests demontrating what this fixes asap. Note it does use CGI::UntaintPatched but that is in our control and same API as CGI::Untaint.
On 9/18/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > Peter Speltz wrote: > >>> ... 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'll be very interested to see this demo site, Peter. Thanks! > > David Baird wrote: > >>I like the sound of this, but I'd like to see a few failing test cases > >>to be clear about what's being fixed. Should be straightforward with > >>Test::WWW::Mech::Maypole ;-) > > Agreed. There are frequently discussions on this list and the user list > where it's clear that some people understand the issue and others don't. > I know because sometimes I'm one of the people who thinks they > understand and other times I haven't got a clue about the issue (any > complex relationship stuff, for example :) > > I think failing tests (a.k.a. example cases for new features) would help > everybody to understand the issues, as well as being useful for actually > testing the code! And it would be great if they could use the standard > example data so far as possible. > > Aaron Trevena wrote: > > This (improved model, backwards compatiblilty, etc) is pretty much > > exactly what I want to do and I had a horrible feeling it was going to > > involve a lot of work (and worse still much of it for me!). > > One of the issues I still don't understand is backwards compatibility. > In this case, we're talking about removing at least two external > modules. I think it's a good idea to do so. But how does somebody who's > written a plugin for CGI::Untaint use it in the new scenario, for > example? Or could I use my hacked about AsForm with it? > > Given that there's no spec about what parts of Maypole constitute public > interface and what is private implementation, it seems to me that > bacwards compatible changes will need to be restricted to code within > single functions. Even then we'll need to be extremely careful. > > Or look at the removal of the 'naughty code' that I think we're all > agreed is a good idea. There was no bug report, it's not broken AFAIK. > It's just ugly. But the change breaks a test, so it's clearly not > backwards compatible. > > I thing all these changes are good ideas. But they're not backwards > compatible by my understanding of the term. So that's one of my > difficulties with this issue. (My other difficulty is the _need_ for > backwards compatibility, but I've bitten the bullet on that) > > Cheers, Dave > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 16/09/05 > > > > ------------------------------------------------------- > 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 > -- 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
