cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Thu, 02 Dec 2004 21:47:01 GMT
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
> 
> Let me re-iterate: there have for a long time been a concesus at the 
> list among those who have cared enough to discuss it that JXTG is a well 
> working way of creating views, but that the implementation is very hard 
> to maintain.

Fair enough. A template language has nothing to do with taglibs, per se.

> There has also been an agreement about that ESQL is the only reason 
> (besides back compability) to care about XSP, you said so youself a week 
> ago or so.

After using it for a little while, I changed my mind. :-)

> For those of us who use CForms it is very convenient to be able to use 
> the template tags together with JXTG constructs.

I believe the best template system does not use tags at all. It either 
uses content (as in velocity) or it uses attributes (as in tapestry).

> So we need a template generator with three sets of tags "jx:", "esql:" 
> and "ft:" thats it.

I disagree, we don't need a set of tags *AT ALL*.

> We also discused how to use a separate conversion layer to remove the 
> need for formating constructs from the template layer.
> 
>                            --- o0o ---
> 
> Given these general requirements that have been discussed again and 
> again at the list and also some more technical, performance driven 
> requirments, I steped forward and proposed a possible way of 
> implementing it. This design is based on a rather far going SoC in the 
> interest of keeping it maintainable. We have also identified a number of 
> templateing components that are needed in other places in Cocoon. E.g. 
> expression language and object model and therefore are worth 
> implementing as separate components. I also proposed implementing the 
> three sets of tags discussed above as taglibs instead of making their 
> interpretation being part of a huge monolitic SAX event handler as in 
> JXTG. Implementing it that way it is must easier to write test code for 
> the tags and generally easier to understand what is going on.

Very well, you just picked the wrong name: a refactoring of common 
services into reusable components has nothing to do with enforcing the 
use of tags into a template language.

But more on this later.

>                            --- o0o ---
> 
> Given this background, I was quite suprised when Miles Elam whent 
> ballistic about that I mentioned the word taglib and draw conclsions 
> about my intensions that are far and in several cases oposite from what 
> I feel and have written anything about.

keep reading and you might understand why.

> Anyway, if you have better suggestions about how to solve the above 
> requirements I'm all ears.

Here I am.

>                            --- o0o ---
> 
> Now over to commenting what you have written.

Bring it on :-)

>> So, my other side thinks that having a scripted controller invoquing 
>> different templated views is a better solution.
>>
>> In this case, do we need taglibs at all? no we don't. 
>> <esql:query>select * from blah</esql:query> sounds easy enough, but in

>> real life it's more something like
>>
>>      <esql:connection>
>>       <esql:pool>gump</esql:pool>
>>        <esql:execute-query>
>>          <esql:query>
>>            SELECT name,description FROM projects ORDER BY name
>>          </esql:query>
>>          <esql:results>
>>            <esql:row-results>
>>             <li>
>>              <a><xsp:attribute 
>> name="href">projects?name=<esql:get-string 
>> column="name"/></xsp:attribute><esql:get-string column="name"/></a>
- 
>> <esql:get-string column="description"/>
>>             </li>
>>            </esql:row-results>
>>          </esql:results>
>>        </esql:execute-query>
>>       </esql:connection>
>>
>> and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
> 
> In the general case I would rather write just the query with some 
> surrounding tags like in the SQLTransformer, get a simple standardized 
> XML serialization of the row set and then transform it to HTML in XSLT.

That works only for trivial monolythic cases. For any serious reporting 
application (for example, where order is parameter dependable) that 
doesn't work.

> The only difference compared to the SQLTransformer would be that I can 
> combine it with JXTG constructions and insert query params in a 
> convinient way.

This is exactly the point that makes me say "just say no to taglibs" 
because, as I explained before, no matter what syntax, putting query 
parameters in a SQL string is not something that should be in a template!

> If I would like to do everything in one step as you suggest above it 
> might look more like:
> 
>    <esql:connection>
>     <esql:pool>gump</esql:pool>
>      <esql:execute-query>
>        <esql:query>
>          SELECT name,description FROM projects WHERE 
> projectleader=${cocoon.request-param.id}ORDER BY name
>        </esql:query>
>        <esql:results>
>          <esql:row-results>
>           <li>
>            <a href="projects?name=${$row.name}"/>${$row.name}</a> - 
> ${$row.description}
>           </li>
>          </esql:row-results>
>        </esql:results>
>      </esql:execute-query>
>    </esql:connection>
> 
> As we are using the same kind of expression template mechanisms as in 
> JXTG. We could probably make the syntax more efficient and take away 
> some of the tag layers if we feel like that.

Sure, that's a better syntax, but the fundamental problem remains: 
template designers don't know nothing about SQL, nor care, nor know 
anything about request parameters, not know anything about dynamic tags 
nor know how to debug something in case somebody screws up with the 
order of those tags!

let me rewrite the above:

controller.script:

   var query = "SELECT name,description " +
               "FROM projects " +
               "WHERE project= " + request.id +
               "ORDER BY name ";
   var results = cocoon.datasources.gump.execute(query);
   request.context.set("projects",results);

view.template (content style):

   <ul>
    #foreach project in projects
    <li><a href="projects?name=${project.name}">${project.name}</a> - 
${project.description}</li>
    #end
   </ul>

or view.template (attribute style):

   <ul x:foreach="project in projects">
    <li><a href="projects?name=${project.name}">${project.name}</a> - 
${project.description}</li>
   </ul>

note how SoC also allows you to use a different technology (example, O/R 
or straight OODBMS or even RDF triple stores!) to populate the beans 
without the template designers know anything about this!

>> What I want is something like this:
>>
>>  - request comes
>>  - sitemap gets it
>>  - matcher matches
>>  - controller is executed and populates beans in the request context
>>  - pipeline is invoqued with access to the request context
>>  - response goes
>>
>> Now, this can happen right now in flow and JXtemplate. If we don't 
>> need state management, this is just like having a better action model 
>> with XSP-like code recompilation.
> 
> Sure, I agree with all that. Only question is: where do I put my SQL 
> queries in the above scenario?

this is the whole stinking point: *never* in the template!

>> But the whole point of this discussion is: do we need taglibs?
>>
>> I'm sorry, but I agree with Miles, we don't: all we need is a 
>> velocity/garbage-like template system and recompilable java controllers.
> 
> If you by this mean that you don't see any need in writing special 
> purpose taglibs as a typical part of normal webapp development, I 
> couldn't agree more.

No, not only that: I think that the person responsible for doing writing 
the logic that drives the flow *and* the content population of the page 
is *NOT* the same person that does the design of the template.

Taglibs force template designers to do the job of content population or 
force two different people to work on the same file.

In both cases, they are suboptimal from what I wrote above, where 
content population and content presentation are kept completely isolated 
and the only contract between the two is:

  1) the shape of the objects in the context
  2) how to perform simple variable espansion, list iteration and 
conditioning.

#2 is the only thing that should be exposed to a template language (just 
like velocity does), everything else should be dealt with at the view 
population level. Which is going to be code, written by coders and 
people that deal a lot better with code than with anything else.

>> Everything else is making a step backwards.
> 
> As said above my only purpose with introducing taglibs is to increase 
> maintainability and the ability to test things. Take a look at the 
> Cocoon code base. Tons of code that hide what it does beyond all this 
> SAX event handling code. If we could refactor away some of that 
> intermingling, we would IMO make a step forward.

You keep mixing concerns.

One concern is to come up with a unified template language. This implies:

  1) understanding the features we want (and we don't want!) from a 
template language
  2) come up with a syntax
  3) implement it

Another and completely separate concern is how to factor out existing 
bits so that #3 is easier.

You are attacking #3 before attacking #1 and #2 and that's why everybody 
here is feeling frustration: there is no consensus on #1 and #2 so 
attacking #3 now is more harmful than useful.

-- 
Stefano.


Mime
View raw message