You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Miles Elam <mi...@pcextremist.com> on 2003/01/17 05:17:46 UTC
Flow questions
With the hope of using WebDAV or XML POST to update XML items on the
server, I've been looking at Flow. If you just want to see my flow
questions, feel free to skip the preamble.
<PREAMBLE>
The back end data store is a PostgreSQL database whose relevant table
looks something like this. It has been abbreviated for clarity.
CREATE TABLE "shows" (
"id" serial NOT NULL,
"category" character varying(96), -- Useful for searches by topic
"topic" character varying(64) NOT NULL,
"abstract" character varying(1024),
"promo" character varying(1024),
"content" text,
"liveDate" timestamp(0) with time zone,
Constraint "shows_pkey" Primary Key ("id")
);
The incoming XML is based upon simplified docbook and looks something
like this:
<show xmlns="http://geekspeak.org/2.0">
<showinfo>
<pubdate>2003-01-20T18:30:00-08:00</pubdate>
<topic>Small Web Dev Survival</topic>
<participationgroup>
<participant userid="3"/>
<participant userid="5"/>
<participant userid="7"/>
</participationgroup>
<promo>On the next Geek Speak: Jasper Larence, CEO of Words and
Images of
Santa Cruz, joins the Geeks for a discussion about the status of
web development as a business. [The quick growth of the Internet
lead to
an acute need for web development companies. The crash saw the
death of
many of these new ventures.] The survival of the web creation
industry
on GeekSpeak, Monday [tomorrow/tonight] at 6:30pm on Central Coast
Public
Radio, KUSP.</promo>
<abstract>
<para>Jasper Larence, CEO of
<orgname><ulink url="http://www.wordsandimages.com">Words &
Images</ulink></orgname> of Santa Cruz, joins the Geeks for a
discussion about the status of web development as a business. The
quick growth of the Internet lead to a large need for web
development
companies. The crash saw the death of many of these new
ventures, but
some companies like Words & Images are still around. Learn
why.</para>
</abstract>
</showinfo>
<section>
<title>What is web development?</title>
<para>Blah blah blah blah blah...</para>
</section>
</show>
At first, I thought to convert the XML into XSP/ESQL. That turned out
to be a mess to the third power: a completely unmaintainable mess of
markup and Java code. I wouldn't expect anyone to happily fix any of my
bugs in that rats nest nor would I expect to happily fix them myself six
months down the road.
The next thought was Actions, but that was just keeping the code
relatively out of sight. It seemed fairly clumsy for any non-trivial
amount (more than 100 lines) of logic and made the sitemap kinda crufty
as well.
</PREAMBLE>
Next came Flow. Although I didn't have multiple pages to work with as
is the case with a wizard, it seemed to make a lot of sense in a
predominantly procedural logic approach. However, I ran into a few
snags -- mostly related to lack of documentation (yes, I realize it's
alpha and the API may be pulled out from under me...I'm prepared to deal
with the search/replace/debug repercussions). I'll keep my code snippet
as short as possible.
function saveShow () {
var showData;
try {
var factory =
javax.xml.parsers.DocumentBuilderFactory.newInstance();
var builder = factory.newDocumentBuilder();
var showDocument = builder.parse( /* Somehow get the XML POST data
in here */ );
var showData = getShowData(showDocument);
} catch ( e ) {
sendPageAndContinue("showerror");
}
try {
var dbConn = /* Somehow get the datasource by name */.getConnection();
var dbStatement = dbConn.createStatement();
// ...snip a whole bunch of extraneous JDBC logic...
} catch (sqle) {
sendPageAndContinue("showerror");
}
}
1) How do I get XML POST data into the function (eg. equivalent to
StreamGenerator)?
2) How do I look up a Cocoon datasource by name in JavaScript/Flow?
3) BSF question: Do I always have to call "foo.getBar()" or will
"foo.bar" work?
4) Am I doing something that will drive me into a brick wall, but I
can't see it yet? (Is this the correct approach to the problem?)
Thanks,
- Miles
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Flow questions
Posted by haul <ha...@informatik.tu-darmstadt.de>.
Miles Elam wrote:
> Christian Haul wrote:
>
>> I was refering to org.apache.cocoon.acting.modular
>
>
> What CVS branch are you using? I've just pulled the latest from HEAD
> and the modular directory is empty. (I missed it the first time
> because I was using "cvs -z3 update -d -P" which prunes empty
> directories.)
In 2.1-dev this and many others have been moved to a block e.g. from
src/java to src/blocks/databases/java
Chris.
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Flow questions
Posted by Miles Elam <mi...@pcextremist.com>.
Christian Haul wrote:
> Miles Elam wrote:
>
>> 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
What CVS branch are you using? I've just pulled the latest from HEAD
and the modular directory is empty. (I missed it the first time because
I was using "cvs -z3 update -d -P" which prunes empty directories.)
>> 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.
Funny...in all the APIs in Java, I always considered JDBC to be the
simplest and easiest to use. Maybe I've just been using SQL for too long...
>> 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.
Just saw a bugzilla message flash by the other day that dealt with this
issue. I made a Wiki page for it
(http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD). It
also answered my questions about how general caching works for
components in 2.1. Thank you Joerg.
> 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.
But isn't that what I'm doing when I call JDBC methods: calling
higher-level Java methods? If this script is an example of a specific
document schema persisting to a specific database schema, I'm at a loss
to see how much code I would be reusing. It would really be a case of
porting the code basically line-for-line to Java (and adding the
compilation step).
- Miles
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Flow questions
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Flow questions
Posted by Miles Elam <mi...@pcextremist.com>.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Flow questions
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 16.Jan.2003 -- 08:17 PM, Miles Elam wrote:
> The next thought was Actions, but that was just keeping the code
> relatively out of sight. It seemed fairly clumsy for any non-trivial
> amount (more than 100 lines) of logic and made the sitemap kinda crufty
> as well.
>
> Next came Flow. Although I didn't have multiple pages to work with as
> is the case with a wizard, it seemed to make a lot of sense in a
> predominantly procedural logic approach. However, I ran into a few
> snags -- mostly related to lack of documentation (yes, I realize it's
> alpha and the API may be pulled out from under me...I'm prepared to deal
> with the search/replace/debug repercussions). I'll keep my code snippet
> as short as possible.
>
> function saveShow () {
> var showData;
> try {
> var factory =
> javax.xml.parsers.DocumentBuilderFactory.newInstance();
> var builder = factory.newDocumentBuilder();
> var showDocument = builder.parse( /* Somehow get the XML POST data
> in here */ );
>
> var showData = getShowData(showDocument);
> } catch ( e ) {
> sendPageAndContinue("showerror");
> }
>
> try {
> var dbConn = /* Somehow get the datasource by name */.getConnection();
> var dbStatement = dbConn.createStatement();
> // ...snip a whole bunch of extraneous JDBC logic...
> } catch (sqle) {
> sendPageAndContinue("showerror");
> }
> }
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?
> 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.
See also
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103811227701167&w=2
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>