Forums

Hi All,

I only started using CF4RC2 two days ago, so this may be a wingnut question, but here we go...

I want to build a dynamic "Request a Quote" form for a mixed catalog/store VM site, and while it meant spending two days wading through the forums I am now just about there and grinning like Fritz the Cat all along at what a great little prog CF really is. Chapeau!

What is still missing, though, is that each of my catalog items should have an "Add to Quote" button, which calls a second form that simply "ticks" the relevant quote item checkbox index based on an argument passed along with the URL, then tells the user what it did, stores the data to session and closes upon submit.

Passing arguments so far works well for text fields, etc., but I can simply not figure out how to pass a (e.g.) numerical parameter that is then used to tick the corresponding checkbox in a checkbox array (or the of a radio button group or a multiple combobox). - In essence, if I pass "...&itemid=3", I want to see that index 3 of the checkbox array gets checked. This must be easy, but I can simply not figure out the syntax.

Any help with this would be greatly appreciated!

Ingmar

Hi Ingmar,

I don't know much about Virtuemart but there are a few VM users here.

Which version of ChronoForms are you using? You can find the version from Site Admin | Extensions | Install/Uninstall | Components in Joomla! 1.5 or Site Admin | Extensions | Extension Manager | Manage in Joomla! 1.6.

To set a checkbox value I'd either use a PHP loop to build it and check the value there, or possibly use a JavaScript snippet to set it after the form is loaded from a value in a hidden input.

In CFv4 I think that the RePublish code might handle this if the value is in the $form->data array before the Show HTML action runs. You can use a custom code action to get the value from the URL if needed.

Bob

Hi Bob,

thanks for your answer, but I think I threw you off a bit by making my "story" all too complicated with VM and such. That was only illustration, sorry about that. Here's the straight forward account:

When my user clicks an "Add to Quote" button I want to pass a URL arguments to a form such as...
index.php?option=com_chronoforms&chronoform=PassArgument2Form&article_id=1

In the form that is called I query the argument and load it into one of my form variables...

<?php
$product_code = JRequest::getString('article_id', '', 'get');
?>

...where $product_code above would be a text variable. However, I encounter two problems in this:

1. The form also needs to read in existing Session Data. This is of course possible and the URL argument is still correctly stored in the form variable, but irrespective of the order of my "Custom Code" and "Session To Data" actions (both before ShowHTML), the new variable value is NOT shown. Instead, the value from the Session Data continues to be shown. But if I submit this form without any further manual changes, then my passed argument value is stored in the new Session Data, meaning that while one is shown, the other is actually in effect. This is of course problematic and I hope you have a solution that helps to enforce display of the currently stored variable value. Incidently, if I do NOT read in my Session Data but only update my form variable with the URL argument in the way given above, then the value passed both updates the form variable AND is displayed.

2. While I can get the above going for simple text variables, I can not figure out how to do this for a specific checkbox index. - Let's say I pass an argument of 3 and thus want to tick the third checkbox in a group of 6 using PHP code in a Custom Code action. How do I do this? Either of the possibilities you give below sound good, but I am afraid I am neither PHP, nor JS literate, so I would need a pointer to get me going. I'll then happily rtfm my way to success...

P.S. I use ChronoForms 4.0 RC2.

Thanks,
Ingmar

Hi Ingmar,

I've read this a couple of times and end up more confused.

I do not see how the code snippet you posted will add any value to your form?

As I said in my last post the ChronoForms Republish code which is set 'On' by default will load any data - including checkbox data - from the $form->data array into the form.

You can add data to the array with a DB Load Record action, a Session to Data action, submission from an earlier form, a custom code action, etc. If you use more than one then the actual values are used depends on the last data loaded.

Bob

Hi Bob,

I checked back and indeed, it is not the code I gave at all that inserts the values into the form. Instead my URL parameter simply had the same name as the form variable I targeted and this caused the variable to be filled with the value passed "automagically". I tested this meachanism and found that this holds true for as many variables as I wish to populate by passing params to them. If I have a form with three variables "first_name", "last_name" and "check_boxes", then passing three parameters with values to them reliably populates the corresponding form variables. Better yet, if I pass multiple values to my check_boxes variable, such as "choice1,choice3" then this ticks ALL of the correct boxes! This is good news and sorry about the confusion caused by giving irrelevant code.

However, since my aim is not to simply populate a form, but to integrate new check_box values passed in a URL param with already ticked ones I am using the Session actions to save and republish the form data in On Load and On Submit. In order to make this work with multiple checkboxes I had to patch data_republish.php according to a forum post I found (by you and castagnier), which did the trick. - In this case I now have passed parameters and stored parameters that compete for which get shown and which are stored internally and this is where I run into problems:

- Using both URL parameter passing AND republishing of stored session data "On Load" causes for the session data to be shown in the form, but for the passed parameter values to be used for submission.
- Manual editing of a form populated in this way does not have any effect. It always is the parameter values passed via the URL that are stored whenever I hit submit.

This could of course be due to me not using the correct action parameters, but I have tried all (seemingly) sensible action sequences and parameter settings and the effect remains the exact same: Parameters passed override session data storage in the form, but are not shown in the form. Manual updates have no effect. My feeling is that this either is a scenario that was not intended/anticipated or that this behavior could possibly be a bug.

If I am still failing to make myself clear, I would be happy to pack up my two example forms with/without session data integration and send you these together with a couple of URLs you could copy and paste to a page for a quick look.

P.S. Using the $form->data reference you gave below as a start, I fiddled a bit and have found out how to access both the values currently stored in the form as well as the values passed to the form. Seems like a good start both towards getting the job done and to learning PHP, so I will try to get my new/old checkbox value integration going myself and will only bug you again if I lose it.

Best regards,
Ingmar

Hi Ingmar,

I don't understand why this is happening:

Using both URL parameter passing AND republishing of stored session data "On Load" causes for the session data to be shown in the form, but for the passed parameter values to be used for submission.
- Manual editing of a form populated in this way does not have any effect. It always is the parameter values passed via the URL that are stored whenever I hit submit.

The On Load actions will update the values shown in the form . . . but they should have no effect on the values submitted by the form afterwards.

Please post a link to the form so I can take a quick look.

Bob

Hi Ingmar,

Add this code in a custom code action before the next form is loaded, that's before the "Show HTML" action in the 2nd form's "on load" event:

<?php
//assuming your checkbox group name is "mycheck"
$form->data['mycheck'] = array('3');
?>

So, assuming that one of your checkboxes has the value = "3" then it should be ticked.

I think that should help you ?

Regards,
Max

Hi Bob,

my site is not online, so I have sent you the site info in a PM.

Here are two walkthroughs that you might want to follow to reliably see the effect I am seeing before you start checking into the why and how.

Problem 1: Competing values for storage and display
1. Click link in "Call PassArgument2Form ChronoForm without passing parameters".
2. Enter e.g. "Bob", "Janes" and check box "Fourth".
3. Submit
4. Click link in "Pass Midget, Queen and choice2,choice3 to PassArgument2Form ChronoForm".
5. Note that it is not the passed parameters "Midget", "Queen" and the checkboxes 2 and 3 that are shown, but instead "Bob", "Janes" and that checkbox 4 is ticked. Also note that my echo() debug string below the Debug window shows that the correct values were passed to the form.
6. Do not edit, but simply Submit.
7. In Home Screen, click link in "Call PassArgument2Form ChronoForm without passing parameters" again.
8. Note that the form now shows "Midget", "Queen" and checkboxes 2 and 3 are ticked.

- It is thus the passed parameters that are saved upon submit, not the parameters shown in the form.

Problem 2: Manual editing not having any effect
1. Start over by going back to home screen.
2. Click link in "Call PassArgument2Form ChronoForm without passing parameters".
3. Enter e.g. "Bob", "Janes" and check box "Fourth".
4. Submit
2. Click link in "Call PassArgument2Form ChronoForm without passing parameters" again to verify that "Bob", "Janes" and checkbox 4 were correctly stored and retrieved to/from Session data.
5. Back in home screen click link in "Pass Midget, Queen and choice2,choice3 to PassArgument2Form ChronoForm".
6. Again note that it is not the passed parameters "Midget", "Queen" and the checkboxes 2 and 3 that are shown, but instead still "Bob", "Janes" and that checkbox 4 is ticked. Also note that my echo() debug string shows that "Midget", "Queen" and checkboxes 2 and 3 were indeed passed to the form, but again are not displayed.
7. This time edit your last name from "Janes" to "James", then Submit.
8. Go back to home screen and then click link in "Call PassArgument2Form ChronoForm without passing parameters".
9. Note that the display is NOT "Bob", "James" and checkbox 4, but "Midget", "Queen" and checkboxes 2+3.

- In other words, editing "Janes" to "James" had no effect, since there were parameter in the "pipeline". Had you edited "Janes" to "James" when NO parameters were passed to the form, this would of course have worked as expected.

Regards,
Ingmar

Hi Ingmar,

I think I've worked out what is happening here.

I hadn't realised before that when you wrote about passing parameters you were passing them to the form in the URL.

The main problem is that when the form is submitted, ChronoForms preserves the calling URL (including the parameters) in the form action URL. This is to help redisplay forms that are embedded in modules or articles correctly. In this case though it doesn't help.

You can turn off this feature in the form General tab by setting 'Relative URL' to No. The parameters are not then preserved and the form behaves as you expect.

Form action URL with 'Relative URL' = 'Yes'

index.php?option=com_chronoforms&first_name=Midget&last_name=Queen&check_boxes=choice2,choice3&lang=en&chronoform=PassArgument2Form&event=submit

Form action URL with 'Relative URL' = 'No'

index.php?option=com_chronoforms&lang=en&chronoform=QuoteRequestCaptcha&event=submit

The second problem - at least I think it's a problem (it may be a feature??) - is that when ChronoForms proceses the submitted form it reads both the $_POST and $_GET variables and gives priority to the $_GET variables.

In libraries/chronoform.php around line 80

function process($event = null){
  if($event && !empty($this->form_name)){
    //set the form data
    if(isset($_POST) && !empty($_POST)){
      $this->data = JRequest::get('post', JREQUEST_ALLOWRAW);
    }
    if(isset($_GET) && !empty($_GET)){
      $this->data = array_merge($this->data, JRequest::get('get', JREQUEST_ALLOWRAW));
    }

I think that the array_merge should be the other way round so that the $_POST values take priority.

$this->data = array_merge(JRequest::get('get', JREQUEST_ALLOWRAW), $this->data);

If you are aware of these potential problems then it is probably not too difficult to add custom code to cover the possibilites.

Bob

Hi Bob,

thanks, this has been immensely helpful!

At first I thought that having the params ignored was NOT the way "I expected" the form to behave, but after thinking about it I realized that this is the same as calling a function with params in any other programming language. If you do not explicity do something with params passed there, then they are ignored as well, so yes, you are right, setting Relative URL to "no" does make my form behave "as expected".

The rest was easy. Still being PHP illiterate the code below may or may not be the best way to do this, but any check_box values passed in the URL are now integrated with the already ticked ones...

<?php
$form->data['check_boxes'] = array_unique (explode(',',JRequest::getString('check_boxes', '', 'get') . ',' . $form->data[check_boxes]));
asort($form->data['check_boxes']);
?>

And yes, I realize that the asort() is not even necessary, but I am German AND Capricorn. Fight it I try, win never... ;-)

Regarding "Problem 2": Since changing "Relative URL" to "No" not only causes for params passed via URL to not be used automatically during submission any longer, but also (and probably consequently) allows for manual form edits to take effect upon submission, it does not make any difference in my case whether I leave the array_merge() direction in libraries/chronoforms.php as is or exchange it.

And since setting "Relative URL" to yes vs. no actually exchanges the direction of the effect (yes: params passed rule, manual edits void; no: params passed void, manual edits rule) I suspect that this might indeed be a feature and not a bug. But this is so far beyond my current understanding of the code that I would rather leave it as is. Maybe this is something that Max could have a look at and nod it off as intended or not...

Thanks also for showing me how to automatically submit the form with the URL param '&event=submit', exactly what I needed! Where can I find out more about the possible params once can pass to the form? Besides, there are plenty of parameters to set for every form and for every form element nearly all of which I do not really understand. Does your CF 3.x Cookbook go into explaining these parameters and passable params? And would the overlap/difference ratio between CF3 and CF4 make it worthwhile to buy your book even if I plan to only work with CF4 and not with CF3 at all? If this is not the case, are you planning for a CF4 version of the book?

Cheers,
Ingmar

Hi Cristian,

We had a major spam storm that diverted me for a while :-( I'm now working backwards though some older posts.

Where can I find out more about the possible params once can pass to the form?

There aren't many in ChronoForms itself - none that I can think of off the top of my head, though you can use almost anything.

Besides, there are plenty of parameters to set for every form and for every form element nearly all of which I do not really understand. Does your CF 3.x Cookbook go into explaining these parameters and passable params? And would the overlap/difference ratio between CF3 and CF4 make it worthwhile to buy your book even if I plan to only work with CF4 and not with CF3 at all? If this is not the case, are you planning for a CF4 version of the book?

There have been two major cahnges since the Book was written. First, Max has upgraded ChronoForms to V4 which has a completely re-written admin interface and underlying form element and action sctructure and second, Joomla! has moved from 1.5 to 1.6/1.7 which has meant some small changes in the way things are coded.

That means that most of the illustrations in the book showing the ChronoForms admin interface are out of date and some (but not all) of the code examples need some tweaking. That said most of the recipes for how to do things in a form are still valid. My (very) rough extimate is that around 60% or more of the book is still valid. There are a selection of freely available chapters on my site that you can check out to see if you find them helpful.

I'd like to update the book but it's not going to happen immediately. It took about six months to write and while the update wouldn't take so long it's not going to be an overnight job either.

Bob