Christian Haul wrote:
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?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?
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.)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.
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.
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?See also http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103811227701167&w=2
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
