On 9/30/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> Peter Speltz wrote:
>
> >>>To me it makes sense to have it in Maypole.pm because it is what
> >>>defines an "action".
> >
> > By this I mean Maypole has a precise definition of an "action" -- an
> > exported sub or a sub that passes the is_public test. Since maypole
> > defines this, it seems it would also define the helper method to
> > determine what the actions are.
>
> Ah, now I understand what you mean. Thanks for persisting. In that case,
> I'd think it ought to be a method on Maypole::Model::Base.
I just realized the "is_public" sub is in the model class. I was
thinking it was in Maypole.pm. Why not put in in M:;Model::Base ?
Compile issues? Other people thought plugin over Maypole.pm but what
about Plugin over Model:;Base?
> But since
> there's no built-in way to call class methods on the model from a
> template, and we don't have a plugin interface for the model ...
>
I make bless a model object in additional data and put it in
template args. Really it may be better to have a slot right in r for
it : $r->model_obj
$r->model_obj ( bless ({}, $r->model_class) );
problem solved. you can always call methods of the model_class form TT
templates. Simon said this is what Template:;Plugin:;Class is for .
It wouks ok but not great and to me is more work so i quit using it.
> ... and since the other suggestions were for a plugin ... I think I feel
> one coming on. model_actions seems like a good name for the method, so
> you won't need to change that.
>
To me (Maypole user's perspective /Maypole app mainainer perspective
) general helper methods not used by Maypole but that most/many users
will like *should* go in the core. I'm just not a big fan of plugins
for general utility stuff anyone may want at a given time. Also,
People can overrinde built in utility methods just as easy as plugging
them in if they do not like them. I think a good framework is one
that says ;
" You are making a $CDBI , $TT app around a database ? We will make
it as easy as possible for you to get the job done. "
Maintaining that "easy as posiible" is a balancing an act. Every
little thing adds up to tip that scale one way or another. The cons
should clearly outweigh the pros before you tip it toward less than
easy. ( I dont know enough to conclude one way or another in this
case. ) Making model_actions a plugin rather than in the Model:;Base
tips it a little more toward less than easy. In and of its self it
makes not much difference but it is another thing that adds up for the
end user.
Eventually the user is repeating the same tasks in every app and
keeping up with updates of Maypole and 20 plugins (exagerrated) . And
to write a plugin they need another plugin because the general
functionality is not in the core.
For me not having a model_actions sub and a model_obj complicates my
app more than necessary. There are probably 10 other little things
like this that maypole or a maypole model class could take care of
that it does not. Lets see, Redirect (that is in the works) , column
info from the db .. . I'm probably being nit picky here and
exageratting the downside . . . However, I may not. I can't tell
right now. I bet new users do not think I am.
thanks for hearing me rant . . .
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users
