> > Problem
> > -------
> > In a system with lots of nested templates or template overrides the
> > amount of variables that need to be forwarded to each template may grow
> > out of proportion.
>
> Didn't we "invent" this mechanism exactly to make the available
> variables more user visible? And wouldn't all the solutions bypass this
> explicit declarations, no matter which of the options you choose?
>
> I personally don't really like to change this.
Yes, we used this mechanism to make variables more visible. When we are
sending too many variables the templates becomes hard to read. I don't like
the change either, but in certain cases this change makes the templates more
readable.
> This reminds me of some email I sent earlier about the send_array
> construct to pass larger amounts of variales where we concluded that
> this would make available variables less visible, so we should propose
> another mechanism. The "solution" back then was, to include the sub
> template from your application and return the result to the main
> template which may echo it anywhere using {raw}.
Yes, I remember that case. That solution is still valid. The problem we have
now, is that we have lots of templates that include other templates. There is
AFAIK not a solution like that possible. See for example the admin templates
from eZ publish.
> I see the problem with big applications where a lot of data is required
> to pass, but imho there are also some solutions beside passing the
> complete local scope at all:
>
> 1) Use Structs / Objects
>
> You may combine lots of information in some structs or objects
> representing logical objects in your application, and pass nothing more
> but them, like a $request-Struct containing all request information.
>
> You are probably already dooing this, but the logical seperations still
> result in too many variables?
Something like?:
{use $send}
{$send->a}
{$send->b}
And $send is a default object send to each Template?
> 2) Use custom template functions
>
> For most data an application needs to populate to its templates we
> probably could just use custom template functions, which give access to
> certain scopes of data.
Something like?:
{var $send = sendVariables()}
{$send->a}
{$send->b}
>
> I don't know how easy it is for now to embed this somehow statically, so
> that it is cached in an optimal way - you know more about this ;).
> Requiring static cache blocks everywhere won't be nice, so maybe it
> could be possible to define that a function returns "static" data in the
> template function definition and then include this data statically in
> the template?
Could be a built-in function, maybe.
Thanks! I like the suggestions.
Cheers, Raymond.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
