cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Thu, 02 Dec 2004 20:54:09 GMT
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.

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.

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

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

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.

                            --- 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.

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

                            --- o0o ---

Now over to commenting what you have written.

> 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>

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. 
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.

If I would like to do everything in one step as you suggest above it 
might look more like:

          SELECT name,description FROM projects WHERE 
projectleader=${}ORDER BY name
            <a href="projects?name=${$}"/>${$}</a> - 

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.

> 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?

> 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.

> 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.


View raw message