Re: [SM-DEVEL] [SM-CVS] CVS: squirrelmail ChangeLog,1.763,1.764

[Steve B. <sbr...@gm...>]

> I can agree with that.  Problem is that other templates might have
> 4-column tables... so the plugin has to change based on the
> template... if that's OK, what is worse is that the core also needs to
> do the same thing, which is ass-backwards in terms of architecture.  I
> will change the core to send TWO variables, one ONLY for plugin data.

I guess this will be the first in a *long* line of template + plugin
discussions. :-)

Paul, what kind of stuff do the plugins spit out on the login page?  I
agree that the plugins should not have to be aware of conditions in
the UI, e.g. templates.  I've been throwing some ideas against the
wall to see what sticks.  In the cases of lists, e.g. the options
page, maybe the login page, the plugins should be able to modify a
data structure (like an array) that is then passed to the template.
The template author can than do what he wants with the data structure.

Another idea I had was to buffer the output from the templates, return
it from the hook call then pass the output to the template for output
later.  This seems to work well in certain instances, e.g.
compose.php.  It might work well in other places also.

Maintaining as much functionality as possible with plugins is going to
be one of the most difficult things about templating since the plugin
engine is so flexible right now.  In other words, you can accomplish
the same thing, including output, from almost any hook.  This is going
to be a painful process, but it needs to be done.

Steve