--- Tony Bowden <tony-maypole at kasei.com> wrote:
> On Wed, Dec 29, 2004 at 09:57:06AM -0800, Peter Speltz wrote:
> > But for the life of me, WHY UNIVERSAL::moniker ???
>
> Because that's what UNIVERSAL::moniker is for doing.
>
It's for returning nicknames of Classes to be used between '/' in URLS and as
directory names ? :)
> > By using that you take the
> > Universe out of it and effectively make it "UglyMaypoleInternal::moniker".
>
> How so?
>
I'm speculating here that it is feasible that some classes somewhere and at
some time in the universe have monikers that aren't fit to be directory names
or parts of URLs. More generally, that it could be used to return any string in
the universe. So limiting it in Maypole you take the universe out of it for
Maypole apps.
If this were necessary, i'd have no problem with it but it seems completely
unnecessary.
> > becomes useless for human consumption and something solely for computer
> > consumption
>
> How so?
>
Only in the maypole, app of course. Example: a human would call a
Football_Player class a "football player". But a computer can't call it that
when using it in a URL" or as a directory. . I'm pretty sure
http://localhost/football player/addnew" isn't a valid url. If it is i can come
up with another example.
> > It contradicts the Universe::moniker doc.
>
> How so?
>
As the docs say what a human likes to read and write are not always what a
computer can use. Or another way, what a computer likes to call things are not
always what a human like to call them.
> > It means all the templates have to be changed.
>
> I thought they needed to be changed anyway? And even then there's only a
> visible difference in the small number of cases where the moniker and
> table name disagree.
>
Only the parts where moniker is used in the path would need to be changed and
not the parts where moniker is used to make pretty class monikers for humans.
This is really only relevant if people use moniker to to make pretty display
for humans (which i like the idea of doing).
> > It means you really don't want to override it if you can help it.
>
> There should be no ill effects of doing so. When moniker guesses
> incorrectly you probably want to override it anyway.
>
Example: big maypole app. you decide to change a moniker or two.
You'd have to move templates for the classes to new directories and change link
urls all throughout the app.
> > A more appropriate method would be Maypole::Model::Base::maypole_moniker.
> This
> > would effect fewer changes on Maypole (docs, templates, internals alike)
> and be
> > more intutive to users trying to figure out their URLS and Directories.
>
> By all means there should be a method in Maypole like this. It's always good
> practice to have an insulating layer around 3rd party modules.
Thank you. That's all i'm saying. maypole_moniker would be something one would
override just once in a custom model base class. Then the URLS are
predictable. Then Existing model monikers are not of any concern. People
coming to maypole with CDBI or other model classes already don't have to change
any monikers to conform. If a new CDBI feature requires a tweak in a moniker
then will it be compatible with Maypole?
The possibilities are pretty limitless on how people use moniker in their
classes and maypole shouldn't restrict it when it doesn't have to.
> are you expecting this method to do by default Call $self->moniker? Or
> something else?
>
Gosh No. (I almost said yes :) ) That would have exactly same effect as just
using moniker. It would have to return Universal::moniker($class) I believe or
just cut and paste code from Universal moniker.
> Tony
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
>
=====
pjs
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
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