[Solar-talk] controller helpers, maybe?

[Rodrigo Moraes]

Hi,
I'm happy that you liked the idea; it was all the time in front of us. :)

2007/7/9, Andreas Ravnestad:
> Just a quick note about vocabulary - to me, the word "plugin" means
> something rather abstract, undefined, and very high-level that
> externally modifies default behaviour or provides something completely
> new (maybe like support for components.. :) ). I don't think I'd feel
> comfortabuls with calling this concept "plugins" since they typically
> won't really do all that much. This is based on my assumption that
> controller helpers will be pretty similar to view helpers in how they
> work and what they are intended for.

I have the same feeling: I see "plugins" as things that are plugged
externally, like using observers. I understand the idea to use a
distinct vocabulary, but I'd still prefer "helper" instead of
"plugin".

Maybe we can come up with a name which is different enough from
"Helper" but still resembles to the same meaning? If they will work
pretty much like view helpers, _ActionHelper would perhaps
differentiate them a bit? Anyway, it's no big deal and I'd be happy if
they were called "plugins". I'd just prefer something else...

> Further, as Rodrigo and I discussed (on irc as usual), it would be very
> practical to have these controller helpers available in associated views
> as well. In that case, it would make sense to distinguish them as
> "controller/action helpers", and "view helpers".
> Well, it would to me, anyways :)

I haven't considered this mix very well; only had some thoughts on irc
when you mentioned the idea. It seems dangerous, doesn't it? Although
I have ideas for helpers that could be used by both controllers or
views... more on this below.

> As for visibility,what is the rationale for protected access? (now I'm
> playing the devils advocate;)

Same question here; I'd like to use isProcess(), for example, from
outside - in "plugins" (I mean, observers). The same is valid for
other functionalities like redirect() etc - I think that observers
could use them sometimes.

Also, if controller helpers were visible, I could use them in view
helpers. Example: assembling uri's from routes is necessary in both
controller and view templates. I would setup a controller helper to do
this and then just wrap it in a view helper, e.g. call the controller
helper using Solar::registry('app')->routeUri($params) (where 'app' is
the registered page controller).

Perhaps not a good example but... I really haven't considered how bad
could it be to mix view and action helpers directly, so this kind of
"bridge" seems to be a quick and fine solution. Honestly, I'd avoid
mixing both other than using strategies like this.

I'm also tempted to suggest that some things should be visible to
controller helpers, like $_request and $_response and $_info, because
they would have a lot of use there.

-- rodrigo