suppressed 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=loginThis 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 suppressed _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.