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.
S/MIME Cryptographic Signature
