--- Dave Howorth <dhoworth at mrc-lmb.cam.ac.uk> wrote:
> Peter Speltz wrote:
> > This is cool Dave.
>
> Thanks!
>
> > It got me thinking Maybe a Maypole::Plugin::Menu would be feasible.
>
> Sounds a good idea.
>
> > -- A way to distinguish object actions and class actions.
>
> AFAIK, the only way in general to tell is to read the code, so this
> would have to be indicated explicitly, perhaps by an extra attribute.
>
The attributes package is pretty cool and would work nicely I think. But what
attributes do we need? Class or Object seems essential. What about an attr to
declare whether it should show up on the menu? Or maybe if you declare it as
Object or Class it means you want it on the menu?
sub edit : Exported : Object { . . . }
sub list : Exported : Class { . . . }
With this Maypole::Plugin::Menu could automatically make URLS like :
/beerdb/view/21
> > -- A way for model to customize and add additional actions from other
> > model classes to their menus
> I think it would be very useful to have a general way to plug in
> additional functionality to models (rather than the list of use this;
> use that; that you see at the start of Maypole::Model::CDBI). I think
> Sebastian has added code to Class::DBI::Loader to help with this and I
> think Simon's considering the best way to handle it in Maypole.
>
I think I wasn't thinking that deeply. IN my prototype of this Plugin, model
classes customize their menus by simply making action links for whatever
Classes and Actions they want and putting them in template args.
Some background info: Originally, I was thinking a method like $r->menu would
return a hashref of HTML::Element links for all the actions in the model_class.
However maybe just the URL, and a human readable action name would be
sufficient and the templates can DWTW.
NOW all the work from $r->menu is done in an "action_links" sub. the
action_links by default just uses $r->model_class and $r->model_class->actions
(you're actions sub) to make links. However it can optionally take a
model_class and a list of actions plus additional query params. This way it can
make any combination of Class/Action links.
Example: Assume a Beer has a brewery_id. You go to the "brewery/view/1" page.
Then in Brewery::view you can say:
sub view : Exported : Object { # Object has nothing to do with this example
. . .
my $brewery = $r->objects->[0];
my $links = $r->action_links(model_class => 'Beer', actions => [
'create_new', 'list'], brewery_id => $brewery->id);
# This would return links with URL's:
#/beerdb/beer/create_new/?brewery_id=1 # create new beer at that brewery
#/beerdb/beer/list/?brewery_id=1 # list all beers at that brewery
# obviously the list and create_new subs are custom (but not very).
# add menu to template
$r->template_args->{menu_items} = $r->menu; # all brewery actions
$r->template_args->{additional_menu_items} = $links;
# perhaps merge hashes somehow. Easy in TT but not in perl
# that i've found.
}
That's how my prototype allows model classes to customize there menus. What do
you think?
> > -- A "action_names" sub to specify what to call these
>
> I'd suggest an alternative here. The names you want are text strings for
> display, so IMHO they should NOT be generated in code. They should be
> generated by web-designers, marketroids or localisers. The actions
> themselves have valid identifiers so the simplest scheme is just to
> write an action_names.tt and PROCESS that:
>
> [%- action_names = {
> view = 'View Item'
> register = 'Register for a Subscription'
> etc = 'Whatever You Want'
> }
> -%]
>
> Or maybe use the magical 'global' template variable.
> [% global.action_names = { ...} %]
>
> Hmm, now if I generalize that argument, do I believe that column and
> table display names should be generated the same way? I wonder. I'll
> think about that for a bit but there could be another revision of my
> loader-generator on the way!
>
Exactly my reasoning. Consistency is crucial. However i was deluded about how
column_names is used. It's used in FOR loops in templates but Template authors
don't have to use them. Similaryly "action_names" could be used just to give a
starting point. Also, as I said above, I was wanting to generate html::element
links and needed content between <a> </a> . I used "action_names" for that.
However, i think just making $r->menu return a hash of
{ url =>
action_name =>
action =>
}
rather than HTML::Element links made from that data may be a better approach.
Then menu template can make links or whatever it wants. However I also like the
HTML::Element approach cause it is efficient in that you don't look up data
again to make links when you wanted them all along in the first place (when the
data was generated). follow me? Maybe an option to think about.
thanks.
=====
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