On Wednesday 29 August 2007, Kore Nordmann wrote:
> On Wed, 2007-08-29 at 12:05 +0200, Raymond Bosman wrote:
> > Hi all,
> >
> > This mail describes a problem we currently have with ezcTemplate and it
> > provides some solutions. Feedback is highly appreciated.
> >
> >
> > 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.
>
> 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}.
I completely agree. This is a problem with way the application is built.
Imagine you have the same problem in programming with lots of functions that
call each other in succession. Do you pass variables along in the same way?
No, it becomes messy.. you can then either group them somehow, make global
variables or you make some other means to get the info (e.g through other
methods).
>
> 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?
This seems like a good way to do things to me.
> 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.
>
> 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?
Yep, this is another way but is much harder to implement for the application.
Cheers,
Frederik
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
