Thread

I need to implement interactive forms within EE rendered web pages where key elements include:
  o First picking up custom user membership fields based on user sign-on,
  o Then using that key information to access records from custom MySQL tables
  o Using PHP scripting.

First of all, I’m new to setting up interactive forms using PHP and MySQL.  But my impression is that you need two web pages for any given form—one to display the initial form for input, and then a second to process the input as launched the first page’s submit button.

So I have these questions:
1. How do you serve up and render these two pages within EE?
2. What effect does the EE PHP before and after option have on doing forms as…
    - I need to pre-populate initial field values before displaying the form, and
    - I need to still kick off the process script following submit.
3. Is there working example code available off which I could pattern?

Many, many thanks. Larry A.

As I think through this, from the EE User Guide…

PHP Parsing Stage.  There are two choices for when PHP gets parsed:

Input: PHP parsed at the “input” stage will be parsed before ExpressionEngine Tags get parsed

Output: PHP parsed at the “output” stage will be the last thing done, which means it will be parsed after the ExpressionEngine tags are interpreted.

For my form page, the only EE tags I am likely to need are those to retrieve custom membership fields to then use as criteria on subsequent SQL calls. So the sequence might well be…
1. EE tags to get userid associated membership fields
2. PHP to query MySQL for initial form field values
3. PHP to slot initial field values into form HTML
4. And then render the page

So the correct answer may be to run with PHP parsing set for output.

Hi Larry - I remember talking to you at EECI about this, but could you give me a higher level refresher on what you would like to accomplish?

For example:
I want a user to fill out a form (that will be pre populated with their membership information) and select resources (which are stored in a resources channel) for us to send them.

You may not need to write your own PHP at all for this - it sounds like something you could used the solspace member module for.

Yes, I plan to use the User module to post and retrieve member information, so no PHP needed there. Otherwise, though, I think I may need to stick to traditional relational tables and queries.  Here’s why.

Table 1.  USERID, KEY.  (EE membership, User module) - say 10,000 or so
Table 2.  KEY, Entry date/hour, Entry price, Entry quantity - say 4 form submits/day/key,
      giving 40,000 recs/day, 14.6M recs/year, or 43.8M recs over a 3 year history
Table 3.  KEY to cross-reference Keys - say each key related to 30 others (so 300,000
      recs altogether, subject to daily modification)

Display Query:  Table1 x Table3 x Table2

EE tags should take care of Table1.  Which I then need to pass via PHP as selection criteria to a MySQL call to join Table3 x Table2 => with retrieved records then formatted for HTML display.

This doesn’t strike me as a typical EE content application. I could be wrong. If there is a relatively straightforward way to implement via EE channels, and thus avoid separate PHP/MySQL coding, I would certainly like to explore. All EE content posting, however, must be fully automatic and driven from submission forms. I.e., nothing manual on the EE side.

Again, any and all suggestions are very much welcomed. Thanks.

Hi Larry,

That’s rather database intensive - and while you could manage something like that with EE / custom tables it may be better to consider other options? Without knowing what you’re doing at a lower level it’s hard to say for sure.

If you do go down the EE route the best way to start an a module like this is with http://pkg.io - it just gives you the bare bones of a EE add-on.

Best, Philip

Hello Larry,

I would have to agree with Phillip here in that you are getting into territory where a custom Module would be a better solution. You would see much better performance in the long run, and the code would likely be easier to manage. Plus, you would have full integration with ExpressionEngine, could still use your custom tables, and be able to access your data via the Control Panel.

Cheers,