[ic] mv_click bounce not working while mv_form_profile is set :-/

[Ethan Rowe]

Philipp.Trost at digi-T.de wrote:

>hi all,
>
>i ve the following form:
>
>    <form action="[process]" method="post" name="bounce_test">
>    <INPUT TYPE="hidden" NAME="mv_session_id" VALUE="[data session id]">
>    <INPUT TYPE="hidden" NAME="mv_form_profile" VALUE="test_bounce">
>    <INPUT TYPE="hidden" NAME="mv_todo" VALUE="return">
>    <INPUT TYPE="hidden" NAME="mv_nextpage" VALUE="@@MV_PAGE@@">
>
>[error name=weight std_label="weight" required=1]
><input type="text" name="weight" class="blau_mittel" value="[value weight]" maxlength="64">
>
>[error name=zip std_label="zip*" required=1]
><input type="text" class="blau_mittel" name="zip" value="[value zip]" maxlength=64>
>
>    [button
>       name=mv_click
>        form=bounce_test
>         text="cancel"
>    ]
>      [bounce page=login]
>    [/button]
>  <INPUT TYPE="submit" class="menu" value="senden">
></form>
>
>the cancel button should bounce to the login page without checking the profile and the submit should submit after checking profile (test_bounce)
>
>but the check will done in both cases .. i tried a lot without success.. am i completely wrong? or can somebody me an advice? .. i wont use js or pass on the profile
>
>thx in advance
>
>noice
>
>info the complete code with all the check routines and the complete file is here : http://paste.phpfi.com/42753 
>  
>
There are a couple of things:

If memory serves, the order of operations as far as evaluating profiles, 
mv_click actions, etc. goes:
1. profile check on mv_form_profile
2. mv_click action process (only occurs if the profile check was successful)
3. profile check on mv_order_profile (I think this only comes into play 
when mv_todo=submit)

Interchange will check the form profile before processing the button 
action no matter what you do.  Therefore, for this kind of case, I think 
you probably need to put an [if]...[/if] within your profile to test for 
the value of mv_click.  The [button] tag outputs an HTML submit element 
with the name 'mv_click' (you don't need to specify the name), and its 
value is of course that of the text displayed in the element (in this 
case, 'cancel').

Therefore, in your form profile definition, you could wrap the existing 
profile in:
[if cgi mv_click ne cancel] (which means, if the CGI value of mv_click 
does not equal 'cancel')
...<your existing profile stuff>...
[/if]

There might be a better solution, but this could do the trick.  If you 
already have a bunch of [if] tags in the profile definition, you may 
need to tinker with this for a while to get it to handle the nested ifs 
properly.

Secondly:
Don't use bounce in an mv_click action (i.e. in the body of a [button]) 
when you're directing the flow to a different page within your catalog.  
Interchange looks at the value of "mv_nextpage" in CGI space to 
determine what page to load.  Therefore, from within a profile check or 
an mv_click/button action, you can always change the page that 
Interchange will load by adjusting mv_nextpage appropriately.  
Furthermore, mv_click/button actions are parsed for ITL, and then the 
result is parsed again, with Interchange expecting a list of CGI 
variable assignments, one per line.  Therefore, in your case, you can 
simply replace:
[bounce page=login]
with:
mv_nextpage=login

This is much more efficient; using [bounce] just puts the bounce stuff 
into the page, but the whole page has to load, then the user's browser 
needs to execute the bounce, resulting in another request; changed 
mv_nextpage directs Interchange to the page you want right from the 
beginning.

This is precisely why mv_click actions are so powerful, and so cool.  In 
fact, this whole area of Interchange, involving actionmaps, autoloads, 
profile checks, and mv_click/mv_check actions, which allow you to do 
very powerful things before Interchange actually starts loading a page, 
is Miles-Davis-cool.

Hope this helps.
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com