--- Rolf Schaufelberger <rs at plusw.de> wrote:
> >
> Yes, concerning the language setting you are right with the session, this
> would be the next problem, since M::P::A::U creates a session only when an
> authentication takes place, yet I need the language selection also in my
> "public" part of the website, so I must simulate a login here or create a
> session outside the Authetication (and reuse it there).
User::set_lang() could still be used here but the user is anonymous. Just store
the language setting in the session like : $r->{session}{lang} rather than in
user like $r->{session}{user}{lang}.
> But the general question with non-model related actions is still there, and
> Peters solution with a dummy table may be a solution, but it's just not
> "clean" (don't know how to express is in english, I mean it's a workaround an
> > no proper conceptual solution).
> I 've thought about a solution like starting the table part in the URL with
> an underscore like <base>/_settings/setLang?lang=en and handler_guts calls
> Settings::setlang without checking for table existance. But this is more ore
> less the same than Peters solution.
>
Technically the fact that maypole uses an actually table name in the url to map
to a class is supposed to change. See maypole.perl.org roadmap. It will change
to something more related to the Class because a single table could be the base
of several different classes. There was way to long a discussion on this in a
thread a few weeks ago called something like "Why does maypole use moniker to
determine template directories".
Anyway, when this happens the table part of the url won't really be a table
part but a class part. So my solution won't be unclean then. Now, i don't
really see it as unclean because it is perfectly ok to override the class_of
method. Also, the name "table" given to the part of the URL to determine the
class is completely arbitrary and not a very fitting name it turns out unless
you are limited to all classes having a distinct table. With that in mind a
better name would be "class_hint" or just "class" since all it is used for
anyway is to get the class that you want to call your action with.
At any rate making model classes to put general cgi scripts in may not be the
best idea but it is something maypole should support and does support all beit
you have to override the class_of method. Afterall, Maypole just maps a url to
a class method call with args. Why should it matter whether the class is
associated with a table in a database or not?
Perhaps another solution may be to put general actions in the base model class?
My base model class could be My::Global.pm so a url
"<base>/global/set_en?lang=en" wouldn't be so bad.
> Greetings Rolf
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
>
=====
pjs
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
_______________________________________________
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