Miles Elam wrote:
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
AFAIK the continuations enabled version doesn't.
<snip/>
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?
I was refering to org.apache.cocoon.acting.modular
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.)
See above
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.)
Depends -- you don't have to deal with the database connection and SQL.
And you can call them from flow.
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?
They are not much more than a method call. Only that the signature is
always the same. They don't invoke pipelines if that is what you were
saying with "no real XML->XML transformation step."
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
No idea. But I doubt it.
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.
A great help is putting your findings on the wiki -- you are probably
taking notes anyway.
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
None that I know of -- but I may have missed it.
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
IMHO anything that does more than decide which is the next page to
display. Calling higher level JAVA methods on the transitions of course.
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?
Maintenance and reuse mostly.
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?
No - complex decisions which page to display next would be my
impression. For example reacting on the outcome of a method call is
tedious inside the sitemap but peace of cake with flow.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
