On 05.01.2010, at 12:00, Michal wrote:
On Tue, Jan 5, 2010 at 10:28 AM, Felix Gilcher <[email protected]> wrote:Request attributes are global while template variables (which are in fact ExecutionContainer attributes) are local to that container execution. A request attribute set in in slot will be available to all slots that execute later and to all templates that are rendered later while a template variable set in a slot will only be available in that template. In general, use template variables since that protects you from naming collisions.Ah: thanks for this clarification.It is possible to use request attributes to handle javascript/css inclusions, however, there are a few things to look out in combination with caching. The general recommendation is to use response attributes from 1.1 on.Can I ask what the things to look out for are?
The main problem is that request attributes represent global state that is mutated by the action and the slots in question. Now if you cache a slot that also adds some javascript to this request attribute... you'll have to cache that request attribute as well, right? However, if that slot is used by another action as well, then when the cache for that slot is read, it restores the request attributes from the earlier run, where other slots had already set some javascript nto this request attribute, and boom, you get the wrong stuff in your output. Working around that with namespaces is extremely cumbersome; that's why as of 1.1, there are response attributes that are automatically cached and and merged properly (see http://trac.agavi.org/ticket/1062 for more details).
- David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
