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 Thu, 12 Apr 2001 21:33:01 GMT
<html><head></head><body><br>
<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 doing 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>
</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