You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2001/07/18 16:45:29 UTC
[RT] forms
Looking at all the approaches for xml based form handling
(including my own ones) I'm not really happy what there
is available up to now...
Especially multipage forms, error messages and i18n
is not addressed in an extensive or sufficient manner.
The Model:
What we do so far is to have a business object that
represent the whole mulitpage form:
class OrderForm {
XTextbox firstname;
XTextbox lastname;
XSingleSelection state;
XEmail email;
}
The View:
Then we have a set of XSP pages (with a taglib)
that maps the elements to the different pages.
page1.xsp:
<xform:textbox name="firstname" class="class.path.OrderForm"/>
<xform:textbox name="lastname" class="class.path.OrderForm"/>
page2.xsp:
<xform:singleSelection name="state" class="class.path.OrderForm"/>
<xform:textbox name="email" class="class.path.OrderForm"/>
The Controler:
We have a Populator that populates the posted
values into the correct OrderForm fields
and a Validator that check all involved fields
on validity. The result is passed to the
Selector that select the new view/page.
For different media you only have to define new views.
All values are stateful now. Even Comboboxes only have
to be filled once (on creation)
Although this looks promising on the first glance there
are some things I'm worried about:
* even for really simple forms one would have create
a class and program in java
* i18n is still a problem for e.g. captions
or default values
* having one XSP pages per view per media is not very nice
What I'd like to try is to marry this approach with
the FormValidatorAction approach. I was thinking of
one descriptor file that defines the multipage form:
The class mapping version:
<?xml version="1.0"?>
<pages>
<page name="name">
<textbox name="firstname" class="class.path.OrderForm">
<caption><i18n:translate>Firstname</i18n:translate></caption>
</textbox>
<textbox name="lastname" class="class.path.OrderForm">
<caption><i18n:translate>Lastname</i18n:translate></caption>
</textbox>
<goto name="address"/>
</page>
<page name="address">
<singleSelection name="state" class="class.path.OrderForm">
<caption><i18n:translate>*please select*</i18n:translate></caption>
<option id="CA"><i18n:translate>California</i18n:translate></option>
<option id="NY"><i18n:translate>New York</i18n:translate></option>
</singleSelection >
<textbox name="email" class="class.path.OrderForm">
<caption><i18n:translate>Email</i18n:translate></caption>
</textbox>
<goto name="address"/>
<goto name="overview"/>
</page>
<page name="overview">
<textbox name="firstname" class="class.path.OrderForm" as="text">
<caption><i18n:translate>Firstname</i18n:translate></caption>
</textbox>
<textbox name="lastname" class="class.path.OrderForm" as="text">
<caption><i18n:translate>Lastname</i18n:translate></caption>
</textbox>
<goto name="start"/>
<goto name="submitted"/>
</page>
<page name="submitted">
<p>
<i18n:translate>Thank You</i18n:translate>
</p>
</page>
</pages>
And the direct one:
<?xml version="1.0"?>
<pages>
<page name="name">
<textbox name="firstname">
<caption><i18n:translate>Firstname</i18n:translate></caption>
<validation nullable="yes"/>
</textbox>
<textbox name="lastname">
<caption><i18n:translate>Lastname</i18n:translate></caption>
</textbox>
<textbox name="email">
<caption><i18n:translate>Email</i18n:translate></caption>
<validation type="string" regexp="^[\d\w][\d\w\-_\.]*@([\d\w\-_]+\.)\w\w\w?$"/>
</textbox>
<textbox name="age">
<caption><i18n:translate>Age</i18n:translate></caption>
<validation type="long" min="4" max="99"/>
</textbox>
</page>
</pages>
(Btw: I don't understand the constraints in the current FormValidatorAction.
Isn't setting a min/max etc. the same as specifying a constraint?)
Now a FormPopulatorAction could populate the values (if it is
an object based form). A FormValidationAction could check the
values and propose a page to show. A FormTransformer could
filter out everything but the correct page and expand the
form elements the full introspective.
<textbox name="firstname" class="class.path.OrderForm">
<caption><i18n:translate>Firstname</i18n:translate></caption>
<value>Torsten</value>
<error code="0"/>
</textbox>
<textbox name="lastname" class="class.path.OrderForm">
<caption><i18n:translate>Lastname</i18n:translate></caption>
<value/>
<error code="1"><i18n:translate>IsNull</i18n:translate></error>
</textbox>
The sitemap could look like this:
<map:match pattern="form.html">
<map:act type="FormPopulatorAction"/>
<map:act type="FormValidatorAction"/>
<map:parameter name="descriptor" value="context:///forms/order.xml"/>
<map:generate src="forms/order.xml"/>
<map:transform type="FormTransformer">
<map:parameter name="select" value="{page}"/>
</map:transform>
<map:transform type="i18n" .../>
<map:transform src="styles/xform2html.xsl"/>
<map:transform src="styles/page2html.xsl"/>
<map:serialize/>
</map:act>
</map:match>
Maybe a generator is even a better approach... Only generate the desired
page. But then we need to pass an action parameter to the generator:
<map:match pattern="form.html">
<map:act type="FormPopulatorAction"/>
<map:act type="FormValidatorAction"/>
<map:parameter name="descriptor" value="context:///forms/order.xml"/>
<map:generate src="forms/order.xml">
<map:parameter name="select" value="{page}"/>
</map:generate>
<map:transform type="i18n" .../>
<map:transform src="styles/xform2html.xsl"/>
<map:transform src="styles/page2html.xsl"/>
<map:serialize/>
</map:act>
</map:match>
But as Transformer we could even use esql or other dynamics
to fill the forms...
Comments please ;)
--
Torsten
---------------------------------------------------------------------
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
RE: [RT] forms [long]
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
Posted by Torsten Curdt <tc...@dff.st>.
> >Looking at all the approaches for xml based form handling
> >(including my own ones) I'm not really happy what there
> >is available up to now...
> >
> >Especially multipage forms, error messages and i18n
> >is not addressed in an extensive or sufficient manner.
> >
> >The Model:
> >What we do so far is to have a business object that
> >represent the whole mulitpage form:
>
> @Crudlet.org our objects to be filled in are much more complex than this,
> we are often dealing with Composite Beans, ie, Beans that can contain
> Beans. The Properties on the Beans also have Editors that do the getting,
> setting and Validation.
>
> Simple Properties
> Simple Indexed Properties
> Composite Properties
> Composite Indexed Properties
> Nested Composite Indexed Properties ;)
> Property Attributes
>
> Our current idea is to use the form field name as an 'address' into the
> Bean, ripping off the syntax from XPath. So that the TagLib can 'auto-fill'
> the Bean from the form.
>
> one/two/three - address a simple property
> one/two/three[3] - address an item within a simple
>
> indexed property
> one/two[2]/three[4]/four - address a property of an indexed
>
> composite property
> one/two/three/@negotiable - address a simple property's 'attributes'
> one/two[2]/three[4]/@negotiable - address an attribute of an indexed property
> one/two[1]/four[0]/eek - address a property of a nested
>
> indexed composite property
> one/two[1]/four[0]/eek/@required - address an attribute of property of
>
> a nested indexed composite property
This is indeed a nice idea. But maybe this is possible
with currently discussed approach. Let's assume we have
the interface:
interface DOMObject extends XMLFragment {
void setValue( String XPath );
String getValue( String XPath );
}
We could create different types of mappers or
implementations:
class BeanDOM implements DOMObject {
void setValue( String XPath ){
/* write to your framework */
}
String getValue( String XPath ){
/* read from your framework */
}
}
That's what I intended to do for my business objects
anyway! (although this is not comforming to the XForm spec)
But for complex business logic and as "frontend" to
a framework this much nicer than the XForm approach
that there is right now.
> >The Controler:
> >We have a Populator that populates the posted
> >values into the correct OrderForm fields
> >and a Validator that check all involved fields
> >on validity. The result is passed to the
> >Selector that select the new view/page.
>
> This is where I would like to be able to generate an Action from XSP
> TagLibs, as I think you are beginning to want as well.
I always wanted :)
> Because the TagLib for the Crudlet Engine was developed originally for
> Cocoon 1, it has all the functionality to be able to generate and handle
> forms, multi page etc., now with Cocoon 2, we can usefully split generation
> and handling into smaller reusable components via the SiteMap/FlowMap, it
> would be of tremendous advantage to be able to re-use the XSP Languages
> that have already been developed (esql, auth, fp, crudlet etc.).
>
>
> Any way, I commend your attempt!
> I would certainly like to work the MVC Pattern more rigorously into our
> approach.
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
> 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 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!
> 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?
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] forms
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 4:45 PM +0200 18/7/01, Torsten Curdt wrote:
>Looking at all the approaches for xml based form handling
>(including my own ones) I'm not really happy what there
>is available up to now...
>
>Especially multipage forms, error messages and i18n
>is not addressed in an extensive or sufficient manner.
>
>The Model:
>What we do so far is to have a business object that
>represent the whole mulitpage form:
@Crudlet.org our objects to be filled in are much more complex than this,
we are often dealing with Composite Beans, ie, Beans that can contain
Beans. The Properties on the Beans also have Editors that do the getting,
setting and Validation.
Simple Properties
Simple Indexed Properties
Composite Properties
Composite Indexed Properties
Nested Composite Indexed Properties ;)
Property Attributes
Our current idea is to use the form field name as an 'address' into the
Bean, ripping off the syntax from XPath. So that the TagLib can 'auto-fill'
the Bean from the form.
one/two/three - address a simple property
one/two/three[3] - address an item within a simple
indexed property
one/two[2]/three[4]/four - address a property of an indexed
composite property
one/two/three/@negotiable - address a simple property's 'attributes'
one/two[2]/three[4]/@negotiable - address an attribute of an indexed property
one/two[1]/four[0]/eek - address a property of a nested
indexed composite property
one/two[1]/four[0]/eek/@required - address an attribute of property of
a nested indexed composite property
>The Controler:
>We have a Populator that populates the posted
>values into the correct OrderForm fields
>and a Validator that check all involved fields
>on validity. The result is passed to the
>Selector that select the new view/page.
This is where I would like to be able to generate an Action from XSP
TagLibs, as I think you are beginning to want as well.
Because the TagLib for the Crudlet Engine was developed originally for
Cocoon 1, it has all the functionality to be able to generate and handle
forms, multi page etc., now with Cocoon 2, we can usefully split generation
and handling into smaller reusable components via the SiteMap/FlowMap, it
would be of tremendous advantage to be able to re-use the XSP Languages
that have already been developed (esql, auth, fp, crudlet etc.).
Any way, I commend your attempt!
I would certainly like to work the MVC Pattern more rigorously into our
approach.
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 am convinced XSP Actions would help.
regards Jeremy
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.
--
___________________________________________________________________
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
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 18.Jul.2001 -- 06:38 PM, Torsten Curdt wrote:
> > Well, I would like to tackle forms in a vew days, but frankly,
> > I would reckon multipage forms to be too complex for an initial
> > release...
>
> I don't think it will make much sense to try a simple form
> first when we don't have an idea which direction to go!
To quote XForms WD 8.5:
As the name implies subpage is not specific to XForms--our intent is
to design subpage so that it can be used within XForms--and more
generally within XHTML to create presentations where document views
are presented to progressively reveal the document structure and
content.
So this is perhaps an issue external to forms. Of course such a thing
is translatable to XSP code plus an actions that keeps feeding the
same XSP until the last subpage has been shown.
> > I would prefer a "XForms logicsheet" or a "XForms stylesheet" to
> > anything else. After all, you will probably want to use it on XSP.
>
> As far as I was teached ;) XSP should be not a lot more than presentation
> logic! A XForms Logicsheet would probably put a lot more logic into
> the XSP pages than necessary.
I'm not sure about that. Forms are 70% markup (-> stylesheet) plus
some housekeeping, e.g. filling the form, switching between views, and
some 35% validation (-> action).
> > Of course this does not rule out a FormTransformer but I'm not sure
> > about a FormPopulator -- a transformer might work as well. But I feel
> > that's not within the scope of such a package.
>
> What package should do it then?
I think it will be a combination of action(s) + logicsheet + stylesheet
> So how would you address some of the common problems?
>
> 1. making a form stateful (keeping the input of e.g. textboxes and comboboxes)
Read request parameters to fill in the form. Add a special parameter
to the form, to find out if the user has seen the form before.
> 2. prevent a combobox be filled from the database on each request
Hard one. I think it's not sensible to do. The DBMS should cache
frequent queries, it would be a bit like reinventing the wheel to do
our own caching. Especially, as we can't have a clue if the underlying
table has changed in between.
> 3. have a media independent definition of forms
XForms does that.
> 4. i18n of the form label/captions
No problem to combine i18n with arbitrary tags.
> 5. i18n of the comboboxes (they probably need to load their options on change of the locale)
Again, that's a problem of the i18n package, not of forms.
> 6. the most important thing: multipage form navigation
If you insist, this could be done by
<multiplepages>
<subpage>
<caption> Part I</caption>
<textfield>
[...]
</subpage>
<subpage>
<caption> Part II</caption>
<textfield>
[...]
</subpage>
[...]
</multiplepages>
translated to
<xsp:logic>
switch (RenderView) {
case 1:
<xsp:content>
[...]
</xsp:content>
break;
case 2:
<xsp:content>
[...]
</xsp:content>
break;
[...]
};
</xsp:logic>
Plus an action that allows to advance only if the current view has
been validated OK.
> I'd really like to get rid of the PHP style of form coding...
Sure, but that's why an XSP should contain only one view of a page and
the decision should be made in the sitemap.
> I'm with you to get this on!
Great! I will definitely need help on this. At the moment I'm struck
with some action coding doing it the avalon way and after that I will
concentrate on forms. I hope that'll be top of next week.
It would be great to discuss some of the issues raised in the
discussion on cocoon-user in more detail. Especially if we want to
(re-)construct an XML representation of the request parameters before
processing them. That would enable us to delegate the validation to
xerces, I think. But it might be expensive in terms of computing
resources. OTOH it's required for XForms compliance.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] forms
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 18 Jul 2001, Christian Haul wrote:
> On 18.Jul.2001 -- 04:45 PM, Torsten Curdt wrote:
> > Looking at all the approaches for xml based form handling
> > (including my own ones) I'm not really happy what there
> > is available up to now...
>
> There has been a discussion on the user list recently... I would
> prefer to stick as close to XForms as possible.
I've developed a forms library for AxKit's XSP (obviously using Perl),
which may interest some. It works rather a lot like ASP.NET forms (though
I didn't know that until after I'd released it).
It works mostly based on callbacks in the XSP page-level logic section.
http://search.cpan.org/doc/MSERGEANT/AxKit-XSP-PerForm-1.4/PerForm.pm
This is just a first try at it, so it may be subject to a change in API
quite a bit, but I like it, and it works pretty well. I'd love to see a
Cocoon port.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] forms
Posted by Torsten Curdt <tc...@dff.st>.
> On 18.Jul.2001 -- 04:45 PM, Torsten Curdt wrote:
> > Looking at all the approaches for xml based form handling
> > (including my own ones) I'm not really happy what there
> > is available up to now...
>
> There has been a discussion on the user list recently... I would
> prefer to stick as close to XForms as possible.
This not even a proposal but RT... I'm always pro standard! :)
> > Especially multipage forms, error messages and i18n
> > is not addressed in an extensive or sufficient manner.
>
> Well, I would like to tackle forms in a vew days, but frankly,
> I would reckon multipage forms to be too complex for an initial
> release...
I don't think it will make much sense to try a simple form
first when we don't have an idea which direction to go!
I really think we should find a way for that first...
> [...]
>
> > And the direct one:
> >
> > <?xml version="1.0"?>
> > <pages>
> > <page name="name">
> > <textbox name="firstname">
> > <caption><i18n:translate>Firstname</i18n:translate></caption>
> > <validation nullable="yes"/>
> > </textbox>
> > <textbox name="lastname">
> > <caption><i18n:translate>Lastname</i18n:translate></caption>
> > </textbox>
> > <textbox name="email">
> > <caption><i18n:translate>Email</i18n:translate></caption>
> > <validation type="string" regexp="^[\d\w][\d\w\-_\.]*@([\d\w\-_]+\.)\w\w\w?$"/>
> > </textbox>
> > <textbox name="age">
> > <caption><i18n:translate>Age</i18n:translate></caption>
> > <validation type="long" min="4" max="99"/>
> > </textbox>
> > </page>
> > </pages>
>
> This is really not very far from XForms.
I know... ;) But I'd really like to have MVC
mapping of the business objects aka form objects.
[..]
> > Now a FormPopulatorAction could populate the values (if it is
> > an object based form). A FormValidationAction could check the
> > values and propose a page to show. A FormTransformer could
> > filter out everything but the correct page and expand the
> > form elements the full introspective.
>
> I would prefer a "XForms logicsheet" or a "XForms stylesheet" to
> anything else. After all, you will probably want to use it on XSP.
As far as I was teached ;) XSP should be not a lot more than presentation
logic! A XForms Logicsheet would probably put a lot more logic into
the XSP pages than necessary.
> Of course this does not rule out a FormTransformer but I'm not sure
> about a FormPopulator -- a transformer might work as well. But I feel
> that's not within the scope of such a package.
What package should do it then?
So how would you address some of the common problems?
1. making a form stateful (keeping the input of e.g. textboxes and comboboxes)
2. prevent a combobox be filled from the database on each request
3. have a media independent definition of forms
4. i18n of the form label/captions
5. i18n of the comboboxes (they probably need to load their options on change of the locale)
6. the most important thing: multipage form navigation
I'd really like to get rid of the PHP style of form coding...
I'm with you to get this on!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] forms
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 18.Jul.2001 -- 04:45 PM, Torsten Curdt wrote:
> Looking at all the approaches for xml based form handling
> (including my own ones) I'm not really happy what there
> is available up to now...
There has been a discussion on the user list recently... I would
prefer to stick as close to XForms as possible.
> Especially multipage forms, error messages and i18n
> is not addressed in an extensive or sufficient manner.
Well, I would like to tackle forms in a vew days, but frankly,
I would reckon multipage forms to be too complex for an initial
release...
[...]
> And the direct one:
>
> <?xml version="1.0"?>
> <pages>
> <page name="name">
> <textbox name="firstname">
> <caption><i18n:translate>Firstname</i18n:translate></caption>
> <validation nullable="yes"/>
> </textbox>
> <textbox name="lastname">
> <caption><i18n:translate>Lastname</i18n:translate></caption>
> </textbox>
> <textbox name="email">
> <caption><i18n:translate>Email</i18n:translate></caption>
> <validation type="string" regexp="^[\d\w][\d\w\-_\.]*@([\d\w\-_]+\.)\w\w\w?$"/>
> </textbox>
> <textbox name="age">
> <caption><i18n:translate>Age</i18n:translate></caption>
> <validation type="long" min="4" max="99"/>
> </textbox>
> </page>
> </pages>
This is really not very far from XForms.
> (Btw: I don't understand the constraints in the current FormValidatorAction.
> Isn't setting a min/max etc. the same as specifying a constraint?)
Yes, these are the constraints available plus equivalence to another
parameter or a constant and few more.
> Now a FormPopulatorAction could populate the values (if it is
> an object based form). A FormValidationAction could check the
> values and propose a page to show. A FormTransformer could
> filter out everything but the correct page and expand the
> form elements the full introspective.
I would prefer a "XForms logicsheet" or a "XForms stylesheet" to
anything else. After all, you will probably want to use it on XSP.
Of course this does not rule out a FormTransformer but I'm not sure
about a FormPopulator -- a transformer might work as well. But I feel
that's not within the scope of such a package.
> Comments please ;)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org