cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <mi...@pcextremist.com>
Subject Re: Flow questions
Date Fri, 17 Jan 2003 19:29:46 GMT
Christian Haul wrote:

>Why don't you code this in a java class and just use it from flow? Why
>would you want to code that in javascript?
>
Because JavaScript has no compile step and is simpler.  Unless you are 
expecting a high load on a resource (content inserts and updates are 
expected to be far fewer than reads), what are reasons to use Java?  
Doesn't Rhino compile the JavaScript down to Java bytecodes anyway?  If 
the whole thing is going to take only about a page's worth of code, why 
go through the compile step?

>>1) How do I get XML POST data into the function (eg. equivalent to 
>>StreamGenerator)?
>>    
>>
>
>You could write an InputModule for that and copy the relevant parts
>from the StreamGenerator or write an InputModule that can connect to
>an internal pipeline (the XMLFileModule does something similar).
>
>  
>
>>2) How do I look up a Cocoon datasource by name in JavaScript/Flow?
>>    
>>
>
>If you follow suggestion to 1) you could use the database actions from
>the modular package and don't need to. Apart from that, you have
>pretty much the same options as inside a java component. See
>e.g. system.js and JSCocoon.java for the available objects.
>
Thanks, although now I'm a bit confused.  I think you are assuming 
background information that most of us don't have.  1) What is the 
"modular" package?  2) Where is it? (I'm assuming you don't mean 
matching/modular which is the only directory I see in the cocoon source 
hierarchy.)  3) Do those database actions really simplify things?  I 
didn't think my codebase was all that complex to begin with.  (Hard for 
me to tell because I don't know which actions you are specifically 
talking about.)

Also, the point of this particular item is the consumption of data with 
only a status/result coming out.  There is no real XML->XML 
transformation step.  There is an abrupt end to the pipeline model here 
in favor of a logic-based, programmatic model.  Wouldn't actions muddy 
those waters rather than clean them up?

Also I saw a post that gave an example of access to the component manager.

  var dbSelector = cocoon.componentManager.lookup(
    org.apache.avalon.excalibur.datasource.DataSourceComponent.ROLE + 
"Selector"
  );
  var datasource = dbSelector.select( "datasource name" );

That's what I was looking for in the original post.  Of course now you 
have me curious about other options.  I realized that my questions may 
have come over as too simple and basic, but I honestly did look through 
the online documentation, the Wiki, and even bought one of the books on 
Cocoon 2 (the one by Lagos Moczar and Jeremy Aston).  When I tried doing 
searches on the mailing lists for this info, most of the hits gave back 
so many unrelated items that it was taking days of drudgery just to get 
close to an answer.

I'm not just talking about Flow.  Has anyone looked up how to implement 
caching in an XSP file lately -- or anywhere else for that matter?  The 
example has been broken in CVS for some time due to the API change from 
2.0 to 2.1 and no one seems to have updated examples.  I checked the 
source for some insight, but the only obvious places that I knew to look 
were FileGenerator and its ilk, but without outside notes on the overall 
mechanism, I'm at the alchemy stage of development (trying something out 
to see what happens).  For example, I saw Carsten Ziegler's 
TimestampValidity object -- something I know will be useful for what I 
have in mind, but there is nothing in plain view that I saw explaining 
how to get there.  Excalibur's XML Utilities are much the same story.  
Unless you know where the starting point is, it's very difficult to 
follow an object/component hierarchy and flow.

I know that people are working on documentation.  I'm not trying to 
sound ungrateful.  Just ranting a bit.

>See also
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103811227701167&w=2
>

Great link!  Thanks!  I vaguely remember it coming down the pipe.  Has 
any documentation come of it yet?  I know there was that sendPage API 
debate, but what about the rest?  It mentions fears about using Flow the 
wrong way (and Stefano's excellent retort regarding JavaScript as just a 
syntax).  Here is my dilemma.  In my setup, Java -- and objects in 
general -- are not the focal point.  This is quite unlike most 
processing systems where the logic and the object model is actually the 
focal point.  For my system, the focal point is XML.  Whatever 
persistence layer is used, the useful contract is the XML -- no matter 
the mechanism to get there, the persistence behavior, or the output 
type.  For distribution, the XML is to be converted to multiple 
formats.  Progammatic logic and objects are seldom used.  In this case, 
I want to persist the XML to a storage medium, but I don't have the 
time, energy, or resources to write a complex XML->Relational bridge.  I 
have just a few different document types that get saved into multiple 
tables.  For reading the info, ESQL is quite capable of doing the job of 
bring various relations together.  On the other hand, when splitting the 
info into distinct relations, custom code will be necessary -- and I 
don't see how an EJB or equivalent will speed things along for me 
either.  CMP would not work for me (and I'm surprised it works for 
anyone with anything but the most trivial of schemas).  Bean Managed 
could work, but is all of that code and work worth avoiding the use of 
100-150 lines of JavaScript?

I looked at XMLDB, but while some of the content could benefit from it, 
the data is far more relational than hierarchical when saving it.  
Frankly, I and my group are also more comfortable with a relational 
database.  That said, with XML as the input/output layer, the backend 
storage can be swapped out if we find that something like Xindice can 
work better for us in the future.

So my question here is what is "the wrong way" to use flow?  How much 
logic is too much?  Is it the number of lines written?  Is it for any 
persistence mechanism -- even if that mechanism is only about 100-150 
lines long?  What exactly is it about JavaScript that is so horrible 
that people believe that everything more than if-statements and 
for-loops must be written in Java?

And for that matter, assuming that I'm not using continuations in this 
case, is that some sort of faux pas?  Is Flow's only raison d'etre for 
multi-page wizards?

- Miles

(once again, writing far more than I was expecting)



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message