cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Fri, 03 Dec 2004 14:13:06 GMT
Stefano Mazzocchi wrote:

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

Ok

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

In our previous discussion at the list our conclusion was that JXTG is 
ok and that although there might be slightly "better" approaches or 
ideas in one way or another, the general feeling was that it would be 
better to evolve from JXTG than to do something completely different. We 
must protect our users investments in Cocoon technology. Of course we 
should do new and revolutionary stuff when we find a much better way of 
doing things. But that something is slightly better is not a good enough 
reason, IMO.

Having said that, I'm happy to keep the template framework open enough 
to make it possible to plug in an attribute driven approach or parsers 
for content driven approaches. It should be quite easy to do that AFAIK. 
Now, these are no itches that I have, but if you or some one else come 
upp with a design proposal for such a template language, I can take part 
in adapting the framework for it.

<snip/>

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

I assumed the context of the having both SQL and JX tags in the 
generator step, then you can do serious reporting. I even happen to know 
that, as I and my coleagues have done serious repporting in numerous 
applications for a number of years in that way.

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

Ok, I start to realize that you assume that I suggest that everything 
should be done in the template step. No I don't, I do what you refer to 
as the controler concern, i.e. put together and execute the SQL query 
based on request params in the template. All view related stuff is done 
in the next step, typically XSLT.

<snip/>

> 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.
>>
Concerning SoC I agree completely, It is a good idea to separate the 
query composition and execution from the result set rendering, I have 
always done it that way and have never recomended anyone to mix them.

Concerning writing code for query composition and execution in an action 
variant of flowscript I also agree :), I think that its better than 
doing it in a generator step.

So why are we not allready doing that? Booth allow the use of 
flowscripts as actions (after having inactivated web continuations) and 
providing DB functions for flowscripts have been discussed a number of 
times at the list. And every time a number of committers (you included), 
have explained (for both of the ideas) that: its not needed, its mix of 
concern and it is generally bad practice.

If you succeed in convincing the community that (flow)script actions and 
flowscript support for DB is ok, and should be our "official 
recomendation" for db reporting stuff, I have no need for SQL-tags 
anymore. Until that happens they fill a clear need.

<snip/>

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

Let me tell a story from real life. I and some others have worked hard 
on enforcing SoC, enterprise design patterns and generally layered 
designs in all our projects. That have been excelent for ensuring the 
success for larger project. But a less excelent side effect is that a 
number of people who was quite productive in small projects using php 
and the like have become very frustrated over the, in their view, overly 
abstract way of doing things. And a few of them even hate Cocoon based 
on that.

My conclusion from this is that its counter productive and destructive 
to force people to follow your own rigid idea about the "ideal" SoC. Do 
simple things in simple ways. If the project grows, introduce the needed 
design and refactor.

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

We also need recursive application of named templates, othewise you 
cannot render menu trees, folders and the like.

<snip/>

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

We went over #1 and #2 a number of times at the list, and the design 
this far is based on the results of these discussions, and every design 
issue has been repported at the list and in some cases discussed. Please 
resarch the archives, if you doubt it.

When you wrote the letter that I'm responding to, you and Miles where 
the only ones that had expressed any frustration at all. Now everybody 
are frustrated, it says something interesting about mail list dynamic 
doesn't it.

Anyway we can take a new itteration with #1 and #2 if you and others 
feel like that. Please write an RT where you give more details about 
your view.

/Daniel



Mime
View raw message