>> I just ran into this in a bad way. I upgraded to 2.06 and whamo, a
>> number of pages no longer worked for me. I finally tracked it down to
>> this 'description' bug. Now I've got 2 lines I have to regularly
>> comment out of Maypole::View::Base::vars - 'description' and 'cgi'.
>>
>> It would be really nice to be able to have column named 'description'
>> without having to hack Maypole...
I wrote:
> I would also vote that being able to have a column called description is
> the priority. Perhaps the class method can be renamed something less
> likely to conflict, like maypole_model_class_description()? That can't
> cause backwards compatibility problems since in previous releases it
> wasn't implemented properly anyway!
I thought about this overnight and would like to change my vote. Instead
of renaming the class description method, I suggest we trash it! There
are two reasons:
1/ Unnecessary complexity
Nobody is using this feature. The implementation has been broken for
quite a while and nobody has complained, whereas several people have
been using columns called 'description'. So it's just a pointless burden
to maintain the code and documentation. It's also one more function
point that newcomers have to learn and remember.
2/ Separation of concerns
The purpose of this method is to return a text string for display on web
pages. Such text should be written by a web designer, not a Perl
programmer. That way it can be easily changed when the site is
redesigned or translated into another language. Equivalent functionality
can easily be provided directly in TT templates. Clear separation of
concerns is one of Maypole's primary design goals.
So I believe the best solution is just to remove the description method
from the interface.
Cheers, Dave
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT