You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2001/07/23 14:58:43 UTC
RE: [RT] forms [long]
At 2:39 PM +0200 20/7/01, Torsten Curdt wrote:
>
>Thanks, took a while to find a way - but I'm still not satisfied as you
>might see ;) too much java programming required for the forms
a good reason to reuse existing TagLibs in this realm ;)
>
>> The problem I see is that people have developed different languages for
>> different storage mediums, hence we have esql -> SQL DB, fp -> XML File,
>> crudlet -> JavaBeans/JavaSpace, and many others.
>>
>> How do we provide a way to make a generic form handling and verification
>> system that can easily deal with different storage?
I still think this is an important issue, that any generic form-handling
mechanism
for Cocoon2 should be savvy with, not everybody uses databases!!!
>> I am convinced XSP Actions would help.
>
>I was always voting for makeing the XSPEngine a component that can be
>used not just for the generation of cocoon serverpages. I would have
>used this engine to create some classes for my application via XSP
>as well!! And of course it could be used easily to create XSP based
>Actions! Just a different stylesheet and a different class name
>convention - maybe a different output dir.
>
>Undreamed-of possibilities!
I cannot judge at the moment how much work it would be to implement this, I
do not know the codebase well enough.
>> BTW. The other big problem I am wrestling with is the thorny issue of
>> content-logic; where the content that is displayed is intricately tied to
>> the condition of runtime and static parameters, often in our case up to
>> four or five levels of nested if-then-else 'statements'. We find this
>> content-logic to be in a different realm to the underlying business-logic
>> of the Beans, it needs to be accessible to the Content Authors as they are
>> the ones who understand the logic and the content at the display level.
>> This does not map nicely into the Cocoon "cleanroom" model.
>
>I can have a slight idea but could you give an example what type of
>cascading logic this would be?
I will give you an idea of this by showing what our StyleSheets looked
like, then what we are replacing them with (sorry, but this is VERY
verbose, and will be horribly wrapped!):
This is a snippet from our old approach, where we had to have one
stylesheet per page (to contain content-selection logic)
<tr>
<td>
<xsl:choose>
<xsl:when test="$isMyOffer = 'true'"> <!-- if it is my offer -->
<xsl:choose>
<xsl:when test="$isActive = 'true'">
<p>See below for the full details of the offer you have made.
You are able to retract
or complete this offer, if the circumstances of this offer
have changed or if you
are satisfied that your line has been sufficiently covered.</p>
<p>To view the exchanges on this offer go to <a
href="../../you/olw/yourOffers.xml">You</a>.</p>
<p>All negotiations that have been bound will be upheld.
Please see our <a href="../user/faqsMembers.xml">FAQ</a> section
if you have queries regarding outstanding exchanges on your
offer that may be
affected by retracting or completing this offer.</p>
</xsl:when>
<xsl:otherwise>
<p>Your offer has been retracted/completed or has expired. To
view the exchanges on your
offer go to <a href="../../you/olw/yourOffers.xml">You</a>.</p>
<p>All negotiations that have been bound will be upheld.</p>
</xsl:otherwise>
</xsl:choose>
<b>You made this offer on <xsl:apply-templates
select="crud-output/bean/property[ @name = 'CreationDate' ]"/></b>
</xsl:when>
<xsl:otherwise> <!-- if it is NOT my offer -->
<xsl:choose>
<xsl:when test="$isCloaked = 'true'">
<xsl:choose>
<xsl:when test="$isActive = 'true'">
<p>The Reinsured for this offer is cloaked, therefore you
are able to pre-accept
or counter this offer. Please click on the appropriate
button presented at the
bottom of this page; this will take you through to the
next step of the process. </p>
<p>If you would like to decline this offer, then you need
not take any action and simply
<a href="offersList.xml">click here</a> to return to the
<a href="offersList.xml">Main Offers Board</a>.
</p>
</xsl:when>
<xsl:otherwise>
<p>This cloaked offer has been retracted/completed or has
expired. To view the exchanges
on this offer go to <a
href="../you/olw/yourOffers.xml">You</a>.</p>
<p>All negotiations that have been bound will be upheld.</p>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:choose>
<xsl:when test="$isActive = 'true'">
<p>In order to accept or counter this offer, please click
on the appropriate button
presented at the bottom of this page, which will take you
through to the next step of the process.</p>
<p>If you would like to decline this offer, then you need
not take any action and simply
<a href="../../offer/olw/offersList.xml">click here</a>
to return to the
<a href="offersList.xml">Main Offers Board</a>. </p>
</xsl:when>
<xsl:otherwise>
<p>This offer has been retracted/completed or has expired.
To view the exchanges
on this offer go to <a
href="../../you/olw/yourOffers.xml">You</a>.</p>
<p>All negotiations that have been bound will be upheld.</p>
</xsl:otherwise>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>
<b>This offer was made on <xsl:apply-templates
select="crud-output/bean/property[ @name = 'CreationDate' ]"/></b>
</xsl:otherwise>
</xsl:choose>
</td>
</tr>
This is the equivalent sample from our new approach.
We embed both content-logic and content in one XSP Page.
We use a stylesheet pass (select.xsl) that selects the bits of content we
actually want to see depending on run-time parameters.
The select namespace works thus:
Uses the select:choose and select:match attributes
At any level, the select:choose attribute in an element, filters it's
child elements according to the value of their selech:match attribute.
The TagLib handles looking up values for {varName} from the crudlet:var
variables (not included)
declarations (so the author does not have to write all of those
xsp:attribute tags)
If the child of an element acting as a chooser, has a value in it's
matcher that equals, it is output
If a child has no matcher, it is always output
If there are no matches, child elements with a select:match="*" are output
Any element may be both a matcher and a chooser
We use <span> as a "throwaway"
<instructions select:choose="{Sender}">
<span select:match="{UserName}" select:choose="{IsActive}">
<p select:match="true">See below for the full details of the offer you
have made.
You are able to retract or complete this offer, if the circumstances
of this
offer have changed or if you are satisfied that your line has been
sufficiently covered.</p>
<p select:match="true">To view the exchanges on this offer go to
<a href="../../you/olw/yourOffers.xml">You</a>.</p>
<p select:match="true">All negotiations that have been bound will be
upheld.
Please see our <a href="../user/faqsMembers.xml">FAQ</a> section if
you have
queries regarding outstanding exchanges on your offer that may be
affected by
retracting or completing this offer.</p>
<p select:match="false">Your offer has been retracted/completed or has
expired.
To view the exchanges on your offer go to <a
href="../../you/olw/yourOffers.xml">You</a>.</p>
<p select:match="false">All negotiations that have been bound will be
upheld.</p>
<p>You made this offer on <crudlet:copy-of bean="OfferDisplay"
property="CreationDate"/></p>
</span>
<span select:match="*" select:choose="(IsCloaked}">
<span select:match="true" select:choose="{IsActive}">
<p select:match="true">The Reinsured for this offer is cloaked,
therefore you are
able to pre-accept or counter this offer. Please click on the
appropriate button
presented at the bottom of this page; this will take you through to
the next step
of the process. </p>
<p select:match="true">If you would like to decline this offer, then
you need not
take any action and simply <a href="offersList.xml">click here</a>
to return to
the <a href="offersList.xml">Main Offers Board</a>.</p>
<p select:match="false">This cloaked offer has been
retracted/completed or has
expired. To view the exchanges on this offer go to <a
href="../you/olw/yourOffers.xml">You</a>.</p>
<p select:match="false">All negotiations that have been bound will be
upheld.</p>
</span>
<span select:match="false" select:choose="{IsActive}">
<p select:match="true">In order to accept or counter this offer,
please click on
the appropriate button presented at the bottom of this page, which
will take you
through to the next step of the process.</p>
<p select:match="true">If you would like to decline this offer, then
you need
not take any action and simply <a
href="../../offer/olw/offersList.xml">click here</a>
to return to the <a href="offersList.xml">Main Offers Board</a>. </p>
<p select:match="false">This offer has been retracted/completed or
has expired.
To view the exchanges on this offer go to <a
href="../../you/olw/yourOffers.xml">You</a>.</p>
<p select:match="false">All negotiations that have been bound will be
upheld.</p>
<p>This offer was made on <crudlet:copy-of bean="OfferDisplay"
property="CreationDate"/></p>
</span>
</span>
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] forms [long]
Posted by Torsten Curdt <tc...@dff.st>.
> >> The problem I see is that people have developed different languages for
> >> different storage mediums, hence we have esql -> SQL DB, fp -> XML File,
> >> crudlet -> JavaBeans/JavaSpace, and many others.
> >>
> >> How do we provide a way to make a generic form handling and verification
> >> system that can easily deal with different storage?
>
> I still think this is an important issue, that any generic form-handling
> mechanism
> for Cocoon2 should be savvy with, not everybody uses databases!!!
Well, I hear you... I see two different approaches:
1. Right now DOMObject is a class. I guess we should change
this into an interface and a class AbstractDOMObject or DOMObjectImpl
anyway. Now you write your own e.g. BeanDOMMapper implementing
DOMObject. This mapper would need to specify a way to your bean
attributes via XPath.
2. As Christian proposed we could put the binding into the instance
data. By having different namespaces or elements we could have
different types of mappers - something like that:
<xform:instance>
<order>
<firstname><mapper:bean name="MyBean" attribute="Firstname"/></firstname>
<lastname><mapper:fp ref="root/order/lastname"/></lastname>
</order>
</xform:instance>
> >> I am convinced XSP Actions would help.
> >
> >I was always voting for makeing the XSPEngine a component that can be
> >used not just for the generation of cocoon serverpages. I would have
> >used this engine to create some classes for my application via XSP
> >as well!! And of course it could be used easily to create XSP based
> >Actions! Just a different stylesheet and a different class name
> >convention - maybe a different output dir.
> >
> >Undreamed-of possibilities!
>
> I cannot judge at the moment how much work it would be to implement this, I
> do not know the codebase well enough.
Me either... AFAIR Berin once stated he was thinking about redesigning the
whole compilation architecture...
Berin, maybe you already have a clue?
> >> BTW. The other big problem I am wrestling with is the thorny issue of
> >> content-logic; where the content that is displayed is intricately tied to
> >> the condition of runtime and static parameters, often in our case up to
> >> four or five levels of nested if-then-else 'statements'. We find this
> >> content-logic to be in a different realm to the underlying business-logic
> >> of the Beans, it needs to be accessible to the Content Authors as they are
> >> the ones who understand the logic and the content at the display level.
> >> This does not map nicely into the Cocoon "cleanroom" model.
> >
> >I can have a slight idea but could you give an example what type of
> >cascading logic this would be?
>
>
> I will give you an idea of this by showing what our StyleSheets looked
> like, then what we are replacing them with (sorry, but this is VERY
> verbose, and will be horribly wrapped!):
>
>
>
> This is a snippet from our old approach, where we had to have one
> stylesheet per page (to contain content-selection logic)
>
[snip]
AFAIU the xform spec is supposed to address this with
"8.1 Conditional Constructs For Dynamic User Interfaces".
So this will be the problem of the client or our XSLT
xform2html stylesheet.
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org