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 no!)
Date Thu, 02 Dec 2004 18:01:07 GMT
Daniel Fagerstrom wrote:
> Miles Elam wrote:

[a little too emotional fight that brings the danger of moving the 
important points discussed on the bottom and the rants at the top, 
hiding the signal]

A little story first.

I'm writing a thing called Dynagump these days. It's a web application 
and it's supposed to do reports out of a database that gump populates 
every night. It's supposed to replace the static web pages that gump 
generates today and that don't keep historical information.

Concerned by bootstrappability, I tried with Python stuff and found out 
that Python is literarely 5 years behind in web technologies. They are 
all thinking that CGI-BIN is good enough (example, MoinMoin) or, if not, 
they build their own web server (example, Zope).

Some people had the brilliant idea to write Servlets for Python (d'oh!) 
in a thing called WebKit. Pretty cool. It feels like JServ 0.9.11. 7 
years ago would have been a compliment.

So I decided I didn't want to spend 3 years of my life to rewrite (one 
more time!) the history of servlets in python and I switched back to java.

Also, I tried to be as simple as possible: velocity templates and a 
resultset as a bean.

It turns out that velocity iterates only on iterators and resultset 
don't implement iterators. So, either I write my own iterators or I do 
something else. Since I never used it, I tried Hibernate. Took me a few 
hours, but I had it: I was able to show my projects on a web page.

Uhuh!!

Ok, now, let's write a real userful page.

Hmmm, well, oh, yeah, URL management... web.xml... crap. One servlet and 
all as parameters? nah, too 90's. one servlet that does URL management? 
all right.

so I start writing what turns out to look like a sitemap-like URL 
matching system. nono, stop that. back to the templates.

hmmmm, all right, I know I have to display the results of

SELECT
   builds.id,
   builds.result,
   builds.start_time,
   project_versions.project,
   results.name
FROM
   builds,
   project_versions,
   results
WHERE
    builds.run = $ID
   AND
    builds.project_version = project_versions.id
   AND
    builds.result = results.id
ORDER BY
   builds.start_time
ASC

but how in hell is this translated into O/R mappings? I look around and 
it seems that I have to do the whole joins by myself...

Wait a second!

This is a publishing application. No roundtripping. Multichanneled. 
URL-space problems, SQL describing the data results perfectly.

Screw that, I'm using cocoon.

Thanks to SVN, I moved the hibernate version somewhere else and started 
over with cocoon.

First, I tried to do the same thing that I did with velocity+hibernate 
in cocoon.... if I wanted to use velocity, I needed to have a way to 
invoque the controller... but I didn't have state to manage, so why 
should I use flowscript for that?

I tried with a simpler SQLTransformer. Worked fine, but then, I 
thought... well, sometimes, the queries change depending on the request 
parameters.... hmmmm, so, how do I do that in SQLTransformer? an XSLT 
stage between the generator and the transformer? nah, gross.

All right, let's use XSP.

                                   - o -

Now I find myself in this weird limbo.

One side of me still likes XSP. The syntax is ugly since XML and Java 
don't mix that well (and it will be even worse with 1.5 generics!), but 
the power is incredible. If you know what you are doing it's like 
writing servlets at 100x the speed but without all the crap that JSP 
forces you since you don't have a pipeline after you.

The only taglibs I'm using are ESQL and request. I do the if/then/else 
in java code.

It works just fine, but I'm afraid that this will stop non-xsp-users 
from being able to contribute to my effort once it starts and this 
scares me.

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

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.

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.

Everything else is making a step backwards.

-- 
Stefano.


Mime
View raw message