cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo F. Ochoa" <>
Subject Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one page into another?]
Date Tue, 28 Mar 2000 19:06:12 GMT
Zisch (Matthias Meier), NetHorizon AG wrote:

> Hi Cocoon-Developers (and especially Stefano ;-),
> >I'm copying this to cocoon-dev since it should really belong there.
> >
> >Crossposting is normally bad, but I don't know if Matthias is subscribed
> >there and this will give him the time to do it.
> Yes, I'm subscribed, but only for two days now. I actually wanted to learn more
> about Cocoon before posting my own ideas, but I saw the discussion about
> page-including in the users list, so I just took my chance to contribute.
> BTW: All my friends call me "Zisch", but if you prefer "Matthias" it's ok. :-)
> >"Zisch (Matthias Meier), NetHorizon AG" wrote:
> >>
> >> Content-MD5: SzWLgMS0js0jny122p3vsA==
> >> X-Spam-Rating: 1.6.2 0/1000/N
> >>
> [ ... uninteresting parts deleted! ...]
> >
> >> We decided now to change to Cocoon as the base for our next release of WeAF.
> >> (There will still be a WeAF since there is a number of features in it, which
> are
> >> not part of Cocoon and probably never should be, since they are quite
> >> specialized for the "style" of Web-Application that we develop, or solve
> >> problems -- like resource-loading, DB-interfacing etc. -- which are not
> actually
> >> part of Cocoon's job.)
> >
> >I totally disagree. In fact we are working toward Castor integration
> >that is exactly about resource-loading and DB-interfacing... You might
> >well do your WeAF stuff, but you might find yourself overlapping with
> >Cocoon and even basing your core on its code.
> >
> >I think it makes much more sense to collaborate. But, this is my
> >personal vision, of course.
> I totally agree! Seems as if I should have a look at Cocoon 2! (Never heard of
> "Castor" -- can someone give me a short explanation?)

    me too!!

> >> However, there are also some "general purpose"-features which I will "port"
> to
> >> Cocoon. One of these features is dynamic inclusion. However, rather than to
> >> dynamically include static XML from files, I would like to include the result
> of
> >> a request to another page which also gets served by Cocoon (something like an
> >> "internal subrequest").
> >
> >Internal subrequests... old tune.
> Sorry, if I tell you stories which you know already ;-) As I said: I'm very new
> to Cocoon.
> >> Since I do not want to format the result of the "subrequest" as a character
> >> stream and re-parse it again to a DOM tree, I intend to hack Cocoon, so that
> it
> >> will be possible to make "internal subrequests" which return their results as
> >> DOM-tree (that is, before the formatter does his work). (I don't think, that
> >> this is yet possible, for example using the util: taglib, is it?)
> >
> >I honestly don't know (ricardo?) but I would think not.
> >
> >> With this hack, it should be possible to "make a request" by calling the
> >> appropriate Java method of the Cocoon-Engine (using a probably modified
> >> Servlet-Request-Object) from within an XSP-page and include the returned
> >> DOM-tree (or parts of it) into the DOM-tree of the document which was
> requested
> >> in the first place.
> >
> >yeah
> I assume, this means: "Do it!".
> >> I skimmed through the Cocoon sources, and I think I know now how to do it.
> Are
> >> there any objections against this intention?
> >
> >one: don't do it on Cocoon 1.x
> >
> >> Other comments? (Maybe, I violate
> >> some basic design-concepts which I didn't know up to now? Maybe there is a
> >> better/simpler way to do it?)
> >
> >Cocoon 1.x if feature-frozen: means that even if you donate the code, I
> >won't add it. This is to _suggest_ people to work on Cocoon2.
> OK. Cocoon 2 then.
> [... parts deleted ...]
> >> There is yet another hack which I need/intend to do: when starting the
> >> web-application (i.e. the Cocoon servlet), I need to initialize arbitrary
> helper
> >> objects which will then be available for the whole application, i.e. all
> >> XSP-pages and other components (for example to implement global caches,
> >> connection-pools etc.). Some of these helpers will also need to listen to
> every
> >> request and eventually redirect (using "internal subrequests") or otherwise
> >> "pre-process" the request (for example to check access to certain pages
> etc.).
> >> Last but not least, some of the helpers will need to know when the
> application
> >> shuts down (for example to cleanly close pooled JDBC connections etc.).
> >
> >This should be a servlet engine thing.
> >
> >> I intend to "generalize" the current way (as of Cocoon 1.7) how producers,
> >> processors and formatters are created to allow creation (and storage in the
> >> ServletContext) of objects of any class. Further I will implement some hooks,
> so
> >> that such global objects (or any other object ;-) may register themselves as
> >> listeners for certain events (namely incoming requests, completion of
> requests
> >> and shutdown of the servlet engine, maybe also for creation and destruction
> of
> >> sessions).
> >>
> >> Again: Objections? Comments? Better ways to do it??
> >
> >Tomcat provides exactly such hooks. I believe that Cocoon, being a
> >servlet should "inherit" all the features that are necessary to
> >servlets... but I admit I haven't really thought about it that much, and
> >I'm always open to alternatives if they are necessary.
> We are currently using JServ, so I was not aware of this possibility in Tomcat.
> I will certainly have a look at it. Thanks for pointing it out!
> >> One last thought: it seems to me, that the response for any request gets
> cached
> >> as a String. This is true, even for pages which are generated by
> >> producers/processors which always re-generate the response (p.e. XSP).
> >> It would be quite easy to specify an additional method for Processor's (resp.
> >> Producer's) -- something like 'boolean isCacheable()' -- to allow Producers
> and
> >> Processors to signal to the engine that responses by that Producer/Processor
> >> shall never be cached because the cached responses get discarded anyway upon
> the
> >> next request for the same page. The needed changes to the Engine class would
> be
> >> minimal and implementation of 'isCacheable()' should be trivial (for the XSP
> >> engine: "return false;" ;-).
> >
> >Good idea. No problem in adding this to Cocoon2. What do others think on
> >this?

  I vote +1, the method isCacheable() sound useful for the Oracle PLSQL Producer
and probable work faster than check for hasChanged().

> >
> >> To the Cocoon-Developers: I understand, that you currently rather work on
> Cocoon
> >> 2.0 than to optimize the 1.x version. Probably you are also aware of this
> >> optimization-possibility, and I expect, it will probably be part of Cocoon
> 2.0
> >> (or be obsolete in Cocoon 2.0). If so, just ignore these two paragraphs. If
> not,
> >> I hope my statement helps to improve Cocoon further.
> >
> >Oh, you definately made great comments and proposed good ideas. I would
> >love to see more people involved in the actualy code writing of Cocoon2
> >and I welcome you on board if you want to help us.
> >
> >But, please, try not to fork our project or to work on Cocoon1 since
> >this would, IMO, waste your efforts and create harm to the project.
> >
> >Instead, direct collaboration would help everyone.
> >
> >What do you think?
> I absolutely agree!

    Stefano or Ricardo, how about to add SQLJ processor to XSP code
    SQLJ is an standard extension to Java to write embedded SQL code inside Java.
It's look like this:

               SQLJ Example

               long length; #sql length = { values(dbms_lob.getLength(:blob)) };

               Equivalent JDBC Example

               CallableStatement cs = conn.prepareCall( "{call ? =
               ); cs.registerOutParameter(1, Types.NUMERIC);
               ((OracleCallableStatement)cs).setBLOB(2, blob); cs.executeUpdate();
long length
               = cs.getLong(1); cs.close();

    SQLJ is more concise and thus easier to write than JDBC, and provides
compile-time schema validation and syntax checking for easier debugging.
    SQLJ takes as input either a file of SQLJ clauses or a file of Java source code
in which SQLJ clauses are embedded. The SQLJ precompiler translates the SQLJ
clauses into their equivalent JDBC calls. SQLJ supports static SQL.
    Each line of SQLJ is mapped to around five lines of JDBC calls.
    Regards, Marcelo.

View raw message