On Thursday 30 August 2007, Raymond Bosman wrote:
> Hi,
>
> I added the solutions mentioned in the previous mails to the proposal. Here
> are the new solutions and a new evaluation. Please, check if it is correct.
>
> The "context" proposal is not included. Frederik or Kore can you give me an
> example? Please, keep in mind that the word "context" may be confusing
> because we use that to set the target output to: HTML or text.
>
> Attached is the proposal.
>
> =====
>
>
>
> 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.
>
> 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 and hence you have no way to look for template variables
documentation.
- 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.
>
>
> 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
>
> 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?
> - 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?
Cheers,
Frederik
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
