RE: jboss and cocoon
arnaud asked: does anybody used cocoon with jboss ? Yes, we deploy Cocoon as an EAR under Jboss. The EJB classes are packaged as a JAR within the EAR and Cocoon is packaged as WAR inside the EAR. The EJB remote interfaces are included in the Cocoon lib. You can of course deploy separately if you'd like... i would like to use mey ejb method : toXML() who transform ejb data in xml Just call your remote interfaces from any Cocoon classes as normal. As long as you've got the remote interfaces available to Cocoon there is no issue. what kind of generator may i use ? Any kind you'd like :-) - 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]
RE: ideal hardware for cocoon?
We are going to be setting up a dedicated cocoon server soon and I am trying to spec out the hardware. The operating system will be redhat (8 probably) and tomcat will be the servlet engine. Does anyone have any experiences of what hardware balance is right for cocoon? As much as you can afford... :-) I know this is stupid question with no concrete answer as it depends on what the server will be doing, loading, etc. etc. etc. The cocoon server is mainly going to be serving FOP based transformations, xml (xhtml) to PDF and xml to svg to png. Given that it sounds like as much memory as you can afford will help... As much static content as possible will be served from a dedicated apache http server so this machine will only be doing dynamic xml transformations. Some of these might get quite large, our present record is xhmtl to 206 pages of pdf. Yep, definitely going to need memory. As you've stated there is no answer to this question. Here we have Cocoon serving a lot of very dynamic content. Dev development is 2 Dell 2650's: dual Xeon processors, RAID 5, 1GB memory. One runs Oracle DB other runs Jboss/Tomcat/Cocoon. Production will be Quad Xeon processor with 4GB memory for DB and multiple 2650's (or similar) for JBoss and Tomcat with more memory. We expect to support a couple 100 users. Lots' of hardware for a small user base, but the problem is hard to solve and hardware is cheaper than people time for this particular problem... - 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]
RE: A note about the best(?) (cocoon-) development environment ...
snip Ones you didnt talk about: 13) Together control center. If you can afford it, it absolutely kills any other IDE on the planet. Hmm, I use it, but I wouldn't quite say that: it's got it's share of bugs that make it sometimes quite painful to use. However, we're getting good support and I expect these to eventually be solved. 14) eXcelon Stylus Studio. A great XML editor. It has a bonus of being easy to use and allot less confusing than XML Spy. This is probably a personal preference kind of thing: I prefer Xslerator over either Stylus or XML Spy, but my main focus is writing and debugging XSLT. If your main focus is XSLT to HTML transformation or XML authoring then Stylus is probably the best choice. If you need something sort of half way in between then XML Spy does a reasonable job. snip * I also managed to setup eclipse with Cocoon in less than 10 minutes. OK, i did a lousy trick, but for debugging and learning how cocoon internals work it's absolutley satisfying... Shouldnt be tough, just run tomcat (or JBoss) in debug mode with a socket attach. Then you can remote attach to the socket and you are on your way! Yes it works, but get some powerful hardware if you're using Together on the other side of the debug socket! more snip - 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]
RE: Using the results of an aggregate part.
Now the question raises, how i can gather an xml-fragment, put it into some temporary place (ideally in memory) and refer to this fragement from another part of the pipeline. Any reason why you don't trust Cocoon caching to do this for you? From the looks of what you've shown us there are no request or client side parameters going into the fragment generation and it should therefore be possible to have it always cached once it has been created the first time? - 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]
OT: Capital (Was RE: Cocoon use worldwide)
Anyone know any VCs with money left? :-). AN interesting aspect of Capitalism is that money never disappears. Anyone who claims this doesn't know how to look at the big picture. Ah, but capital does disappear: much of the dot com boom was financed not with money but with inflated expectations converted into inflated stock evaluations But yes, you are correct, you still can find money if you can write a decent business plan. But beware, you can also still find over valued stock if you're not careful. - 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]
RE: Simple example / XML / XSLT In production
I was debating xml, xslt versus jsp with a colleague. He noted that although xml, xslt works well in a divided graphics/analyst/developer big team, it eventually was scrapped for JSP. The lack of object hierarchy and polymorphism made changes very difficult. Can anyone provide tales of xml, xslt in a major production? (sans company name, of course) We're certainly heading towards having a lot of xml and xslt in production. Can't imagine doing what we are doing with JSP: we need 100's of customized variations of any given screen. My reason for replying however is the comment on lack of object hierarchy and polymorphism. I'm confused by this: although it's certainly true that XSLT is not an OO language that doesn't mean it cannot map constructs to OO languages. In particular, XML can map OO isomorphically and XSLT can then traverse this mapping. Moreover, XSLT does allow for some many different types of hierarchy (include, import, modes and priorities) that, although different than OO aggregation and inheritance can be used in similar ways. Finally, much XSLT is run without schema/DTD validation which allows it in a way to support the ultimate in polymorphism: your data can dynamically change type. This last is a bit of a straw man, but let me put it this way; XSLT is Turing complete, anything you can program in any other language can be done with XSLT. It's not always easy, but then again, sometimes it's a lot easier than using JSP... - 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]
RE: XML / XSLT In production
True true, and thank you Peter. I should have clarified, not lack of object hierarchy and polymorphism, but lack of perfect or ...traditional. Some deny a comparison between xslt and oop languages. My discussion with the colleague was brief; I cannot interpret his experience perfectly. The serious problem apparently was synching xml, xslt with changes in the underlying object model. There are ways to do this automatically as well, both at run time and at design time. Perhaps they need to look at something like Castor? Or, if your careful your underlying model can be generated from a design that should be capable of generating XML as much as it is Java stubs... In such a model the XSLT is independent of the OO model (running over it, as it where). I drew a parallel with OODBMS, a solution which still defies popularity. Yes, we're doing an OO to relational mapping (sigh/shrug). But there are reasons for it in spite of what the OODBMS people might try to sell you. Meanwhile, Jsp and struts continue to preside over cocoon, much to my disappointment. It's a hard sell, while they are an easy sell. No one gets fired over choosing Oracle, Weblogic, jsp followed by MacDonald's for lunch. The sell shouldn't be as much Cocoon as it is dynamic UI and/or dynamic data models... If you don't expect to _ever_ change your UI and you only have one of them then JSP makes sense, otherwise you need something else - 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]
RE: proposal: The Newbies Competence Center (XSP?)
I think we are agreeing (?) on the issue of proprietary : in essence, any code that you do not write yourself is 'proprietary' in some way - it belongs to someone. Uh, no, but it's not worth worrying about... - 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]
RE: Cocoon use worldwide
We're using Cocoon on health care projects that need to protect XML content at a fine-grain level based on a user's role, context, and state of the data. Rather than embedding this logic completely in the persistence layer or code (a DB or EJBs), we're doing it within transforms and actions. Hi Jack (John?), This sounds an awful lot like what we are working on here at St. Jude Children's Research Hospital... I've posted about it some here on users and some on dev. Mostly architectural concerns: one area I'd like to see Cocoon go is to make it possible to write all business and presentation logic as XSLT rules triggered from XML templates. This allows us to audit various transactions to ensure they meet HIPAA guidelines at a very detailed level and express those data security policies as constraints on XPath expressions - which non-programmers like physicians can actually read and understand! :-) That's a bit different than our approach. The security and audit rules are written in XSLT/Xpath, but they aren't implemented in such a way that I'd expect anyone but a programmer to understand (though they are not to opaque). Eg: xsl:if test=$auth != 'None' and $auth != '' !-- can user see object at all? -- Or: xsl:if test=contains(@authorization,'Update') We've also been able to more easily cast their web applications as web services, VoiceXML services, and as AvantGo sources (e.g., a directory of regional physicians). Haven't had to go their yet... Finally, the development and deployment of Cocoon solutions are very cost effective (TCD and TCO). Very important for a non-profit like us... snip/ I'm giving a tutorial on Cocoon next month ( http://www.eccnet.com/xmlug/ ) here in D.C. I also noticed that Ivelin Ivanov is giving a talk in Austin, TX USA next month too ( http://www.xmlaustin.org/_html_out/main/events.html ) If you ever make it near Memphis I think it would be worth getting together. I used to get to the DC area every spring for the HCFA conferences but don't have time for those these days... - 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]
RE: cocoon portability
Also they want to know how much of the effort of setting up a cocoon can be reused if we decide not to go with cocoon. I suppose the business logic can be reused and possible the stylesheets but I am not sure. If you stay away from XSP then much of what you do can be reused. If you're careful all your XSLT are portable. Similarly, Cocoon is a big servlet: if you're careful (extend a common base class that of your own) actions and generators can be maybe 80% reusable, though you'll have to write a lot of code to move them anywhere: Basically, you'd have to implement your own servlet that probably made hard coded assumptions about resource names. It would call your generators to pass the output on to an XML transform. From there you'd call your actions, again with a bunch of stuff hard coded. I can't imagine actually wanting to ever do this, but much of our code has been written with this possibility in mind. Now that Cocoon is more accepted here this requirement may go away for us in the future :-) - 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]
RE: Cocoon Competence Center Updates
my question is how other people can even use cocoon with this bug in it. Certainly if you are just doing SQL to a little database, it will work fine but has none before tried to integrate it with an enterprise development system? It's real simple: don't use XSP... You where going along fine with Cocoon, you have a working Generator. For some reason you decided to convert it to an XSP and you found a bug. So why not go back to using the Java code? Or as a temporary work around dump the EJB interfaces into an EAR and deploy them with Cocoon - 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]
RE: proposal: The Newbies Competence Center (XSP?)
Title: Message Well, you carefully (or not?) snipped out my point that, in the end, the XSPs are converted to Java That's irrelevant; you're still writing proprietary code... - and at least one of theCocoon books I read suggests this as a perfectly vaild way to start off doing your own coding for custom generators. Absolutely, justunderstand the tradeoffs you're making in terms of performance and portability. So... I am not sure what you mean by "loss of portability" - It may not be anissue for you. For us, we have some requirements torun our code outside of Cocoon. They haven't forced us away from Cocoon yet, but they could in the future. All that said, I would be very happy to "upgrade my skills" (and design approach) to learn how to develop Cocoon-based systems that are both complex and XSP-free. 1st learnJava. 2nd learn XSLT.:-) If you (or anyone else) would care to share your approach and methodology in the form of tutorials and/or examples, I am sure I am not the only one who would benefit from it. The way we do things won't make a lot of sense to you untilyou have a lot of Java and XSLT skills.
RE: proposal: The Newbies Competence Center (XSP?)
Title: Message Hmm? Well isn't that like saying that sitemaps are "proprietary" Well yes, but there's a big difference between coding your business logic in a proprietary non-portable solution and configuringa pipeline. By staying away from XSP I can switch away from Cocoon to a servlet environment with a couple of days worth of coding (although I'll loose a lot of flexibility). to Cocoon. XSP, to me, provide a valid and useful function. They allow me to develop generators with a *minimal* amount of Java knowledge (which, sadly, is my situation); as far as possible I avoid using it (except for simple if/then statements and the odd calculation) but it makes a very useful wrapper for ESQL which, if you are working with databases, is a *must have* (IMO) That's all very good. You just need to be aware of the trade off you are making: lower learning code in Java for reduced portability. If that's not an issue for you then full speed ahead... None of this changes the fact that it's very possible to code a complex Cocoon app without touching a line of XSP...
RE: Cocoon is complex, but worth it! Some Answers to your dilemma
Thanks for the reply. I still, however, cant figure out how to get a hello world working on a clean war without all of the other crap in the cocoon war. Robert, It seems you really have two requirements for Cocoon: 1) learning how to create a simple Cocoon app; 2) learning how to build a minimal Cocoon distribution that doesn't require all the JARs for deployment in order that you can deploy Cocoon multiple times without duplicating the libraries each time. It's not clear why you want to combine these two steps? We ran Cocoon here for almost 8 months before we worried about getting a minimal Cocoon image (when we finally cleaned things up we went from a 12MB EAR to a 5 MB EAR, much of which is our own code). In the mean time we wasted some disk space but no development time... You are right that Cocoon is not easy to pick up and use for deploying a simple application. That's not what it was designed for. Cocoon is designed for making it easy to manage complex data sets and/or complex web based user interfaces. If all you want is a simple front end then likely you don't have a requirement to use Cocoon - 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]
RE: Single JAR with all the libs?
Robert,
Don't know the answer to your problem, but I also am not sure why you need
it?
In any case, I've noticed that at no point has anyone suggested deploying an
EAR under JBoss/Cocoon instead of a WAR? Given that you want to hot deploy
single classes that's probably not an option for you, but for integrated
EJB/Cocoon deployment it works pretty well.
Following is a Ant build that gives a pretty minimal Cocoon combined with an
EJB Jar. It's specific to one of our projects, but should be pretty easy to
modify. Note that it builds Cocoon and does a hot deploy to Jboss all in
one shot, that would also be easy to change
Also note, This version is for JBoss 2.4.4. we've also got a version that
deploys to JBoss 3 but I don't have a version at hand, but I think the only
change is the location of the deploy directory relative to the JBoss root...
project name=gunk default=deploy basedir=/
property name=rootDir value=/projects/
property name=deploy value=/Jboss-2_Tomcat-4/jboss/deploy/
property name=ctHome value=${rootDir}/gunk/
property name=build value=${ctHome}/build/main/
property name=cocoon value=${ctHome}/Cocoon/
property name=distvalue=${ctHome}/dist/
property name=ear value=${ctHome}/ear/
property name=ejbbuildvalue=${ctHome}/build/ejb/
property name=ejbsrc value=${ctHome}/ejbsrc/
property name=script value=${ctHome}/buildscript/
property name=src value=${ctHome}/src/
property name=srcmain value=${ctHome}/src/
property name=web value=${ctHome}/web/
property name=libHome value=${ctHome}/lib/
property name=avalon
value=${libHome}/avalon-framework-20020627.jar/
property name=cocoonlib value=${libHome}/cocoon-2.0.4.jar/
property name=datasource
value=${libHome}/excalibur-datasource-vm14-20021121.jar/
property name=jdomvalue=${libHome}/jdom.jar/
property name=junit value=${libHome}/junit.jar/
property name=log value=${libHome}/logkit-20020529.jar/
property name=oracle value=${libHome}/classes12.zip/
property name=pool
value=${libHome}/excalibur-pool-20020820.jar/
property name=servlet value=${libHome}/servlet.jar/
property name=ujc value=${libHome}/ujc.jar/
property name=xalan value=${libHome}/xalan-2.4.1.jar/
property name=xerces value=${libHome}/xercesImpl-2.1.1.jar/
property name=debugmodevalue=off/
target name=init
tstamp/
mkdir dir=${build}/
mkdir dir=${dist}/
mkdir dir=${ejbbuild}/
mkdir dir=${ejbbuild}/META-INF/
copy todir=${ejbbuild}/META-INF
fileset dir=${script}
patternset
include name=ejb-jar.xml/
/patternset
/fileset
/copy
mkdir dir=${ear}/
/target
target name=compileEjb depends=init
property name=build.compiler value=jikes/
javac srcdir=${ejbsrc}
destdir=${ejbbuild}
debug=${debugmode}
classpath
pathelement path=${ujc}/
pathelement path=${oracle}/
pathelement path=${srcmain}/
pathelement path=${servlet}/
pathelement path=${avalon}/
pathelement path=${cocoonlib}/
pathelement path=${xalan}/
pathelement path=${xerces}/
pathelement path=${log}/
pathelement path=${datasource}/
pathelement path=${pool}/
pathelement path=${junit}/
/classpath
/javac
copy todir=${ejbbuild}/org/stjude
fileset dir=${src}/org/stjude
patternset
include name=ct/ct.properties/
/patternset
/fileset
/copy
/target
target name=compileMain depends=compileEjb
javac srcdir=${src} destdir=${build} debug=${debugmode}
classpath
pathelement path=${ejbbuild}/
pathelement path=${ujc}/
pathelement path=${servlet}/
pathelement path=${oracle}/
pathelement path=${jdom}/
pathelement path=${avalon}/
pathelement path=${cocoonlib}/
pathelement path=${xalan}/
pathelement path=${xerces}/
pathelement path=${log}/
pathelement path=${datasource}/
pathelement path=${pool}/
pathelement path=${junit}/
/classpath
/javac
copy todir=${build}
fileset dir=${src}
patternset
include name=**/*.properties/
include name=**/*.xsl/
include name=**/*.xml/
/patternset
/fileset
/copy
/target
target name=deploy depends=compileMain
!-- jar main EJB files --
jar jarfile=${ear}/gunk.jar
fileset dir=${ejbbuild}/
/jar
!-- war main Web files --
war
RE: Cocoon is complex, but worth it! Some Answers to your dilemma
For what it's worth, I walked through the steps for building the minimal war he was looking for on Saturday, sent him the binary war (5 meg) and posted the steps on the wiki. He's already written a first custom generator that connects to his ejbs and seems much happier now. He's started to refer to cocoon as we! :) Some of that happened off list, so I thought it worth sending in a quick update. Yes, I saw that. I'm only now catching up with the 280 e-mails I had this morning: that's what I get for being off-line all weekend; new baby girl at home, who has time for computers :-) I do agree, Peter that many people will not see a need right away to strip things out, but a great point that Robert made is that the flip side of keeping the expanse of possibilities visible to a new user is that it's quite difficult to figure out what's essential and what's not: especially for the ejb world where logic and data access are already well encapsulated. Really the biggest issue for me as a new Cocoon users was the sitemap; you get told to look at the sitemap since everything is controlled by the sitemap. Then, once you look at the sitemap you wonder what the heck is ALL this stuff? A WAR packed full of tons of JARS I can ignore, but Cocoon isn't going to do me much good unless I can comprehend the sitemap. The flip side top this is that if you have a minimal sitemap then there is no good way to learn the features of Cocoon incrementally. Once you've got things working with Cocoon what is going to make you look at other Coccon components to see if you can extend things with Cocoon instead of re-inventing the wheel? You spend a bit of time looking, but there is so much to look at it's often easier to just incrementally add to your own code one bit at a time. Next thing you know you've reinvented the Castor transformer (or whatever)... - 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]
RE: proposal: The Newbies Competence Center
Hrmm... this gives me an idea, tell me if you follow along: Cocoon was developed with SoC in mind. You have the content separated from the style, and you have the logic of the site separated from the content. So, instead of trying to define what a user is and what a developer is, we should define the different roles that a person would have when using or developing with Cocoon. Yes please, this sounds like a very good idea. - 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]
RE: proposal: The Newbies Competence Center
Ideally, all of these roles work together in order to get things done, but they only have to worry about their specific role. I have come to believe this is a fairy tale. No individual in a development group, in my opinion, can *ever* worry about just their role. They can specialize on their role, but you can't make a rigid wall here. Maybe as Cocoon (and more specifically, Cocoon's best practices) matures, this may get better. Ahh, but that's the beauty of role based documentation: you're not forcing people into a particular role. You're just saying when performing this role, here's where you find the information about how to do it. If people switch roles or don't fit into a particular role they still have a clue where to look in the docs... snip/ I think this is a bad idea for the reasons stated above. Since it's Super Bowl season here in the U.S., I'll use a (American) football analogy. Before Cocoon, in the heady days of just JSP, ASP, and PHP, it was a pickup game at the park. The role of quarterback is constantly changing who it applies to and everyone's scrambling in all different directions. People generally enjoy themselves and are hostile to the idea that people should be assigned roles and stick with them. So, who is assigning roles? No one, it's just the docs tell you how to perform a given role... - 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]
RE: Hello and question
Here's the context: We have several hundred thousand time series, but they will, for the foreseeable future, remain in their present repository (the Fame time series database application.) However, there are a few hundred series which our staff use regularly, and which they need to query, graph, plug into reports, save as PDFs, import into spreadsheets, etc. By and large, the Cocoon framework seems like a promising way of providing these multiple views of the data. At this early stage in our planning, we're considering a mechanism whereby these few hundred series are dumped from Fame into XML, one file per time series. We explicitly don't want to dump the data into some intermediate format (e.g, Oracle or whatever), because Fame will remain the core database. I suppose that you can't hit Fame (whatever that might be) directly? Or that you are afraid of the load that hitting Fame directly would put on the system? I don't really see why dumping the data into Oracle or whatever is any different from creating an intermediate XML file? They are both data stores... You need to determine what the functional requirements are in terms of performance and querying and let that determine the technical architecture and not just pick operating system managed XML files arbitrarily. However, either way Cocoon still may be a good fit; it can handle output from an relational database (with JDBC) almost as easily as handling an XML file directly and if you have to create the XML from scratch it probably makes more sense to do that with Cocoon instead of using some other external tool to do the job. - 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]
RE: 10 basic survival tips for cocoon users (was: Logicsheet problems - global XSLT variables)
4.) Proceed in baby steps when changing things in your cocoon app But it really slows up development Doing incremental development will ultimately save you many many, days of lost productivity. The biggest roadblock is having sufficiently powerful hardware that doing many compiles and redeploying Cocoon doesn't cost you a lot of time. Splurging for the best hardware you can afford will likely pay itself back very quickly in time savings... For XSLT changes it's usually simple to proceed in baby steps since you can usually edit the live sheets and resubmit the page and immediately see the results. In addition you can break your pipelines into pieces so that you can capture the output XML and feed it into something like XML Spy or Xselerator and debug your XSLT that way. - 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]
RE: [HELP]indent can not be multiply defined at the same import level! Old value = no; New value = yes
Title: Message I'd guess that you have an "include" in one of your XSLTs andthat you have the "indent" attribute set to "no" in the base, and "yes" in the included stylesheet. It's not a Cocoon problem, but the parser chokes on it... Description:org.apache.cocoon.ProcessingException: Exception in creating Transform Handler: javax.xml.transform.TransformerException: indent can not be multiply defined at the same import level! Old value = no; New value = yes I see that there's something wrong, but that's all. I don't have any idea what this message is talking about. I don't knowwhat it is talking about and WHY, and, more important, what i must DO to correct this error. Hmmm., I wonder wheter it's a good idea to tell people what's wrong instead of telling them what to do to get it up and running ;-). Please help. Thanx.
RE: EJBs and Cocoon (hmm, again ;-)
So the question is: does anybody already have a decent solution for the EJB-Cocoon problem? Or isn't there any problem at all... Umm, what problem? If you want EJB's you go ahead and use them... What's your environment? We use JBoss and create an EAR with Cocoon as a WAR inside it and the EJB's in a JAR inside the EAR. Jboss auto deploys everything -- the EJB's according to our deployment descriptors -- and we then use the remote interfaces as normal from the code running on the Cocoon side of things. - 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]
RE: Pipeline problem
How solve my problem ?
How trace data between two transformers :
- between ldap and xslt
- between xslt and annuaire...
You can always comment out part of the pipeline temporarily and view the
output directly. Eg:
map:match pattern=hub/integration/*
map:generate src=hub/integration/{1}.xml/
!--
map:transform type=ldap/
map:transform src=hub/LDAP2Group.xslt type=xslt/
map:transform type=annuaire
map:parameter name=use-connection value=annuaire_datasource/
/map:transform
--
map:serialize type=xml/
/map:match
Note that the serialize is now told that it's sending XML to the browser...
You can then capture the output XML from the browser and cut and paste into
your favorite XSLT debugging tool (assuming you have a standard XSLT), or
just use it as a reference while editing the XSLT. As you get each
transform working you move the comment down:
map:match pattern=hub/integration/*
map:generate src=hub/integration/{1}.xml/
map:transform type=ldap/
!--
map:transform src=hub/LDAP2Group.xslt type=xslt/
map:transform type=annuaire
map:parameter name=use-connection value=annuaire_datasource/
/map:transform
--
map:serialize type=xml/
/map:match
-
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]
RE: Confused about xsl:include
Not 100% sure, but in my (humble) opinion, you can only call included templates and no longer use apply. Nonsense... Apply-templates works just fine with included templates. What's missing from the included code is the place that the apply is invoked so we can't tell if it's being done correctly. It's also possible that some other template with higher precedence is matching first. - 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]
RE: Confused about xsl:include
The above template match=title works fine if I paste it into the main xsl file. But if instead, right there in it's place, in the main xsl, I put this: xsl:include href=stylesheets/other.xsl/ to include the above file, the match is no longer applied in the output. I'm perfectly open to other ways of doing this. I'm just getting started. So in-other-words there is no main matching template in the XSL doing the include? It sounds like the default template in the primary is being picked up and it of course is not ever going to apply your included template. This isn't a Cocoon problem, you can test your code in any XSLT debugger/editor (Xslerator for example). Spend some time at http://www.mulberrytech.com/xsl/ and check out the list archive there (search on default templates)... - 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]
RE: starting cocoon with windows 2000
You should use 2.0.3 instead - it is the easiest version to install so far. Personally, I'd go with JDK 1.3.1, however, 'cause you'll have to recompile some jars for JDK 1.4. 2.0.3 works just fine with JDK 1.4 with no recompilation of jars required. Just make sure you get the version that has been compiled for 1.4! - 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]
RE: inserting doctype from xsl
There's more than one doctype you could have for HTML. Some folks may want to send HTML 3.2 with the appropriate header. It would be possible to have all of the doctypes ready to go out of the box. It would also mean a html32 serializer, a html4 serializer, a html401 serializer, etc. and that's not counting the transitional/strict/frameset qualifiers. Seems a lot to have in the default sitemap when most people would only use one or two at the most. It would probably be reasonable to include a commented out example in the default sitemap? map:serializer logger=sitemap.serializer.html mime-type=text/html name=html pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.serialization.HTMLSerializer buffer-size1024/buffer-size doctype-public-//W3C//DTD HTML 4.01 Transitional//EN/doctype-public /map:serializer shouldn't it be inserted by default in a default sitemap from the cocoon installations? should we write this to the developers mailing list? - 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]
RE: java.lang.OutOfMemoryError
After I've made the changes, I don't seem to get the OutOfMemory exception anymore, but the site still runs extremely slow. The TaskManager shows CPU usage at 100%, which I suspect is due to memory to disk swaps. Can't help you, but if it's swapping then almost certainly you won't peg CPU at 100% (unless you've got some kind of supernatural disk subsystem). If you really only have 96M of Ram on your box it's time to upgrade. That won't even support Win2K decently... I'd start at 512M and go up if you can afford it! - 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]
RE: Cocoon and EJB
Would you mind integrating it into the CocoonWiki (http://www.outerthought.net)? If no and it's easier for you I can do it for you. Reinhard, go ahead and add it if you wish; everything in the document is based on stuff from the Cocoon-user archives, with some modifications. As I said, it's a bit out of date, anyone who is currently attempting this might be able to bring it up to date as they work through it. Also, I strongly suspect that the section on working with Oracle isn't 100% accurate, but I haven't spent anytime trying to determine if this is true. http://outerthought.net/wiki/Wiki.jsp?page=JBossDeployment Reinhard Cool. The pre tags used for the sample code doesn't wrap (sensibly enough). Since some of the sample lines are extremely long the result is that the rest of the content runs off the right hand side of the browser as it flows to the logical line length. I guess there are two ways to fix this: 1) break the sample code in some logical spot, 2) use a CSS rule that causes the rest of the information to have some sensible right hand boundary (should be percentage based, but can't be 100% since the left hand menus take up some room). This problem seems common across the Cocoon Wiki (at least with IE 6.1) so solution 2 is probably the best since then all pages using the CSS will format reasonably without the requirement to manually format every piece of sample code. - 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]
RE: XMLForms vs Struts
I'm beginning to design a small system for my company and I need some forms to input/output data. How small? Given that you are posting on Cocoon-users I assume you are considering using Cocoon though you don't specifically mention it. The general consensus seems to be that Cocoon isn't really suited for small sites/systems. However, if you have a lot of dynamic rendering, or multiple browser issues (egg. graceful degradation of multimedia), or multiple output format requirements it still might make sense. I wanto to use open software for the project. I read about frameworks like struts, xmlforms and perhaps others. However, I don't know how to decide the technology to use. Since XMLForms and Struts aren't directly comparable (they work at very different levels and do very different things) we really need to know more about your requirements: How many users? How many pages? How many forms? If you can't give us high level requirements how about low level requirements: Do you need database support? Do you need EJB support? Do you need XML support? Do you need Web services support? Do you need LDAP support? Recommending a particular web technology implementation without having specific requirements is sort of like recommending a vehicle without knowing whether the person really has requirements for a car, truck, train, airplane or boat... - 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]
RE: XMLForms vs Struts
I'm sorry. It's a kind of help desk in our intranet where the users can: 1) Request technical assistance (input) 2) Query the status of their previous requests 3) Query a DB where any user can look at common problems/solutions We have 500 total users. I think there could be 10/20 users (max) using the app simultaneously. We are not planning to use EJB, WS or LDAP. We have been considering to use a relational DB (Oracle). There are commercial applications for this very purpose, so I'm not sure why you're looking at building this yourself? However, given that you are, I'd guess you have no need for multiple language support, no need for eventually scaling the thing to support a lot of users, and no need for multiple browser support. As such, Cocoon is likely overkill. It's not even clear that you need much of a flexible controller structure (any dynamic work flow?), but Struts won't do you any harm. Otherwise this could just be a simple JSP site or just HTML with Servlets... If you have control over the browser you might want to look at DHTML or client side XML/XSLT with CSS just to keep presentation separated a little better. Personally, I'd likely go with a client side XML/XSLT and Servlet implementation, but I don't know if your shop can handle the XSLT authoring (it's a bit of a paradigm shift from Java coding)? I also don't know what other infrastructure I'd add to the mix without knowing the requirements better. - 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]
RE: Empty anchor tags
Thanks, it works now. Should follow the specs. Wasn't a name=foo valid in HTML 4.0, though? Id is better anyway, it's more generic. It's still valid, from the same document: http://www.w3.org/TR/html401/struct/links.html#h-12.2.1 You can use either name or id, but the name has to be unique. a name=foo Whooa, that would be a spec violation, IIRC... :-) Called with: a href=#foolink to foo/a This doesn't work with IE: a name=foo/a Unless I missed something I don't think there is an obvious reason one should work and the other not work... - 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]
RE: Cocoon and EJB
Would you mind integrating it into the CocoonWiki (http://www.outerthought.net)? If no and it's easier for you I can do it for you. Reinhard, go ahead and add it if you wish; everything in the document is based on stuff from the Cocoon-user archives, with some modifications. As I said, it's a bit out of date, anyone who is currently attempting this might be able to bring it up to date as they work through it. Also, I strongly suspect that the section on working with Oracle isn't 100% accurate, but I haven't spent anytime trying to determine if this is true. -Original Message- From: Hunsberger, Peter [mailto:Peter.Hunsberger;stjude.org] Sent: Friday, October 25, 2002 4:59 PM To: '[EMAIL PROTECTED]' Subject: RE: Cocoon and EJB I have a doubt whether it is possible (and easy :) to fetch data from EJB (connected to a DB) and produce HTML pages from both XML/XSL documents and these data. Despite Michael Homeijer interesting answers, there were not many responses, and it seems to me there are never a lot when it comes to EJB and Cocoon. As I am also interested, is really nobody out there who knows much more about it...? Are there any resources available focusing on EJB and Cocoon? Don't know about resources, but I also don't really see what the issue is? In our case we use JBoss with Tomcat and Cocoon. We define the EJB resources through JBoss and don't worry about them in Cocoon. We then package up the Cocoon WAR with our EJB JAR into a EAR and deploy it under JBoss. With the proper JNDI definitions in JBoss all is done; your Cocoon classes see the EJBs and away you go. It took me perhaps a week of fiddling to get this going, but the magic trick is to make sure you've got all the classes in the proper places for the particular combination of Tomcat, JBoss, JDK and Cocoon. Following is a summary of various messages I've found that I used to create some basic instructions for our developers on how to get the whole thing up and running. Some of this is out of date, since new binaries are now available that did not exist when I wrote this and life is now a bit simpler. How to deploy Cocoon on JBoss and Tomcat 1. Deploy tomcat/jboss. Versions 4.0/2.4.3 are apparently known to work. We use 4.0.4 and 2.4.4. Note that according to the Cocoon2 homepage certain beta versions of Tomcat dows not work with Cocoon2. To deploy Tomcat 4.0.4 use the integrated 2.4.4/4.0.1 Tomcat/Jboss then copy a Tomcat 4.0.4 install over the catalina directory structure in the Jboss/Tomcat install. If you do this, I'd rename the base directory to help keep things straight as to what is installed. 2. Add environment variable CATALINA_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7070. This is to be able to debug java run in Tomcat. For Netbeans 3.2.1 for programming/debugging (remember to add port 7070 to debugging environment). 3. Delete in [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/lib following: -crimson.jar -jaxp.jar -xml.jar (xml.jar is not present in latest versions of JBoss.) If Tomcat 3.x is used the following files must be also be deleted: from [your path]/JBoss-xxx_Tomcat-3.x/tomcat/lib: -parser.jar -jaxp.jar 4. new run.bat file in [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/bin to: @echo off @if not %ECHO% == echo %ECHO% @if %OS% == Windows_NT setlocal set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;run.jar REM Add all login modules for JAAS-based security REM and all libraries that are used by them here REM need one of the two following lines for xerces support set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/xerces.jar REM set JBOSS_CLASSPATH=$JBOSS_CLASSPATH:../lib/xml-apis.jar REM Add the XML parser jars and set the JAXP factory names REM Crimson parser JAXP setup(default) REM set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/crimson.jar REM set JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson .jaxp.Docu men tBuilderFactoryImpl REM set JAXP=%JAXP% -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXPa rserFactor yIm pl echo JBOSS_CLASSPATH=%JBOSS_CLASSPATH% java %JAXP% -classpath %JBOSS_CLASSPATH% org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 pause 5. If you want to be able to debug JBoss/Tomcat/Cocoon2 replace the last line (before pause) with: java -Xint -Xdebug -Xnoagent -classpath %JBOSS_CLASSPATH% -Xrunjdwp:transport=dt_socket,server=y,address=12999,suspend=n org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 If you use Netbeans 3.2.1 for programming/debugging remember to add port 12999 to debugging environment. 6. copy xerces.jar to [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/lib. We used versions 1.4.3. Download xerces binary and use .jar file in the downloaded xerces_xxx.zip
RE: Cocoon and EJB
I have a doubt whether it is possible (and easy :) to fetch data from EJB (connected to a DB) and produce HTML pages from both XML/XSL documents and these data. Despite Michael Homeijer interesting answers, there were not many responses, and it seems to me there are never a lot when it comes to EJB and Cocoon. As I am also interested, is really nobody out there who knows much more about it...? Are there any resources available focusing on EJB and Cocoon? Don't know about resources, but I also don't really see what the issue is? In our case we use JBoss with Tomcat and Cocoon. We define the EJB resources through JBoss and don't worry about them in Cocoon. We then package up the Cocoon WAR with our EJB JAR into a EAR and deploy it under JBoss. With the proper JNDI definitions in JBoss all is done; your Cocoon classes see the EJBs and away you go. It took me perhaps a week of fiddling to get this going, but the magic trick is to make sure you've got all the classes in the proper places for the particular combination of Tomcat, JBoss, JDK and Cocoon. Following is a summary of various messages I've found that I used to create some basic instructions for our developers on how to get the whole thing up and running. Some of this is out of date, since new binaries are now available that did not exist when I wrote this and life is now a bit simpler. How to deploy Cocoon on JBoss and Tomcat 1. Deploy tomcat/jboss. Versions 4.0/2.4.3 are apparently known to work. We use 4.0.4 and 2.4.4. Note that according to the Cocoon2 homepage certain beta versions of Tomcat dows not work with Cocoon2. To deploy Tomcat 4.0.4 use the integrated 2.4.4/4.0.1 Tomcat/Jboss then copy a Tomcat 4.0.4 install over the catalina directory structure in the Jboss/Tomcat install. If you do this, I'd rename the base directory to help keep things straight as to what is installed. 2. Add environment variable CATALINA_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7070. This is to be able to debug java run in Tomcat. For Netbeans 3.2.1 for programming/debugging (remember to add port 7070 to debugging environment). 3. Delete in [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/lib following: -crimson.jar -jaxp.jar -xml.jar (xml.jar is not present in latest versions of JBoss.) If Tomcat 3.x is used the following files must be also be deleted: from [your path]/JBoss-xxx_Tomcat-3.x/tomcat/lib: -parser.jar -jaxp.jar 4. new run.bat file in [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/bin to: @echo off @if not %ECHO% == echo %ECHO% @if %OS% == Windows_NT setlocal set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;run.jar REM Add all login modules for JAAS-based security REM and all libraries that are used by them here REM need one of the two following lines for xerces support set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/xerces.jar REM set JBOSS_CLASSPATH=$JBOSS_CLASSPATH:../lib/xml-apis.jar REM Add the XML parser jars and set the JAXP factory names REM Crimson parser JAXP setup(default) REM set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/crimson.jar REM set JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.Docu men tBuilderFactoryImpl REM set JAXP=%JAXP% -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactor yIm pl echo JBOSS_CLASSPATH=%JBOSS_CLASSPATH% java %JAXP% -classpath %JBOSS_CLASSPATH% org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 pause 5. If you want to be able to debug JBoss/Tomcat/Cocoon2 replace the last line (before pause) with: java -Xint -Xdebug -Xnoagent -classpath %JBOSS_CLASSPATH% -Xrunjdwp:transport=dt_socket,server=y,address=12999,suspend=n org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 If you use Netbeans 3.2.1 for programming/debugging remember to add port 12999 to debugging environment. 6. copy xerces.jar to [your path]/JBoss-2.4.3_Tomcat-4.0/jboss/lib. We used versions 1.4.3. Download xerces binary and use .jar file in the downloaded xerces_xxx.zip The Apache site suggests that you should copy xml-apis.jar from cocoon/lib/core/ to jboss/lib. However, I did not have to do this. If you think you need xml-apis.jar you may also want to uncomment the line in run.bat that refers to it and comment the line that uses xerces. Only one of these should be needed... 7. add environment variable TOMCAT_HOME=[your path]/JBoss-2.4.3_Tomcat-4.0/catalina/ (if a Tomcat 3.x version is used catalina must be substituted with tomcat). This is for use with Cocoon ant file: build.bat. 8. Test that JBoss/Tomcat starts up and responds on port 8080/jboss Contrary to some documentation the test application still works fine. Cocoon and Java 1.4 configuration - Cocoon requires more recent versions of the Xerces and Xalan libraries than those shipped with
RE: Link Livesites:
I'm just setting up a new site which is dedicated to using Domino and Apache Cocoon. It's due to go live by the start of next week. Before you go live you may want to make sure that thepage background is set to white for all pages. As it is, it defaults to the browser background which may not be white. In that case looks rather like someone pasted togethergraphics fragments into a scrap book...
RE: ServerPageAction: XMLFragment reuse in XSL transformer
There's probably about half a dozen ways to do this. Perhaps one of
the simplest is just to create your own caching generator and use aggregation
(with any other XML you may need)in the pipeline.
In the
generator you'll need to implement the setup method to see the objectModel,
something like the following:
private gunk mySessionData = null;
public
void setup( SourceResolver resolver, Map objectModel, String src, Parameters
parms ) throws ProcessingException,
SAXException, IOException {
if (mySessionData == null )
{
super.setup(
resolver, objectModel, src, parms );
Request request =
(Request)ObjectModelHelper.getRequest(objectModel);
Session session =
request.getSession(false);
if (session != null) {
//
save a pointer to your session data for use in the generate
method
mySessionData =
}
} }
Now in
your generate method just pick up whatever data hangs off of "mySessionData" and
away you go
-Original Message-From:
Christian Kurz [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 17, 2002
11:26 AMTo: [EMAIL PROTECTED]Subject:
ServerPageAction: XMLFragment reuse in XSL transformerHello cocoon-users,
I need to generate some tiny XML elements
(XMLFragment) within a ServerPageAction and I would like to use this
XMLFragment later on in an XSL transformer, that is fed by an xml generator.
The XMLFragment captured in the ServerPageAction is
basically saying, which nodes are to be returned from the big input
document.
From some other message in this group I have
understood, that passing objects is only possible through session or request
objects, but not through sitemap variables. I don't like to use a request
generator as the starting point of the pipeline, as I'd loose cacheability at
a very early step in the pipeline.With a quite bigxml input
document,this does not seem a good idea to me.
So I am currently struggling how to get a piece
of XML, that isattached to a session or request object, into the xsl
transformer. Has anybody tried this before e.g. using an XSL
extension?
Any help or hints appreciated!
Thank you in advance,
Christian
RE: ServerPageAction: XMLFragment reuse in XSL transformer
Well,
obviously, it something changes on every request then, by definition, it isn't
cacheable. However, I believe, with aggregation, only the components that
are marked as invalidated in the cache are rebuilt on a new request; the rest of
the data stays in it's respective cache. This does mean that the
aggregated document is rebuilt each time (I have no idea what the impact of that
would be). But the "large" document source would stay not be retrieved
from scratch.
Perhaps using the document function as Olivier would avoid this. At
one point document did notcheck cache validity at all and you would only
get a newer version of the data if the main data was invalidated in cache. I
think this has been fixed in 2.0.3. The problem is how to get the URI
resolve for the document function to fund the data in session. Someone
else will have to tell you how to do that (and if it's even
possible)...
-Original
Message-From: Christian Kurz
[mailto:[EMAIL PROTECTED]]Sent: Friday, October 18, 2002 1:42
AMTo: [EMAIL PROTECTED]Subject: Re:
ServerPageAction: XMLFragment reuse in XSL transformer
Thank you very much for the quick feed-back!
The idea sounds great and is a lot cleaner,
than fiddling something in someXSL extension.
I am not sure about the cachaebility: the
XMLFragment specifying, which nodes to filter from the big input document,
changes everytime, so Cocoon would need to parse the source file on every
request (, if my understanding is right).
If I'd slidely change your approach to
implementing the same approach into a transformer component. This transformer
component will not be cacheable, but at least the generator in front of it
would be.
Thanks again,
Christian
BTW, thanks also for the code snippet. It helps a
lot, as soon as it comes to thinks like the ObjectModel, I start feeling
uncomfortable.
- Original Message -
From:
Hunsberger, Peter
To: '[EMAIL PROTECTED]'
Sent: Thursday, October 17, 2002 6:46
PM
Subject: RE: ServerPageAction:
XMLFragment reuse in XSL transformer
There's probably about half a dozen ways to do this. Perhaps
one of the simplest is just to create your own caching generator and use
aggregation (with any other XML you may need)in the
pipeline.
In
the generator you'll need to implement the setup method to see the
objectModel, something like the following:
private gunk mySessionData = null;
public void setup( SourceResolver resolver, Map objectModel, String
src, Parameters parms ) throws
ProcessingException, SAXException,
IOException {
if (mySessionData == null )
{
super.setup(
resolver, objectModel, src, parms );
Request
request =
(Request)ObjectModelHelper.getRequest(objectModel);
Session session =
request.getSession(false);
if (session != null) {
//
save a pointer to your session data for use in the generate
method
mySessionData =
}
} }
Now in your generate method just pick up whatever data hangs off of
"mySessionData" and away you go
-Original Message-From:
Christian Kurz [mailto:[EMAIL PROTECTED]]Sent: Thursday, October 17,
2002 11:26 AMTo: [EMAIL PROTECTED]Subject:
ServerPageAction: XMLFragment reuse in XSL transformerHello cocoon-users,
I need to generate some tiny XML elements
(XMLFragment) within a ServerPageAction and I would like to use this
XMLFragment later on in an XSL transformer, that is fed by an xml
generator. The XMLFragment captured in the
ServerPageAction is basically saying, which nodes are to be returned from
the big input document.
From some other message in this group I have
understood, that passing objects is only possible through session or
request objects, but not through sitemap variables. I don't like to use a
request generator as the starting point of the pipeline, as I'd loose
cacheability at a very early step in the pipeline.With a quite
bigxml input document,this does not seem a good idea to
me.
So I am currently struggling how to get a
piece of XML, that isattached to a session or request object, into
the xsl transformer. Has anybody tried this before e.g. using an XSL
extension?
Any help or hints appreciated!
Thank you in advance,
Christian
RE: Cocoon Connection Pooling and Database Shutdown
Why should I use carriage returns in my messages, Berin? So that we don't have to scroll on forever in one direction, and it makes it alot easier to interpose comments throughout your message--adding context to other people's response. Berin, what mail client are you using? Most have a configurable setting to tell them when to wrap long lines. I for one only put in CR/LF when starting new paragraphs; I've been using e-mail for some 20 years now (showing my age! ;-) and never had anyone complain... - 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]
RE: [Q] Pipeline best practices
Or put the most likely pipelines to get hit first and the least likely last... That can be problematic if your most used pipelines are the generic matches. Eg, three special cases and 100 general cases: match=fee.foe match=fee.fie match=fee.fum match= fee.* Probably ok with three special cases, but what about 20, or 50...??? - 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]
RE: Building a DOM Model with XMLForms
I'm working on a project prototype where I'm trying to implement a kind of wizard using XMLForms. The difference is that I'd like the XML docs written by the content people to define the resulting XML doc, without specifying it ahead of time. In other words, I'd like the elements attributes to be built by the XPath commands that originate from the XForm ref attributes. I'm using 2.1-dev, a fairly fresh snapshot. We've got a similar problem. I'm not using XForms/XMLForms due to the fact that I've got a historical code base and 2.1 isn't yet ready for production. However, let me describe what we're doing, a similar approach might be useful for you... In our case new forms are added daily. We have one group of people that define the meta-data for the forms (from which a DTD can be generated). We have another group of people who utilize this metadata to generate the actual forms (most screens/forms utilize only a subset of the possible fields). Given that this stuff changes daily we keep all metadata in a database. We're currently working on a GUI generator that will let the forms builder people build a skeleton XML description of a form using a (essentially) dynamically created DTD (from the metadata in the database). This XML is again stored in the database (as essentially form instance specific metadata specified as XML). At run time we generate the complete metadata for a given form back from the metadata and aggregate this with the stored XML form description to completely describe the form. In addition, at run we generate all relevant data from the database (in the same pass as the metadata generation), so that a complete metadata and data XML tree is available for each form element used by the form designers. An XSLT then merges these two trees to generate a new set of nodes which is used by a separate presentation XSLT pass to actually generate the form. I think, in your case something similar would be possible: aggregate the GUI designers XML description with a (possibly transformed) XForms DTD (which you may have to create?) via an XSLT, then feed this to the actual XForm transformer? - 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]
RE: Stuck on Hello World, with non-FAQ Problem
I also don't understand why the other Cocoon pages still come up after I deleted ALL the other stuff inside the map:pipelines tag other than my map:pipeline for the Hello World example that generates from helloworld.xml, transforms with helloworld2html.xsl and serializes the output. That tends to suggest that the copy of Cocoon you are modifying isn't the same one that Tomcat is running... How are you deploying Cocoon (expanding the EAR manually and copying?)? BTW, to answer another question you had earlier, the reason you see sitemap.xconf in multiple directories is that a parent sitemap can mount sub-sitemaps. It's a parent child relationship from the main sitemap... - 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]
RE: Why is my cocoon app an IE6 killer?
When accessing a - servlet generated site - with (lots of) images - using a recent versions of Internet Explorer (i.e.6) on windows then IE stops loading images. And even better: from this moment on it generally doesnÂ’t display images anymore, even from other sites until you restart IE. I can confirm that you've still got the problem with IE 6 and SP1... Though you don't explicitly state it, it sounds like if the same page is servered as static HTML it renders properly? If so, it's just a guess, but one possibility would be that there's a difference in the HTTP handling. Perhaps the servlet engines are negotiating HTTP 1.0 vs. 1.1 for static pages or vice versa? In such a case perhaps the servlet engine has a bug and doesn't close the image streams exhausting some resource on IE? Or similarly, perhaps it's an IE bug of the same type. It seems to me the first place to look would be to see what the HTTP headers have to say, though you may have to get pretty low level to see what the differences might be. - 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]
RE: [C2.1-CVS] Problem using 2 pipelines
I saw that many people in thi maillist prefer make XSLT tranforms and few people use XSP. Why? A couple of reasons why I avoid using XSP: 1) It's more or less proprietary (though that is sort of changing). XSLT can be run with many different application servers. 2) XSLT is functional programming and thus lends itself well to rule based processing. XSP is (mostly) procedural programming and in some ways isn't as well suited for the job of sorting and merging tree nodes. Putting point two differently: XSLT is designed specifically for manipulating XML. Java is a general programming language not at all specialized for handling XML, XSP only partly bridges the gap. My personal approach is to try and write generic XSLT for general tasks: eg. filtering the contents of a XML tree based on the contents of a second tree; merging the attributes of two XML trees with similar node names. I then use these as building blocks to create more specific tasks: filtering an XML tree based on what a user is authorized to see; adding presentation attributes to a nodeset based on the final use of the XML. In this way, I can write XSLT that is driven by XML rules that just about any one can author (and maintain). If I was writing XSP and the business rules changed making similar changes would be (I believe) a much harder process. In our case we have (literally) 1000's of business rules to implement, any of which can change on a weekly basis (such is the nature of clinical trials). So having an easy way to dynamically build up applications based on business rules is important to us. If your application is more static and processing speed is more of an issue then a different architecture may make more sense for you. Somewhat off topic, but a general rule at how to pick a particular way of implementing systems: With any large application it's always a good ideas to first build up a conceptual systems architecture based on business requirements. Then build a logical architecture -- based on both the conceptual architecture, the current state of your business and application specific requirements -- before you pick a physical architecture. Only once you have a physical architecture should you start to match up a physical implementation (detail design) with the physical architecture. I know this sounds like a lot of analysis, but its been shown that if you can hit the target of 1/3 analysis, 1/3 development, 1/3 testing, your project life cycle will be much shorter than if you have other proportions of analysis to development and testing... - 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]
RE: [C2.1-CVS] About XSP
I know that XSP is not only attached to Java, there are implementation of XSP using perl, for example AxKit. And into Cocoon there are impletations in Java, Javascript and Python. The 2 question is hw about performance? What of both makes it faster? Sorry, can't help you there. I should have probably stated the issue more like the procedural languages currently implemented for XSP are not specialized for handling XML... Putting point two differently: XSLT is designed specifically for manipulating XML. Java is a general programming language not at all specialized for handling XML, XSP only partly bridges the gap. Maybe yes, but into the apache website there is writen they recomend the use of XSP to create and update data in a database while the use XSLT to retrieve it. That sounds like a good division of labor. The alternative is to either use XSLT extensions (again somewhat proprietary) or do everything in an action handler, which necessitates Java in any case and has it's own maintainability issues. In our case, all data is managed through EJBs and a proxy layer already exists. As such, doing database manipulation from an action handler is relatively straight forward and transparent. We do use XML and XSLT to run validation rules on the data before forwarding it on to the EJBs. This is managed by the action handler running a transform under the covers. This is one area in which I consider Cocoon to be a little weak: you really need to be able to run a transform as an action handler directly from the pipeline. I've been starting to look at what it would take to make this happen; in general I keep coming back to making the whole pipeline a transform that includes other transforms; the pipeline transform being passed the current context as an XML nodeset. A third possibility exists which is the Castor transformer approach. Haven't had time to explore it but it has some appeal from a theoretical point of view. My approach is use the 2 techologies. I am not against XSLT since I use it after the XSP generator give to the pipeline the data. Mainly to make some changes with custom a XSL to prepare the aoutput before the serializer makes the endwork. Again, that seems like a good way to separate concerns. In particular you might want to see if you can make your XSP/XSLT pipeline such that the XSLT could, in theory, work with the same XML generated some other way (than the XSP). - 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]
RE: web app design
This framework will be for small business or medium business and to construct and publish their corporative webs. Just this constraint alone will get you a long way towards creating some performance targets and usages numbers: You can make an assumption about the max. number of users in a company (possibly adding some users for extranet type usage if applicable). From there you can make some assumptions about max. simultaneous users based on the application type. Using the first number you can make some estimates on max data based on application type times number of users. Using the second number you can make some assumptions about bandwidth requirements (max. users times data sizes in play at any moment). Now you've got some idea of your database size, # of simultaneous users, amount of data being accessed and generated. Next you need to make some assumptions about response time. Again, you know the application type (eg. generating credit card responses is way different than generating seismic analysis result sets) and should be able to come up with some reasonable numbers. This will allow you to estimate transactions per sec, page views per sec. etc. What you don't know is how Cocoon maps to any performance metrics; you can't do that without some real load analysis software and hardware. But at this point, that isn't really the issue: what you really want to estimate is whether a processing heavy architecture can handle the transaction requirements on some reasonable hardware (as defined what your company is comfortable supporting). If it starts to look like you've got a lot of transactions per second or a lot of page views per second with a lot of data per page view then maybe a pure Cocoon architecture isn't the best way to go. In my experience, apps targeted at small companies aren't generally an issue. App's targeted at 1000's of simultaneous users might start to get questionable (although that's our ball park with a mostly pure Cocoon architecture, albeit mixed with a good chunk of EJBs). We're targeting a single large database processor, a couple of EJB' servers and in the order of 10 front end web/app servers as the largest possible hardware config we will need (a couple of years out). However, our app splits nicely into small user communities that can be easily mapped to individual app servers. (Note that fail over hardware is a separate issue from the hardware needed for performance reasons). How to start? Create a spread sheet and fill in some guesses for max users, max. simultaneous users, largest data set sizes, required transaction response times. Validate the assumptions with as many people as you can. Now figure out, disk space usage, bandwidth, transactions per sec. etc. If these numbers are small, don't worry about the architecture much more. If they start to imply lot's of hardware invest some more time in validating the numbers. If you're still nervous after that you've got to start benchmarking - 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]
Passing unknown parameters through a site-map
I've got a situation where I've got to pass a bunch of parameters with
unknown names from a (Cocoon generated) HTML form through an action to a
standard Cocoon pipeline. There are certain parameters I don't want to pass
on to the stylesheet so I can't use
map:parameter name=use-request-parameters value=true/
However, I can, in my action selectively not copy the unwanted parameters
into the map (since they have well defined names). The issue is, how do I
then pass these onto the transform from the from the sitemap? Normally, I'd
do something like:
map:parameter name=gunk_data_id
value={gunk_data_id}/
to pass on individual parameters. In this case, since I don't know all the
parameter names I can't do that. I basically want to say, pass all the
parameters in the map returned from the action onto the transform (the
equivalent of use-action-parameters perhaps?)
Peter Hunsberger
Phone: 901-495-5252
E-mail: [EMAIL PROTECTED]
-
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]
RE: Passing unknown parameters through a site-map
Is there some reason which forces you not to copy the parameters wholesale? Otherwise, use use-request-parameters and simply ignore the parameters you don't want. Should have made that clear; if I pass all parameters I can clobber parameters where I don't want the values from the form. Also, not being able to filter out some specific parameters could potentially be a bit of a security hole (we are running generic parameter driven templates). I'd definitely require some way of being able to detect that a parameter was passed to me from the form and was also being set specifically by the sitemap... You can also try to override the wholesale parameter import by passing an empty string for the unwanted parameters That would cause problems when the value I really wanted was defaulted to something else in the stylesheet: I'd then get the wrong value... Since the pipeline is generic at this point I'd have to parse the stylesheet to figure out what the proper defaults are. You can use an internal pipeline with an request-generator and an XSLT to filter out unwanted parameters, and aggregate it to you main source: That could work, but the problem is that the parameters names are mapped to various meta-data and I don't know which ones I want and which ones I don't want until I examine the meta-data. Moving the management of the metadata into an XSLT would in effect mean moving converting a chunk of my action handler logic into an XSLT. Now, (as you may know, if you've caught any of my architectural discussions on the list) I am trying to head that direction anyways, so that's a good long term solution. However, short term this is a problem since we have cases where the action handler is already running a XSLT transform under the covers to evaluate rules on which metadata to pick up (evaluation of metadata about metadata): I'd have to generate the XSLT on the fly in order to filter the parameters properly and that doesn't seem like a very efficient way to get parameters into a stylesheet when all I really want to do is ignore some of them... A better possibility would be to create a custom request generator (moving the metadata handling from the action handler to the generator). This complicates the stylesheet somewhat since you going from being able to use global parameters to (at best) having to use XSLT keys to access the equivalent values. This strikes me as a good way to go except that it could also have performance implications? One of my long goals is, essentially, to replace the sitemap with an XML/XSLT combination that implements mapping as a dynamic rules based system. I'd like to hold off on doing that until I see how the 2.1 flowmap stuff shakes out... - 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]
RE: Passing unknown parameters through a site-map
That could work, but the problem is that the parameters names are mapped to various meta-data and I don't know which ones I want and which ones I don't want until I examine the meta-data. Moving the management of the metadata into an XSLT would in effect mean moving converting a chunk of my action handler logic into an XSLT. If your metadata is XML, you can aggregate it with the request parameters in order to filter them. That would be too simple :-) At this particular point in time the metadata comes from a relational database, which is why this particular data mapping problem is resolved using an action handler and not in an XML/XSLT in the first place... - 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]
RE: web app design
Related to cocoon it seems I need to do all this through generators or actions ( I think), but It not seems the proper way because all my required process will occurs out of SAX streams or related process (or I don't understand how to do it). Only in the load process my components will need to read some specific xml data for their configuration and initialization Also I will need my components make use of session management, caching, scheduling DB access and i18n ... should it manage it directly with java? cocoon? and/or avalon components? Raul, choosing a good application architecture even using just Cocoon can be difficult, never mind adding Avalon components to the mix. I think you need to tell us some of the performance criteria: how many users max? what kind of data set sizes? how many transactions per second, minute or hour (whichever is relevant)? The other thing that helps in this decision is knowing how dynamic the data is and where it is sourced: is every page built dynamically, or are pages mostly static? Is the data all XML, is some of it relational DB, or does some come from other systems via EJBs? If the answer is that performance scaling is not an issue and the data is all XML and every page is dynamic then a pure Cocoon solution would make sense. If the answer is that performance is going to be a big problem, the data comes from SJBs and everything is dynamic then pure Avalon components might make sense. If everything is static then just Apache might make sense... If you go with a pure Cocoon or mostly Cocoon implementation then I would push for a design centered around implementing business rules via XML and XSLT separated from data presentation (also based on XML and XSLT). This exploits the functional programming design of XSLT and minimizes procedural logic coding. This can be a hard thing to understand but is extremely powerful and flexible if you take the time to learn how to do it (a knowledge of LISP, Prologue and/or Haskell might help). In such a design you extract all business rules and all data as XML from various sources and use the business rule data to first transform the data according to the business rules (your interface contract) and then transform the data in a second pass as needed for presentation. If everything is dynamic you need to also code metadata to determine what real data must be extracted. This eliminates the need for logic-sheets and taglibs, using XSLT to filter the XML instead. You do end up coding Cocoon generators and actions to implement such a design, but they are mostly trivial; they create the XML and pass on or filter http response data as more XML for subsequent processing steps. If you're interested in pursuing this approach give me a reply back and I can likely dig up some old threads in the archives on the topic. - 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]
RE: web app design
My webapp is a vertical app on cocoon, specifically only oriented for Businesses who wants to base their e-comm-activity in CRM. You still didn't tell us your performance requirements, but this would suggest that the user community is small, or can at least be physically partitioned. As such, a pure Cocoon architecture should be viable. In this sense, the result should be a Cocoon but with enhanced services for the purposes mentioned, strongly based in cocoon but with developing future-jobs parallel to Cocoon because her high-specificity. There are people creating web services on top of Cocoon. There are also people creating publishing frameworks on top of Cocoon. Again search the mail list archives for these discussions. Neither of these areas are particularly mature in Cocoon (but then again, where are they?), so you'll likely run into some problems if you try to extend other initiatives. The one thing that it sounds like you will need is custom Cocoon serializers and transformers. A serializer or a transformer can grab the results of a transformation and do with it as it pleases. As such, they can, in a sense, replace the requirement for components implemented directly on Avalon... I'm not sure, but depending on your implementation time frame you might want to consider the Cocoon 2.1 fork instead of the 2.0 versions of Cocoon. Less stable, but I think they might fit your requirements a little better (can anyone validate this?). - 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]
Invoking Cocoon actions via JavaScript
One of our developers has run into an issue that I can't see an easy solution to. However, I also can't believe that no one else has run into the problem. We have a form where we are using IE 5.5 (and above) DHTML to enable drop and drag editing to reorder fields. As the result of a drop, we determine some positional values, place these values into the form and then attempt to submit the form to the server where the values will be placed in a database. In order to submit the form, the JavaScript code has to invoke the proper HTML action for the form, which is named using the Cocoon standard cocoon-action- format. Since JavaScript attempts to resolve the action name as an JavaScript object it eventually turns a string of this format into three object names separated by two minus signs and subsequently blows up trying to subtract non-existent JavaScript objects from each other. One obvious fix would be to change Cocoon to not use - in the action names. Given that this would break just about every Cocoon implementation in the world I'm hoping that someone has run into this before and found a work around on the JavaScript side of the world? Peter Hunsberger Phone: 901-495-5252 E-mail: [EMAIL PROTECTED] - 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]
RE: Pattern wildcards meaning
Samples provided with Cocoon dist. use path-like style to parameterize patterns, e.g. map:match pattern=*/* where, for instance, in sitemap administrator mind, 1st * is meaning source #1 and 2nd * source #2 (these wildcards beeing use to aggregate two sources). Why not use a more verbose pattern like: map:match pattern=aggregate[source1=*][source2=*] using an XPath predicate-like style? This way, you don't need to comment the pattern and everybody can immediatly understand it. Having not looked at the source URL this, off hand, strikes me as a bad idea; it exposes the (presumed) implementation of the URL to those calling it. What happens if the implementation changes from using an aggregation to using a named source and a named stylesheet? Does everyone have to go back and change all the calling URLs (or do you just live with URLs that have nothing to do with reality)? IMO, abstraction is a good idea when building web links. A specific implementation should be commented so those who need to know can understand how the implementation works, but everyday users should have such details hidden from them. I suspect, in this case, some of my comments may not apply, the calling URL may specifically name the source files as XML, but even then, I wouldn't necessarily want to expose any more about the implementation than I have to. - 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]
RE: DOMStreamer oddity
Any ideas why things would act differently in these two scenarios, given the fact that the input is apparently identical. Namespaces on one version of the XML and not on the other? (Perhaps only on the root element). - 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]
RE: sexy open source
OK_now_im_getting_personal_others_should_skip_this_tag Honestly, I went through stjude.org, nice idea, but if you'd decipher my nick, I'm quite uncomfortable with basic research exploiting animals with little or no actual use at all for all those unfortunate children - probably dictated by industry-driven NCI and others. I hope you work to catalogize only really valuable clinical research e.g. non-invasive statistical environment observation to help to discover most valuable prevention possibilities. Worth a quarrel between us... Moreover, I'm (fortunatelly) not the one giving money out here. Nevertheless, although miles away, you are looking like to be a suitable consultant for us with enough spare time. Wait till I discuss your possible involvement with those sitting on cash, then I'll contact you directly. Quick but informed expertise is awaited. /OK_personal_tag_is_over_though_not_well_formed I realize this is very far off topic, but this is important so please bear with me: I think you may have misinterpreted what St. Jude does. It is the leading institution in the world for research into Childhood diseases. Everyone that is treated here is treated regardless of their ability to pay, often for free. If you ever get a chance to see a 3 year old kid with operational scars all over their head, attached to an chemo IV drip looking as happy as can be because they've had just one more month to live you will never, ever, again feel sorry for the sacrifice of some animal in the name of clinical research. Most of these kids would not have a chance to live at all if it where not for St. Jude; we are now tracking 30 year survivors. Basic research is critical to the 1000's of children that we treat each year. Yes many animals may die in related experiments. They will do so painlessly and humanely. Many children will also die because we have not yet figured out how to save them. The clinical research is invasive, dirty, hands on real life medical research; that's the way lives are saved. Going on Yes please... [snip] You mean J2EE was too big calibre for your requirements but after you got into it, you wanted not to give up on possible features? In this particular case we probably won't have to scale to the point that we really need most J2EE features for another year or so. We could have held off on the J2EE learning curve until the rest of the application was more mature and stable. In particular, when you realize that many of our developers are contract and that they will have moved on by the time we really need the J2EE features. We paid to educate them on something we didn't necessarily need at the time. OTOH, we did get a core group of developers up the learning curve and we now have a running J2EE system to eliminate most of the learning curve for new developers. Accepted. Seems like solutions implemented in Cocoon are, at this stage of Cocoon in general, hardly universal enough to be taken over (even in part) by another business models. That's the deal, I think. Cocoon is easy to customize, but then it is hard to find reusable patterns, till some next evolution comes. I'm slowly starting to see a generalized architecture fall out of the work we do. It's rather different from what seems to be a main thrust of Cocoon (XSP), and it may be worth outlining: 1) exploit the ability of Cocoon to chain transformations together and separate transformations into separate passes of object assembly and output rendering; 2) separate and encapsulate the differing concerns of handling the application work flow into well defined XML: request parameters; application information (session level); object metadata specific to the current context; object data specific to the current instance. Use aggregation (conceptually within a single generator, or explicitly within the sitemap, exploiting caching) to combine these for the object assembly pass. 3) resolve (using XSLT) the combined application state data, session state data, request state data, object meta-data and object data based on the users current authorization into an abstract object tree populated with all information required to generate any output. 4) render the object tree to the currently required output format. This architecture exploits the functional programming model of XSLT and uses meta-data to essentially create rules about how to resolve and render the current object tree. If you get functional programming you will see that this keeps the basic processing model pretty simple and eliminates non-standard processing extensions (read XSP) from the flow. If you get stuck on procedural approaches and can't see how you'd ever give up your logic sheets you'll be missing much of the power of XML and XSLT in my opinion. We didn't start out with architected XML for each of these concerns and so hadn't thought about when and how to persist each of these pieces of information in a standard way. By instead
RE: sexy open source
Title: Message One could certainly argue that DB2 is as sexy or sexier than Oracle; the fact that Oracle 8 lacks true outer joinmakes it down right ugly if you ask me... In any case, my real reason for responding is to say that I would consider jBoss "sexy" anyone that's had to do a manual EJB deploy using something other than JBoss is likely to agree... -Original Message-From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]]Sent: Wednesday, August 14, 2002 8:11 AMTo: '[EMAIL PROTECTED]'Subject: RE: sexy open source subj was "sexy open source". I don't think that there's "sexy open source" RDBMS comparing to Oracle, or even MS SQL Server. Ok, Apache is sexy, comparing to IIS indeed. business doesn't care about opennes as much as about performance and features. Cocoon is sexy too, btw jBoss is not. -Original Message-From: Manos Batsis [mailto:[EMAIL PROTECTED]]Sent: Wednesday, August 14, 2002 9:09 AMTo: [EMAIL PROTECTED]Subject: RE: sexy open source Argyn, Err... the subject says "open source". I don't think there is a point in arguing about what sucks and what doesn't, so I just won't. Manos -Original Message-From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 4:05 PMTo: '[EMAIL PROTECTED]'Subject: RE: sexy open source RDBMS must be Oracle. no other options, imho. cost is not a problem. it's negligeable comparing to the cost of one DBA. while at the same time performance and other features of Oracle are far better than anything. 4) Business Logic Persistence Proposal: Firebird RDBMS as JBoss service jBoss sucks, imho.
RE: sexy open source
I don't care for JBoss that much but would like to
have J2EE for business logic scalability. My BIG
question is - HOW DO YOU ACCESS EJBs FROM COCOON?
Please, give us your secrets!
Didn't I just answer this? Nothing special is required: define your EJB's
to jBoss as normal. Deploy the EJBs along with the Cocoon servlet as part of
an ear through jBoss. The Cocoon code can then see anything in the EJB jar.
We mostly use proxy code to wrap the EJB references, but you could call them
directly from your code.
We do cache our EJB references using code like:
Foo foo = (Foo)EJBUtil.getFooBLHome().create().getFoo(fData);
Where EJBUtil has code like:
public static FooBLHome getFooBLHome()
throws BackEndException {
try {
return
(FooBLHome)ResourceFactory.getFactory().lookUpHome(FooBLHome.class);
} catch (NamingException e) {
throw new BackEndException(e.getMessage());
}
}
and ResourceFactory is just a singleton that keeps a hash map of the
references. No need to jump through these hoops if you're not pounding on
the EJB references a lot...
-
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]
RE: sexy open source
a) Did you ever try to migrate to JBoss 3x? JBoss 3 was still alpha when we started this release cycle. Jan./Feb. will be our first chance to consider using it. b) Do you have to write the proxies for every EJB manually or is there automatized solution? We manually write the code. 90% of the time it's just thin layer wrappers, but every once in a while there is some other encapsulation. In particular, polymorphic methods that all populate the same data class for retrieval but in different ways. There are some philosophical differences on how pure a proxy should be. Personally, I don't have a problem with a proxy interpreting my intentions with a slightly different implementation then I may be aware of. For me, that's one of the benefits of using a proxy. b) Are you able to use load balancing and other administration of JBoss fully with no negatives on running system? Pretty much so. However, currently all production deployments are still on Websphere with scheduled down time. This will change once the current release makes it to production, but so far there are no plans to build a hot fail over environment. d) Do the efforts with J2EE pay off really better performance and manageability against simple Tomcat approach according your experience? Architectures are based on business needs. (If you'd like to pay me to analyze your business requirements and determine the appropriate architecture for your needs I might be open to offers...) For our case the business requirements don't necessarily dictate a J2EE architecture and the learning curve was sufficiently long that knowing what we know now we might not have done it. However, having climbed the learning curve there is definitely no reason to go back. e) Do you use JBoss in any custom or standarized means also for authentification and authorisation for Cocoon resources or would it be too complicated to implement? We're doing custom authentication. We've looked at realm based authentication but we have a complex security model in a complex application and so far there hasn't been a good fit. f) Would you be so nice to post some (almost out of the box) working demo illustrating your application workflow? Sorry, I can't do that. The application is a) proprietary, and b) still under development. There are over 500 Java classes, over 10 generic XSLT and a highly abstracted, highly normalized schema covering some 50 tables. The architecture document is over 200 pages and would barely get down to the level of detail that you want... There is no preset workflow within the application (it's a generic application for capturing the results of Clinical Trials), - 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]
RE: sexy open source
So far, every time I hear someone talk about using EJB's and cocoon, the topic gets bundled with deploying cocoon in the appserver itself, which pegs you to one front end machine and causes all of your display logic (cocoon) to run on the same disks and cpus as your ejb logic. Is no one using EJB's on a remote (conceptually remote, even if it's on the same machine for now) server from within cocoon? Seems to me that a powerful set up is Assuming you had your JNDI service running correctly the only issue would be packaging up the data classes and the interfaces for Cocoon. That could be a bit of a pain if you had a lot of EJB's and had to manually code the build script to package up the right pieces, but if you're careful with your naming conventions you could probably automate that pretty quickly (for every class that has a Home or Bean suffix you know there's a corresponding class that doesn't have the Home suffix that is the class you want to bundle up for Cocoon). Haven't needed to do this yet, but could be doing so sometime this fall. - 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]
RE: Form validator action question
I can't process my xsl again (not the same request parameters returned by form validator action). Umm, you can always arrange to pass the request parameters back for a 2nd pass; there's no reason the validator can't return the original parameters if there is a validation error... - 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]
return nodeset from action?
Is it possible to return a parameter containing a NodeSet from a Cocoon
action? If I was running an Xalan based servlet I could call a transform
with a parameter that was in fact an org.apache.xpath.NodeSet. I'd like to
do the equivalent in Cocoon. If I just do this directly Cocoon appears to
wrap the results as a String before passing it on to the transformer?
In my action I use code like:
map.put( msgs, (NodeSet)myobject.getMsgs() );
where the getMsgs method returns a nodeset of 1 or more nodes that I'd then
like to reference inside an XSLT. When I reference the parameter in my XSLT
(using xsl:copy-of select=$msgs) I get
org.apache.xpath.NodeSet@90fd20
indicating that the Nodeset has been converted to a String at some point
before I'm referencing it. The site map looks like:
map:act set=test
map:generate src=templates/test.xml/
map:transform src=stylesheets/resolve.xsl
map:parameter name=msgs value={msgs}/
/map:transform
map:serialize type=xml/
/map:act
I suspect the problem is passing the parameter back via the sitemap.
However, if I don't do this I don't see the parameter in the XSLT at all.
I'd guess there is some magic parameter that tells Cocoon to pass the
parameters from the action map back to the transform as parameters? Testing
with:
map:parameter name=parameters value=true/
or
map:parameter name=use-request-parameters value=true/
as parameters to the map:transform did not give the desired results...
Looking at the source doesn't reveal any particular magic to handle this.
My action just extends abstract action, but I don't see any other action
that would yield any other results?
Failing this capability, how else does one return structured data from an
action to a XSLT? (We do not want to use XSP's for this particular set of
transformations...)
I'm running Cocoon 2.0.3 (thanks for the many fixes and improvements :-)
with Tomcat 4.0.4 / JBoss 2.4.4 and JDK 1.4
Peter Hunsberger
Phone: 901-495-5252
E-mail: [EMAIL PROTECTED]
-
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]
RE: return nodeset from action?
Is it possible to return a parameter containing a NodeSet from a Cocoon action? Not via sitemap. Request or session attributes will do. I was afraid of that. [snip] I suspect the problem is passing the parameter back via the sitemap. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9916 The bug has my vote (2 of them!) I think choice #3 is probably the way to go (either a or b). I was somewhat expecting I might have to do this. I'll look at seeing if I can pop the necessary data into the request and then get at it from the XSLT, but if it doesn't I may start to dig through this fix myself... - 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]
RE: Java packages
Now, yes, I could create subdirs in cocoon/WEB-INF/classes or create separate jars for each in the libs, and have my apps each include their own. The other possibility is deploying Cocoon multiple times as different EARs, once for each application. That way if one application needs some features of a particular Cocoon release that breaks other things you're still fine. - 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]
RE: creating pipeline output for XML File viewable with IE browser
I was having difficulty constructing a map entry that will display XML output within the IE browser. It sounds like you have two separate problems: In which I receive a cocoon error message within Tomcat 4.0.1 web server. What's the error message? In which I have the following in a sitemap file: map:pipeline map:match pattern=testXMLOutput map:generate src=test.xml/ map:transform src=test.xsl/ map:serialize type=html/ should be type=xml if you are outputting XML, but this should just cause the results not to display as you expect and not cause a Cocoon error... /map:match /map:pipeline - 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]
RE: SourceWritingTransformer sample (disregard previous post Serializer that writes to file)
Also, what if I don't want the final output sent over the wire.how would I stop output from going to the requesting browser? Writing a null (do nothing) serializer would be pretty easy... :-) - 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]
RE: Giving up! Cocoon too big, slow and confusing
After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. John, it took me almost 2 weeks to go from 0 to 60 using Tomcat, JBoss, and Cocoon (with the 1.4 SDK complicating matters), our previous environment was IIS and Websphere. Having built many servlet based systems I can tell you that the learning curve was worth it. The servlet based version of our current system took over 4 person years to build and has about half as much functionality as what we are currently aiming for with the Cocoon based system in about twice as much code. A complete rewrite using Cocoon was simpler than extending the current system. Cocoon has already shaved probably 6 person months or more off of what would otherwise have been a 2.5 person year project (4 people on the current project, 6 on the original version). Yes things are disorganized at the moment, but the solution is simple: don't try and understand everything up front. Instead, take it one step at a time and research each gotcha with the multitude of resources that are available (the mail list archive and Google are your friends). Subscribe to the mailing list and watch the messages go by. By the time you get to the point where you need a certain feature there will most likely have been enough discussion on the mailing list that you already know what to look for. Of course your mileage may vary, if you're trying to build a couple of simple web pages with no requirement for reusability or multiple data transforms then the learning curve may not save you anything (this time around). But then again, I always preferred VM over MVS...:-) - 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]
RE: Session transformer and namespaces
creates the following invalid XML output (there are multiple xmlns attributes on the 'root' element): ?xml version=1.0 encoding=UTF-8? test root xmlns=http://cocoon.apache.org/session/1.0; xmlns=http://cocoon.apache.org/session/1.0; xmlns=http://cocoon.apache.org/session/1.0; afoo/a bbar/b /root /test Umm, the XML might not be what you want, but it's not illegal; an element can have multiple namespaces - 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]
RE: Logging and Form Validation
This is a major sticking point for my developers that like and are comfortable with jsp with javascript embedded. They want to keep it at the client and I am trying to build a case for the server through cocoon. IMNSHO, the only way you can justify client side validation is if you are running an Intranet and you have an organization that somehow restricts the users capability to modify browsers settings so that you can ensure JavaScript is enabled. Otherwise, you can receive unvalidated data... If you're running over the Internet it's fine to use client side validation in addition to server side if you want to have some extra performance benefits for those who have JavaScript enabled. However, who wants to maintain both? Even if you have an Intranet and locked down browser settings, client side validation can be a real pain to maintain over time. In particular, there is (usually) no good coupling between the validation and the rest of the server side code. The exception is if you generate your client side validation code from server side templates. That's quite possible, but I suspect that once you developers jump through the hoops of embedding JavaScript within XML ( lot's of escaping and/or CDATA) they won't object to server side validation nearly so much... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
So how would I accomplish this with Cocoon. Could I just create a component for doing that validation and treat it as a self contained pipe? I suspect our case won't apply to you: we drive validation out of the database through some EJB's using XML templates that describe what validation rules to pick up. We also have a requirement to ensure that our validators can work with frameworks other than Cocoon without a lot of work. However, if you look at the validation examples that come with Cocoon you should probably get several ideas on ways to proceed. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
I beg to differ. The most part of validation is a trivial matter (minimum lenght of fields, bounds checking, ...) and this should, in my eyes, be done on the client: max performance, min hassles for the user (errors are interactivaley corrected). It's not the complexity of the validation that's at issue. The real question is: HOW THE HECK DO YOU ENSURE THAT THE BROWSER HAS JAVASCRIPT AND HAS IT ENABLED? Excuse the shouting, but unless you address this issue nothing else matters... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
(remember, you still must have validation on the backend) Precisely my original point: since you have to write the server side validation anyway, do you really want to write both client and server side validation? I only do so if there is a real performance penalty with the page validation/regeneration on the server side... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
How about input type=button onclick=submitTheForm() value=Go/ Guaranteed to produce lots and lots of calls to the help desk, or perhaps just people that don't use your site (particularly attractive for someone running an e-commerce site). The fact of the matter is that some of your average users have heard that Javascript is dangerous and opens them up to viruses, worms, etc. As a result, for a web site that must work on the general Internet, it is not only unfriendly, but down right myopic, to require that the end user have JavaScript enabled. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
wait: how many users out there are without JavaScript support ? Not many I think, and I have yet to find a customer of mine saying it has to work on *every* browser, usually they say IE 5.x, IE 6.x... maybe Netscape 6.x... possibly Opera 5 and that's it. I've done three e-commerce sites. The numbers vary for each site, but there is always a trickle of users who do not have JavaScript. I've never bothered to check the numbers on other sites, but I'd guess the results to be the same (many of the others don't have forms validation to worry about). I won't write both validations, I don't simply cater to people wihout Javascript... and I wonder how many developers pay attention to those unlucky fellows. If you really care about your public then you pay attention to such details - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging and Form Validation
Well... you are making a very general statement. Yes, the original start of this conversation qualified when you don't need to worry about JavaScript being enabled... I don't have a problem with people requiring JavaScript; they just need to understand the consequences; if they are writing for the general Internet population they should always make sure the site works both ways... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon vs J2ee performance
I needed the opinion of the house whether Cocoon is a fit for mission critical operations where speed is of top priority in comparison with JSP-Servlet-HTML architecture, using a servlet container only as in J2ee,(with or without ejb's). You are going to have to qualify your requirements a little better than that: Is a formula one race car faster than a school bus? Yes. Will a formula one race car transport 40 school children from point A to point B faster than a school bus? Probably not... Will JSP-Servlet-HTML render a single simple HTML page faster than Cocoon? Yes. Will JSP-Servlet-HTML render 40 complex variations on a common theme faster than Cocoon? Probably not... My guiding principle is to always remember that people costs go up year over year and hardware costs go down year over year. As a result I never attempt to solve something with complex programming that can be solved just as well by simple programming and throwing more hardware at it. From my experimentation I believe that if you need to deliver lots of variations on something (a single page, different languages, output customized to a particular device, in some cases different database results) then Cocoon will probably have lower overall costs that a JSP-Servlet-HTML architecture in the long run. Finally, remember that you can use EJBs with Cocoon. They should not be part of your comparison. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pls confirm: cocoon won't work on OSX
I've tried the following: Tomcat 4.0.1 w/ cocoon 2.0 Tomcat 4.0.1 w/ cocoon 2.0.2 Tomcat 4.0.4b1 w/ cocoon 2.0 Jetty 4 w/ cocoon 2.0 Tomcat 4.0.4b1 w/ cocoon 1.8 Um, you might try Tomcat 4.0.4b1 with Cocoon 2.0.2 We run it on Win 2K with the 1.4 JDK... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Detecting change on XML included with document() to reset cache?
Using Cocoon 2.0.2 Tomcat 4.0.4b JBoss 2.4.4 JRE 1.4.0 I have a straight forward sub-site that invokes a simple 1 stage XML to HTML pipeline. The main xml target of the pipeline is just a list of the real xml files that are to be processed, eg: list filefile-a.xml/file filefile-b.xml/file filefile-c.xml/file /list The style sheet uses the XSLT document() function to process these files. The problem is that usually only the referenced files are updated, the main xml and xsl are mostly static. As a result Cocoon never sees the changes and never clears the cache. Is there a simple way to tell Cocoon to check the referenced files? I realize I could restructure this to have a Cocoon pipeline aggregate the files and process them. However, that approach has two problems: 1) the current method is portable to any XSLT engine; 2) the XML file that determines the included files is visible to the users for when an occasional update is required. I don't want to expose the sitemap to the users due to security/integrity and training issues. Peter Hunsberger Phone: 901-495-5252 E-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Detecting change on XML included with document() to reset cache?
With care you may be able to do this in a portable way though not with the document function. The problem I see with asking the file generator to check dependencies is the overhead of parsing the entire document on every request. That's a reasonable idea; one could code the xsl to pick up a parameter from cocoon to alternate behavior between using document() and cinclude. Not completely clean, but not too horrible. It turns out that using an aggregate in a pipeline requires only two trivial changes to the style sheet, so I can code the stylesheet in a portable manner (ie; again an xsl:choose on a passed parameter when using Cocoon). However, I still have the security/integrity of the sitemap issue. I could get around this by building a application to maintain the sitemap but that's obviously a tad bit of work. Alternately, if one could specify an external file for an map:aggregate that would solve the security/integrity issue; eg: map:aggregate element=list src=data/list.xml/ If I can't get that, what I'd like is a way to tell a caching generator to check some other file list (or generator for that matter) for currency, eg: map:generate ... map:cache-currency-listfile1, file2, .../cache-currency-list map:cache-currency-generator type=generator-name/ /map:generate In the first case a simple hash map of timestamps on the files would work, in the 2nd case some timestamp passed back from some standard method in the generator interface would do the trick, it wouldn't even have to be a timestamp: if the returned string changes from call to call invalidate the cache. It seems to me that this might also help simplify implementation of some of the other cache control mechanisms that have been floating around the list in the last couple of weeks. (And, no, I'm sorry, I don't currently have time to write the code.) - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible bug ?
Just to follow up with this, it appears this a bit of a bug with C2. I don't know why the normal Cocoon sitemap wasn't working, but for my sitemap it was a case of a little too much cutting when I cut and pasted the sitemap: I was missing the pipeline tags. The questionable behavior is that Cocoon happily parsed the sitemap giving no errors and also ran the matchers reporting everything as normal in the logs... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
