> > Solution 6: Struct like variable passed on
> > ------------------------------------------
> > The variables send to the first template can be packed in one structure.
> > For example the user application sends:
> >
> > $t = new ezcTemplate();
> > $t->send->structure = new ezcTemplateVariableCollection();
> > $t->send->structure->a = 1;
> > $t->send->structure->b = 2;
> > $t->process("p");
> >
> > Template p and q are:
> >
> > Template p:
> > {use $structure}
> > {include "q" send $structure}
> >
> >
> > Template q:
> > {use $structure}
> > {$structure->a}
> > {$structure->b}
> >
> >
> >
> >
> > Solution 7: Provide a variable with all send variables
> > ------------------------------------------------------
> > Almost the same as solution 6, but a struct like variable with all 'send'
> > variables is provided by default.
> >
> > User application:
> > $t = new ezcTemplate();
> > $t->send->a = 1;
> > $t->send->b = 2;
> > $t->process("p");
> >
> >
> > Template p:
> > {use $send, $a}
> > {$a}
> > {include "q" send $send}
> >
> >
> > Template q:
> > {use $send}
> > {$send->a}
> > {$send->b}
> >
> >
> > It can also be that the $send variable is always available for all
> > templates. The templates would be:
> >
> > Template p:
> > {use $a}
> > {$a}
> > {include "q"}
> >
> >
> > Template q:
> > {use $send}
> > {$send->a}
> > {$send->b}
>
> This solution is not as good as the struct solution (6) as with the struct
> you will have to define a class in your program that actually have these
> values set. This class can (should) be documented. In case of solution 7
> there is no good way to document what is actually sent to a template. In
> the current implementation this documentation is forced by the use of
> {use}. The same is true for solution 8.
Solution 7 and 8 send an ezcTemplateVariableCollection which is made available
implicitly by the template engine. So in theory solution 6, 7 and 8 work in a
simular way. If documentation is needed for the sending variables and it
needs to be in the class documentation, then I agree and solution 6 is better
in that case.
Another good feature about solution 6 against solution 7 and 8 is that the
variables are accessible only in one way. E.g:
Solution 7 and 8:
{send $x, $send}
{$send->x} == {$x}
> > Evaluation
> > ----------
> > Many solutions share the same concept. Therefor we categorized the
> > solutions in three groups:
> >
> > - Group 1: Solution 1, 2 and 3.
> > - Group 2: Solution 4 and 5.
> > - Group 3: Solution 6, 7 and 8.
> >
> >
> > Group 1 changes the behavior of the {include} statement. The changed
> > behavior results that the original send variables are passed along
> > without specifying those variables explicitly.
> >
> > Group 2 adds a keyword to the included template so that more variables
> > are available.
> >
> > Group 3 packs all the original send variables in a group (object).
> >
> >
> > Advantages and disadvantages for group 1:
> >
> > + Easy to write a (single) template. No knowledge is needed where
> > variables are made available. {use} specifies only which variables are
> > used inside the template.
> >
> > + Easy to change in the template code.
> >
> > + Easy to see which variables are used in the template (and are declared
> > externally).
> >
> > - Once a template is written, it may be difficult to 'backtrack' a
> > variable to it's declaration. Keep in mind that when 'template overrides'
> > are used, this task is difficult without extra runtime information.
>
> Yes, the point here is that you have now removed the "entry" point for
> template variables
There is still an entry point like:
{use $prevTemplate, $topScope1, $topScope2}
> and hence you have no way to look for template variables
> documentation.
Documentation could be written in the template or at the point that template
variables are sent.
> - you can easily end up with lots of templates where new variables "pop up"
> everywhere. This is exactly the situation we have in ez publish today that
> is so confusing and that we want to avoid.
Not really "pop up", because every variable is still declared in the {use}. In
a structure with a bunch of unrelated variables the chance is much bigger
that suddenly new variable pops up.
> > Advantages and disadvantages for group 2:
> >
> > + Easy to see if a variable comes from the user application or from the
> > calling template.
> >
> > + Easy to see which variables are used in the template (and are declared
> > externally).
> >
> > - Makes templates less generic. Multi-purpose templates may be called
> > from anywhere.
> >
> > - May be harder to write the template when it's unknown where previous
> > templates declare their variables.
> >
> > - It is not possible to specify a variable that comes from the user
> > application unless it's (modified and) sent by the previous template.
> > (Making this work would undo the 'easy backtracking' advantage.)
>
> - Same documentation and confusion issues as group 1
Same answers as group 1 ;).
> > Advantages and disadvantages for group 3:
> >
> > + Some variants are possible to implement without changing the template
> > engine or are already available. Send-use structure is the same.
> >
> > + Easy to see if a variable comes from the user application or from the
> > calling template.
> >
> > - Hard to see which variables are actually used. (The group is only
> > available in the {use} block.)
>
> True, this is far less inconvenient than not knowing what you actually
> _can_ use though IMHO.
>
> > Also checking if a variable is set, has to
> > be done manually.
>
> Yes, that is annoying.
>
> > - Extra code in the templates itself is needed to retrieve a variable
> > from the top scope.
>
> This one I don't get. Can you give an example?
{use $sendVars}
{$sendVars->x}
is longer than:
{use $x}
{$x}
> > - Makes templates less generic. Multi-purpose templates may be called
> > from anywhere.
>
> Yes, but how multipurpose is the system when all the templates rely on
> specific variables to be set for one of the templates included somewhere in
> the chain of templates. How is the programmer supposed to know which
> variables must be supplied to a template when he chooses to use it from a
> PHP file?
You got a very good point here. I've to think about this ..
Raymond.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
