On 4 Sep 2004 at 16:12, Simon Cozens wrote:
> David R. Baird:
> > A couple of recent patches are playing around with $r->{query} and
> > $r->{params}. Would it not be more sensible for Maypole to combine
> > both GET and POST parameters into a single set, and put them in
> > $r->{params}, and forget about $r->{query} altogether?
>
> I don't know. A lot of the decisions I've made maintaining Maypole have taken
> into consideration whether or not this would screw over existing Maypole
> users. A change like this would, so I wouldn't do it.
>
> I suspect that I'd like to see behaviour-changing "fixes", like this one,
> mentioned on maypole@ first to make sure users are aware that their
> applications will break the next time they install Maypole. That sort of thing
> tends to put users off a technology, if they're not expecting it.
I certainly agree with you on that. Maybe a compromise would be to
add something like $r->{all_params} to the mix, and deprecate query
and params for the next couple of releases. Or slightly more riskily
(but less reworking of templates), copy all the data into params
(and/or query), and deprecate query (or params).
I have to declare an interest (maybe it's an ulterior motive if
you're a TT fan). MasonX::Maypole could break if future development
of Maypole relied on looking in one or other place for submitted
data.
> Sebastian (the new Maypole maintainer) (hooray!) may view the world
> differently, and I may after all be worrying about nothing, so I'll defer to
> him from now on.
Congrats Sebastian!
d.
-- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk_______________________________________________ maypole-dev mailing list maypole-dev at lists.netthink.co.uk http://lists.netthink.co.uk/listinfo/maypole-dev
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:56 GMT