Understanding code - follow-up for parents registering their children

[chiebert]

Hi all,

Re-visiting the 'how to allow parents to register their children for an event' issue:

• Anyone developed any hot-shot and current approaches using D7 and Civi 4.1?
• If not, I'm looking at some experimental code that dlobo put together a year ago (D6 and Civi3.3, I think - see http://forum.civicrm.org/index.php/topic,18478.msg78094.html#msg78094) and I'd appreciate a couple of code-reading tips:

Background to the experimental module: the workflow is...

• Send the parent to a profile to collect her info
• Redirect parent back to the event form to collect child(ren)'s info, and an API call in the postprocess hook sets up the parent-child relationship(s)
• some other fun stuff pre-populates defaults if the parent already has some children in the system

First: Among the constants defined at the head of that experimental module is PARENT_EVENT_ID. Am I right in assuming that's a hard-coded reference to a particular event that has parents registering children?

Second: At several points (notably at lines 82 and following) something like

Code: [Select]

CRM_Utils_Request::retrieve( 'mainID', 'Integer', $form, false, null, $_REQUEST ); is called. This is clearly deeply below the API - can someone enlighten me as to what's being retrieved here?

Thanks for any enlightenment!

[chiebert]

Second: At several points (notably at lines 82 and following) something like

Code: [Select]

CRM_Utils_Request::retrieve( 'mainID', 'Integer', $form, false, null, $_REQUEST ); is called. This is clearly deeply below the API - can someone enlighten me as to what's being retrieved here?

Doh. Found the class and function in CRM/Utils/Request.php (along with all sorts of other lovelies). Nice to (re)learn one's (object-oriented) PHP. :/ I've got the flow of this solution figured now.

[Eileen]

That code was written before the v3 api so that's probably one reason it doesn't use the api

[chiebert]

Gathered as much with the V2 civicrm_relationship_create() call. I'm just wondering if there's more here that's easier now...

[petednz]

this is a paid event?

[chiebert]

Yep - otherwise I'd be running to webform_civicrm for help... (assuming that's why you ask). After supper I'm going to experiment to see if chaining API v3 calls can get me a list of a given contact_ID's related (Child) contacts...

[petednz]

ha - yes it was - but decided to ask first rather than my typical "have you tried webform-civicrm"

[chiebert]

I tell ya, here's the wish-list:

- use webform_civicrm to handle all the multiple contacts/relationships heavy lifting
- redirect to civicrm's 'checkout' to handle the contribution creation
- (bonus) be able to provide a link to come back later and make a payment on the 'account' (I know: CiviAccount is supposed to make this possible, right?)

[Donald Lobo]

I think the way colemanw does it for his summer camp is:

1. uses webform_civicrm to capture parent / child relationship

2. Has custom code / hooks to compute the final amount

3. redirect to a civicrm contribition page and sets:

* the final amount
* some pre-text with the breakdown of the amount
* various default fields filled in based on submitted values in item 1

I'm pretty sure he'll be open to sharing the code

lobo

[Coleman Watts]

That's about right. (or at least that's how it ought to work, but I wrote the camp software before I wrote webform_civicrm, so the forms in step 1 are hard-coded)

For step three, I have 2 hooks: buildForm and post. The buildForm hook will do as Lobo says and print some helpful info about how much they owe and why at the top of a particular contribution form (this of course requires the user to be logged-in).
The post hook kicks in when the contribution is made... it does some fancy math to figure out how many kids they've registered, and for how many weeks each, and what discounts are applied, and how much they've already paid, and then updates each participant record to reflect the correct payment amount.

You are welcome to look at the code, but much of it will not be applicable to your situation. However I think the general approach works quite well. I recommend it
I think this workflow will work for you:

• Require the parent to create an account/login
• They can fill out their own contact info, enter their kids, and pick camp sessions all on the same webform
• BTW: By next year webform_civicrm will have gained the ability to pre-fill contacts based on relationships, so they won't have to re-enter their kids next year
• The webform redirects to a contribution page, with the above-mentioned hooks in place
• If you have online med-forms etc those could also be webforms. You'll need a little "glue" to help the parent navigate between forms.

BTW, if you're against making parents create an account, you may be able to get around it with checksums.

[chiebert]

Thanks for the break-down, Coleman. In fact, I've gotten almost all the way there in just the way you describe - awesome (Civi-lised) webform, hooking in at the end to programmatically present a nice html table summary. I'm then redirecting to a contribution page with the webform's nid and the submission's sid appended to the URL, so I can reload the submission details in hook_civircrm_buildForm.

And that's where I'm stuck: Try as I might, I can't seem to grok the method for setting markup from buildForm - I can set prices in buildAmount no problem, but I'd really like to get the summary info into the contrib page. And I know I'm targeting the right page in the hook: dpm($form); after my context logic works just fine.

Even if I could just see a snippet of your buildForm code, I sense it would bring light to the darkness.

[and then hopefully I can add something to the hooks wiki, which is woefully short of current (API v3-driven) examples! Same time as I update the multisite walk through]

[chiebert]

Oh, and: whoever finds this post - check out webform_civicrm (if you're a Drupalista). Really. Now. We'll wait for you...

[Coleman Watts]

Try as I might, I can't seem to grok the method for setting markup from buildForm

I struggled with that as well. I found a method that worked for me (overriding the form's intro text). If you were wanting to place the markup somewhere other than the top, then I'm afraid I don't know how (but I'm sure Lobo does).

Code: [Select]

$form->assign('intro_text', '<p>Hello World</p>');I think I added something about this to the hook wiki, or at least I meant to...

[chiebert]

Coleman, you are a star! I'll give $form->assign() a try - and intro_text is exactly what I was trying to change. Thank-you, and I'll feed back here the results when I get back to the work.

Peace!

[Eileen]

Re the missing api 3 examples - check the examples folder in the api/v3 folder in your install - or in svn

http://svn.civicrm.org/civicrm/branches/v4.1/api/v3/examples