> From: Jason Foster [mailto:[EMAIL PROTECTED]] > > I am in the process of trying to create a Cocoon "baby-block" > that can be > used to generate output from a DocBook source file. I was > hoping that the > group could help me puzzle through the "right way" to > accomplish my goal. > > The process that I am envisioning looks something like this... > > 1. The user visits a web page where they specify the DocBook > source file > they would like to upload and the various processing options > they would > like to use. These options are presented as pulldowns, text fields, > checkboxes, etc. > 2. The uploaded file into a temporary directory somewhere > 3. The DocBook stylesheets are applied to the file, using the > specified > processing options > 4. (For now) a PDF document is returned to the user > > My primary implementation goal is to use the minimum amount > of code as > possible. Right now the W3, and in my opinion the Cocoon > developers, are > pushing for a more declarative web development experience
I would not say for all the Cocoon developers. > (check out the > XForms spec for an example) so I would like my implementation > to adhere to > this vision. > > Accomplishing part 1 is fairly straightforward, as it is a > simple XHTML > page, no bells or whistles. I could base it on a transform, > but for now > that seems like overkill. Yes. > > Part 2 looks to be be handled by the SourceUploadAction that > is currently > sitting in the scratchpad. The alternative that is most > often discussed in > this list is to use an XSP page to do the work, which I would > prefer not to > do for the reasons discussed earlier. Any other techniques would be > greatly appreciated. IMO, SourceUploadAction is the right choice. > > Part 3 looks to be the most complicated. I don't want the > user to have to > always select all of the processing options. I also don't > want to have to > keep track of the default values used by the DocBook > stylesheets, which > would be a maintenance nightmare. My plan is to provide a > "use default" > option for the pulldowns and to assume that empty text fields > mean "use > default". What's wrong with having defaults in stylesheets and assign new values from request params? <xsl:param name="use.extensions">no<xsl:param> And then in the sitemap turn on <use-request-parameters>false</use-request-parameters> option for the XSL transformer. > > Another problem is that the DocBook stylesheets assume that > there will be > a "driver" stylesheet that looks like: > > <xsl:stylesheet > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version='1.0'> > <xsl:import > > href="file:///Users/jafoster/Development/docbook-xsl-1.50.0/fo > /docbook. > xsl"/> > <xsl:param name="use.extensions"/> > <xsl:param name="autotoc.label.separator"/> > </xsl:stylesheet> > > I would really like to do things "properly" and use the > driver stylesheet > approach. This means that I need to first use the submitted > form to create > the driver stylesheet and then use that new stylesheet to process the > uploaded file. > > At a guess what I will have to do is use two different > pipelines. The > first will use some kind of "FileWritingTransformer" or > "WriteableSource" > or something similar to generate the driver stylesheet. That > pipeline will > then call the second pipeline which will actually do the > transformation and > generate the PDF. Hopefully someone can provide some advice > on this part > of the implementation. One issue that I have no idea how to > address is the > namespacing issues associated with having one XSLT generate > another XSLT. You can do it this way: - First pipeline generates the content transformations into PDF and calls the second pipeline to obtain the needed stylesheet - Second pipeline generates a stylesheet depending on request params and using a stylesheet template Look at the Slashedit sitemap (xml-cocoon\2.1-dev\src\scratchpad\webapp\samples\editor\editor.xmap), particularly, the lines 101-123. You'll see several <map:transform src="cocoon:/something.xsl" />. > > Assuming that I can get this to work, part 4 is automatic, > assuming that I > use Saxon. As of today Xalan can't handle DocBook, so I am using the > "specify your own factory" approach and forcing the use of Saxon. > > I have every intention of documenting the full design process and > implementation of this project, assuming that I can ever > make it work. I > know that the DocBook community would love to have an > automated way for new > users to play with the DocBook stylesheets in a controlled manner. And I'm sure that Cocoon community would like to have a use-case like this, and more over if it will be documented in details. Hope my comments help a little. Konstantin. > > Thanks for any help you can give. Once this is all documented, you > (hopefully) won't have to answer these kind of questions again! > > Jason Foster > > > --------------------------------------------------------------------- > 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]> > --------------------------------------------------------------------- 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]>
