cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <cla...@histio.org>
Subject Re: 4 New Classes
Date Tue, 17 Apr 2001 22:08:18 GMT
<html><head></head><body><br>

Ulrich Mayring wrote:<br>
<blockquote type="cite" cite="mid:3AD17686.71501400@denic.de"><pre wrap="">Claude
Warren wrote:<br></pre><blockquote type="cite"><pre wrap="">I have
written 2 new classes.<br><br>AggregatingProducer - used to aggregate static (or
infrequently changing)<br>XML pages into a single page.  This is handy if you have documents
that<br>are combined with infrastructure elements to create standard pages which<br>contain
a mixture of static and active (current time for example)<br>elements.  Conceptually
it is like a "make" for xml pages.  I use this<br>on a site that should be public soon
to combine documents created by a<br>content editor with elements to create a standard
display.  The<br>resulting XML document is stored on disk for quick retrieval later.<br>This
producer works correctly in front of the XSP classes.<br></pre></blockquote><pre
wrap=""><!----><br>Does it pick up changes to the source XML files automatically?
What is<br>the advantage of using a producer instead of doi!
ng it all in XSP?</pre></blockquote>
    <br>

The basic problem that I had on my site was that I have content authors/editors
that create standard documents.&nbsp; Those documents are then placed within the
framework of the site (navigation bars, standard headers and footers, etc.).&nbsp;
Much of this content does not change or changes very little over time.&nbsp; What
does change is that I have a system clock displayed on every page.&nbsp; The result
was a very slow process that started from the base document did the transforms
to add the framework elements (remember that the XSP to put the clock in
would have to come first) and then did the transform to the HTML output.&nbsp;
I realized that what I really wanted to do was to do the transforms for the
static content before I did the XSP and do it so that it would refresh whenever
one of&nbsp; the underlying documents changed but would still be produced quickly.&nbsp;
The result is the AggregatingProducer.&nbsp; It is intended to aggregate several
sources of nearly static content and save the aggregated document so that
it can be quickly produced for the remaining processing.<br>
    <blockquote type="cite" cite="mid:3AD17686.71501400@denic.de"><pre wrap=""><br><br></pre><blockquote
type="cite"><pre wrap="">HAUtilProcessor - a class that uses a plug in paradigm to
provide an<br>extensible processor. I have uses this to develop a system specific time<br>class
&lt;hautil:time&gt;, an include class &lt;hautil:include&gt; that works with<br>the
AggregatingProducer, a navigation class &lt;hautil:navigation&gt; to<br>produce
an active navigation panel, a backlinks class &lt;hautil:backlinks&gt;<br>to
create a series of links to directories up the document tree,<br>parameter &lt;hautil:parameter&gt;
and header &lt;hautil:header&gt; classes to<br>retrieve parameters and headers
from the servlet request.<br></pre></blockquote><pre wrap=""><!----><br>Shouldn't
this be an XSP taglib, too? Why a processor?</pre></blockquote>

Since XSP generally produces "dynamic" output, and I wanted a way to aggregate
content before XSP would get it I needed a processor that could be used by
the aggregation mechanism.&nbsp; As a side effect it can be used outside of that
mechanism as well.&nbsp; The one thing that I do not like about the XSP process
is the way it converts each XML page into a class file.&nbsp; It seems to me that
it would be much cleaner to compile the LogicSheet into a classfile and pass
the relevant portions of the XML document as arguments during a transform.&nbsp;
HAUtilProcessor does this to some degree, however, it does not compile the
java code on the fly.<br>
        <blockquote type="cite" cite="mid:3AD17686.71501400@denic.de"><pre wrap=""><br><br></pre><blockquote
type="cite"><pre wrap="">HAFormProcessor - a class that processes &lt;haform:&gt;
tags to create online<br>forms.  The result of the post operation is a document that
has a<br>structure based on the structure and names of the &lt;haform&gt; elements
in<br>the original document.  The processor has the ability to hide data from<br>the
form (not on the form at all) but include those data on the document<br>that results
from the post operation.<br></pre></blockquote><pre wrap=""><!----><br>Interesting,
I'll look at it. However, IMHO it should also be an XSP<br>taglib, so XSP features can
be used within it.</pre></blockquote>
            <br>

The HAFormProcessor has to be able to completely replace the output document.&nbsp;
I could not find a way to do that and to navigate the entire input document
at the same time.&nbsp; Basically on a "GET" the form processor removes any nodes
enclosed in &lt;haform:hidden&gt; tags and then passes the document down
the chain.&nbsp; On a "POST" it uses the input document as a "template" to format
an output document using the HttpServletRequest parameters for values.&nbsp; For
example:<br>

&lt;haform:root&gt;<br>

&lt;haform:form&gt;<br>

&lt;haform:input label="Name" type="text" length="30" haform:name="user_name" haform:req="y"/&gt;<br>

&lt;haform:input label="Email" type="email" length="30" haform:name="user_email"/&gt;<br>

&lt;haform:input label="Submit" type="submit" haform:remove="y"/&gt;<br>

&lt;/haform:form&gt;<br>
            <br>

Should be processed by a standard XSLT process to produce a in input form
with 2 text fields.&nbsp; The field names in HTML would be user_name and user_email.&nbsp;
The labels are used for description and are intended to be end user prompts.&nbsp;
the user_name field is required.<br>
            <br>

on the POST each field is validates.&nbsp; user_name must have a value, and the
user_email if it has a value must pass the "email" validation.&nbsp; Once that
is done the following document would be produced:<br>
            <br>

&lt;haform:root&gt;<br>

&lt;user_name&gt;What ever the user entered&lt;/user_name&gt;<br>

&lt;user_email&gt;The user email as entered&lt;/user_email&gt;<br>

&lt;/haform:root&gt;<br>
            <br>

The haform:root could be renamed to something else using the haform:name
attribute.&nbsp; In addition processing instructions can be added to the resulting
document.&nbsp; <br>
            <br>

If the form fails the validation the original document is modified to add
haform:error attributes that describe the error and text nodes are added
that contain the input values from the POST.<br>
            <blockquote type="cite" cite="mid:3AD17686.71501400@denic.de"><pre wrap=""><br><br></pre><blockquote
type="cite"><pre wrap="">I hope to have the code and documentation available on <a
class="moz-txt-link-abbreviated" href="http://www.histio.org">www.histio.org</a><br>sometime
soon.<br></pre></blockquote><pre wrap=""><!----><br>Cool,
tell us when the docs and samples are ready.</pre></blockquote>
                <br>

The docs may be some time but I do have the code and examples archived up and will send to
whomever asks.<br>
                <br>

Claude<br>
                <br>
</body></html>


---------------------------------------------------------------------
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: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message