[ic] Forms validation

IC-Admin interchange-users@lists.akopia.com
Tue May 8 22:52:01 2001


On Tue, 8 May 2001 cfm@maine.com wrote:

> On Tue, May 08, 2001 at 05:42:14PM -0700, Dan B wrote:
> > At 03:16 PM 5/8/2001 -0400, you wrote:
> > >I'm confused between order profiles and [error] for forms validation...
> > >
> > >Does anyone can send me code samples other than the demo? What if its not
> > >for an order...
> > >
> > >Lets say a login or another form that will just gather info. What "tools"
> > >would one use?
> > >I'll search in the doc when I'll know what to search for =)
> > >
> > >That whole forms thing is hard to swallow...I wish someone could explain it
> > >to me. I've used forms for YEARS with ASP and PHP and I just cant understand
> > >why its [process] instead of [process-target] as the action...nor what is
> > >the difference between "submit", "return", "cancel" that you put in an
> > >mv_todo or mv_doit or mv_click? or whatever...etc.
> 
> That's a really good question; it's a difficult part.  For
> all the years we've used minivend I don't understand much of
> it but here's how we treat it now as a rule:
> 
> mv_click lets you select any one of the click actions...
> 
> <FORM ACTION="[process-target _self ]" METHOD=POST>
> <INPUT NAME="mv_doit" TYPE=HIDDEN VALUE=refresh>
> <INPUT NAME="mv_order_profile" TYPE=HIDDEN VALUE="basket_profile">
> 
> <DIV ALIGN=CENTER><INPUT NAME="mv_click" TYPE=SUBMIT VALUE="Browse">
> <INPUT NAME="mv_click" TYPE=SUBMIT VALUE=Recalculate>
> <INPUT NAME="mv_click" TYPE=SUBMIT VALUE="Cancel All">
> <INPUT NAME="mv_click" TYPE=SUBMIT VALUE="Check Out"></DIV>
> [set Browse]
> mv_todo=return
> mv_nextpage=catalog
> [/set]
> [set Cancel All]
> mv_todo=return
> mv_nextpage=mv/cancel
> [/set]
> [set Check Out]
> mv_todo=submit
> [/set]
> [set Recalculate]
> mv_todo=return
> mv_nextpage=basket
> [/set]
> </FORM>[set basket_profile]
> [profile]basket[/profile]
> [/set]
> 
> I don't even know if all the todo and doits are needed. :-)
> 
> I just wanted to point out that this very small subset of the
> possibilities allows us to do everything.  It used to bother
> me that I did not know the differences between all the various
> options.  :-)
> 
> cfm
> 

I mean, if both, you and Dan Browning, are commenting this way,
I really wonder, why either the documenters or developers don't
try to write something up, which makes it a little bit clearer.

Contrary to you, I haven't even seriously tried, because in
my case it just doesn't make sense to do so. But it always bothers me
if old timers like you both, are making those comments. It
makes me believe you have valid reasons to say so, and I think
they should be taken into account.

Let's hope, someone from the documentation team, thinks the same
way or at least understands what you think is missing.

BF

> 
> 
> 
> > >
> > >It looks like a completely different approach...
> > >
> > >If someone thinks he can write something on the subject PLEASE use me as a
> > >cobaye as I'm sure others will benefit a lot from this.
> > >
> > >Thank you.
> > >
> > >J.-P.
> > 
> > Yes, J.-P., I hope as well that someone will be inspired to write 
> > "Introduction to Forms the Interchange Way 101".
> > 
> > Barring that, the following reading might be a great primer:
> > 
> > http://developer2.akopia.com/cgi-bin/ic/dev/ictemplates_26.html
> > 
> > http://developer2.akopia.com/cgi-bin/ic/dev/iccattut_34.html
> > 
> > http://developer2.akopia.com/cgi-bin/ic/dev/iccattut_37.html
> > 
> > http://developer2.akopia.com/cgi-bin/ic/dev/icdatabase_44.html
> > 
> > Later,
> > 
> > Dan Browning, Cyclone Computer Systems, danb@cyclonecomputers.com
> > 
> > 
> > _______________________________________________
> > Interchange-users mailing list
> > Interchange-users@lists.akopia.com
> > http://lists.akopia.com/mailman/listinfo/interchange-users
> 
>