Dave Howorth:
> I wrote:
> >>Maypole::Config
> >>---------------
> >>Is there any significance in the order in which methods are listed? If
> >>so, it would be good to explain it. If not, alphabetical order would be
> >>nice :)
>
> and Sebastian replied:
> > Patches welcome ;)
>
> So here's a new version of Maypole::Config in alphabetical order :)
Documentation patch, big thanks! Applied!
> tables
> ------
> This is mandatory, according to Maypole::Model::Base, so why is it
> described as 'if supported'?
We only only require classes(), tables() are optional.
>
> table_to_class
> --------------
> This appears to be a private config variable used by
> Maypole::Model::CDBI::Plain in order to support the required class_of()
> interface method. As such:
> - I don't see that it's view-related.
> - I don't think it should be documented in the public interface of
> Maypole::Config.
> - This is a clear example of the need for models etc to be able to
> extend the config state. I believe there should be a documented way for
> modules to do this, as I've said before. There are two reasons: (1) it
> means the people writing extensions can just get on and do it without
> worrying about unwanted side-effects etc. (2) it means the core
> developers know what other people are likely or not to do, and so can
> steer usage.
We don't use it, but there is a way:
package Maypole::Model::CDBI::Plain;
Maypole::Config->mk_accessors(qw(table_to_class));
>
> ok_tables
> ---------
> the description is clearly incomplete but I have no idea when this
> method is supposed to be used, so I can't complete the description.
This is a hash representation of display_tables(), used as cache.
sebastian
_______________________________________________
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:56 GMT