You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/07/12 21:16:11 UTC
ValidatorAction cleanup
I want to clean up the Validator XSP page. The reason is that I want
to provide a markup that does not require me to embed <xsp:logic> tags
in my forms. Basically, it will be tags like the following:
<on-error name="field">
<warn>Display this message</warn>
</on-error>
<on-toosmall name="name">
<warn>Name needs to be at least 5 characters</warn>
</on-toosmall>
This cleans up the generated code, and is much more maintainable for the
end user. Does anyone have any input on preferred semantics?
Also, should this be 2.1 only, or should I make the functionality available
for 2.0 as well?
Re: ValidatorAction cleanup
Posted by Berin Loritsch <bl...@apache.org>.
Christian Haul wrote:
>
> Ah, while we're at it. Did you have a chance to have a look at my
> proposed patch for ESQL?
No, I didn't.
>
> 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: ValidatorAction cleanup
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 13.Jul.2001 -- 08:43 AM, Berin Loritsch wrote:
> > trying to sensibly integrate Informix SERIAL columns into
> > DatabaseAddAction.... Probably a more modular approach to
> > DatabaseAddAction.
>
> As to this issue, if SERIAL columns generate new id numbers, you might
> want to use the "automatic" mode:
>
> <table name="ifxTable">
> <keys>
> <key param="id" dbcol="department_id" type="int" mode="automatic"/>
> </keys>
> <values>
> <value param="name" dbcol="department_name" type="string"/>
> </values>
> </table>
>
> What this does is tell the Database Actions that the "department_id"
> key values will be automatically generated by the database--so it does
> not try to add the information itself.
True, but then I'd like to have the freshly generated ID available --
without an error prone query (think duplicate values, no candidate
keys). Informix requires to do a myStatement.getSerial() after
execution. Oracle needs a query "MYSEQUENCE.current", others need
"@@IDCOLUMN" &c. So I'm working on a module for this. But perhaps a
code generator performs better.
Ah, while we're at it. Did you have a chance to have a look at my
proposed patch for ESQL?
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: ValidatorAction cleanup
Posted by Berin Loritsch <bl...@apache.org>.
Christian Haul wrote:
>
> On 12.Jul.2001 -- 03:16 PM, Berin Loritsch wrote:
> > I want to clean up the Validator XSP page. The reason is that I want
> > to provide a markup that does not require me to embed <xsp:logic> tags
> > in my forms. Basically, it will be tags like the following:
> >
> > <on-error name="field">
> > <warn>Display this message</warn>
> > </on-error>
> > <on-toosmall name="name">
> > <warn>Name needs to be at least 5 characters</warn>
> > </on-toosmall>
> >
> >
> > This cleans up the generated code, and is much more maintainable for the
> > end user. Does anyone have any input on preferred semantics?
> >
>
> I remember that there have been discussions on this list whether to
> duplicate e.g. if-then-else constructs in xsp tags. I believe the
> consensus was that's not too good an idea.
Notice, that I am not doing something like this:
<xsp:if>
<xsp:test><xsp-formval:is-toosmall name="name"/></xsp:test>
<xsp:true>
<warn>Display this message</warn>
</xsp:true>
</xsp:if>
That would be an example of a if/then/else expression in XSP. That is not
_conceptually_ what I am doing. The Concept is that should an error occur,
the embedded tags are placed in the document. This can be implemented in
any number of ways. The bottom line is that we need a way of achieving
this functionality without <xsp:logic> tags embedded in a page. Those
are ugly--and language dependant.
> Actually, I don't mind but this should really be an addition rather
> than a replacement for the <is-ok> &c. tags.
That is the whole reason I am using the <on-ok> approach. They are in
addition to, not in lieu of the <is-ok> tags. They each have their
purposes.
> For a real application I would envision a higher level taglib that
> combines the validation with reading the request parameters and does
> more form specific stuff.
>
> <form-lib:input type="text" name="fieldname" default="">
> <form-lib:label> <!-- tooltip or real label? -->
> This is an input field
> </form-lib:label>
> <!-- even more things you can do with input field, javascript &c -->
> <form-lib:on-error>
> <warn>Display this message</warn>
> </form-lib:on-error>
> </form-lib:input>
I am looking at XForms markup--however they do not have a error reporting
mechanism yet. The <xsp-formval:on-error/> approach does essentually what
your markup here is suggesting. Requiring each project to develop their
own logicsheet and markup for the <on-error> tags is kind of much. It will
make life easier for a great number of people to have these tags added to
the logicsheet.
> So, maybe I would put it there rather than the form-validator. I will
> have a go at this and the necessary stylesheet but currently I'm
> trying to sensibly integrate Informix SERIAL columns into
> DatabaseAddAction.... Probably a more modular approach to
> DatabaseAddAction.
As to this issue, if SERIAL columns generate new id numbers, you might
want to use the "automatic" mode:
<table name="ifxTable">
<keys>
<key param="id" dbcol="department_id" type="int" mode="automatic"/>
</keys>
<values>
<value param="name" dbcol="department_name" type="string"/>
</values>
</table>
What this does is tell the Database Actions that the "department_id"
key values will be automatically generated by the database--so it does
not try to add the information itself.
Re: ValidatorAction cleanup
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 12.Jul.2001 -- 03:16 PM, Berin Loritsch wrote:
> I want to clean up the Validator XSP page. The reason is that I want
> to provide a markup that does not require me to embed <xsp:logic> tags
> in my forms. Basically, it will be tags like the following:
>
> <on-error name="field">
> <warn>Display this message</warn>
> </on-error>
> <on-toosmall name="name">
> <warn>Name needs to be at least 5 characters</warn>
> </on-toosmall>
>
>
> This cleans up the generated code, and is much more maintainable for the
> end user. Does anyone have any input on preferred semantics?
>
I remember that there have been discussions on this list whether to
duplicate e.g. if-then-else constructs in xsp tags. I believe the
consensus was that's not too good an idea.
Actually, I don't mind but this should really be an addition rather
than a replacement for the <is-ok> &c. tags.
For a real application I would envision a higher level taglib that
combines the validation with reading the request parameters and does
more form specific stuff.
<form-lib:input type="text" name="fieldname" default="">
<form-lib:label> <!-- tooltip or real label? -->
This is an input field
</form-lib:label>
<!-- even more things you can do with input field, javascript &c -->
<form-lib:on-error>
<warn>Display this message</warn>
</form-lib:on-error>
</form-lib:input>
So, maybe I would put it there rather than the form-validator. I will
have a go at this and the necessary stylesheet but currently I'm
trying to sensibly integrate Informix SERIAL columns into
DatabaseAddAction.... Probably a more modular approach to
DatabaseAddAction.
> Also, should this be 2.1 only, or should I make the functionality available
> for 2.0 as well?
It's not gonna break anything nor is it likely to introduce new bugs
so I'd say 2.0 should be OK.
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