cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RFC] "Cocoon Templates": Name and Tag Interface
Date Mon, 29 Nov 2004 21:00:40 GMT
Jonas Ekstedt wrote:
> On Mon, 2004-11-29 at 08:33 -0800, Ralph Goers wrote:
> snip...
>>>This is somewhat OT in the current context but IMO expressions, (the
>>>stuff inside ${}), should only have access to FOM and preferably just
>>>read access. IMHO expressions should not have side effects.
>>There should be a way to register objects for use by the template so that
>>flow is not a requirement.  Of course, the template should also be able to
>>access the request and response.
> How about allowing a "context-populator" parameter to the template
> generator. As an example, suppose we want to populate the context with a
> query from a db. 
> In sitemap:
> <map:generate type="template" src="showQuery">
>   <map:parameter name="context-populator" src="com.MyPopulator"/>
> </map:generate>
> The populator:
> package com;
> public class MyPopulator implements Populator {
>   public static Context getContext(ServiceManager manager, 
>                                    Map objectModel) {
>     Context context = new DefaultContext();    
>     context.put("myQuery", selectFromDB(manager, "select * from ...");
>     return context;
>   }
> }
Good idea, but I would go even further:

interface TagPopulator {
   static Tag getTag(Class tagClass,
                     ServiceManager manager,
                     Map objectModel,

And maybe more methods if we will do part of the setup at compile time 
and part of it at execution time. This way we have more flexibility in 
experimenting with different initialization strategies like setter 
injection etc. One could possibly also write adapters for foreign 
taglibs this way.

> One could even have population implemented as a flow function:
> <map:generate type="template" src="showQuery">
>   <map:parameter name="context-populator" flow="getMyContext"/>
> </map:generate>
> function getMyContext(manager, objectModel) {
>   return {var: "value1", var2: "value2"};
> }

Something like that can be done with flowscript:

function getMyContext1() {
   SendPage("showQuery.jx", {var1: "value1", var2: "value2"});

I know that it is rather clumsy, but instead of solving that with a 
template specific solution like the one you propose, I would prefer to 
be able to write something like:

<map:call function="getMyContext"/>
<map:generate type="template" src="showQuery"/>

It actually was allowed by mistake until about one year ago, when it was 
removed as the meaning of it is unclear when web continuations or 
redirections are used within the flowscript. If we refactor the 
flowscript implementation so that the possibilty to use web 
continuations and redirection can be turned off, it would be safe to 
allow the above construction again.

But that will be after we have finished the template (and convertor and 
some form ;) ) work as far as I am concerned.


View raw message