• [Snippet] eForm2db 0.1BETA - Manipulate DB records via eForm and MODx DBAPI#

  • pixelchutes Reply #1, 5 years, 3 months ago

    Reply

    Capture, store and process validated form submission with E’s ...eForm + eForm2db


    eForm2db Version: 0.1 [Beta 1] Author: pixelchutes

    Requirements: eForm 1.4+

    Use:

      [list]
    • Takes validated eForm submittal data for use with the MODx DBAPI extender class.
      Reference: /manager/includes/extenders/dbapi.mysql.class.inc.php

    • Easily process database records referencing your form submission data:

    • INSERT new records to a table of your choice

    • UPDATE existing records if you'd prefer

    • DELETE records based on form submittal criteria

    • Form a query and return its record set as XML using $modx->db->getXML

    • Query a table's MetaData using $modx->db->getTableMetaData, followed by an update query on only the form fields that are named after table columns!

    • and much more!
    [/list]

    The eForm2db snippet:
    <?php
    	function eForm2db( &$fields )
    	{
    		/*---------------------------------------------------------------		
    		eForm2db 
    		Version: 0.1 [Beta 1]
    		Author: pixelchutes
    		---------------------------------------------------------------
    		Requirements:
    			eForm 1.4+
    		---------------------------------------------------------------
    		Use:
    			- Takes validated eForm submittal data for use with the MODx DBAPI extender class.								
    			- Easily process database records referencing your form submission data:				  
    			  + INSERT new records to a table of your choice				  
    			  + UPDATE existing records if you'd prefer				  
    			  + DELETE records based on form submittal criteria				  
    			  + Form a query and return its record set as XML using $modx->db->getXML				  
    			  + Query a table's MetaData using $modx->db->getTableMetaData, followed by an update query
    			    on only the form fields that are named after table columns!				    
    			  + and much more! 
    		---------------------------------------------------------------*/
    
    		// Bring needed resources into scope
    		global $modx, $table_prefix;
    
    		// Init our array
    		$dbTable = array(); // key = DB Column; Value = Insert/Update value
    
    		// Insert field/value pairs to insert/update in our table
    		$dbTable[name] = $fields[first_name].' '.$fields[last_name]; // Merge two form fields together
    		$dbTable[datetime] = date( 'YmdHis', strtotime( $fields[postdate] ) ); // Massage the postdate timestamp to be MySQL insert friendly
    
    
    		// INSERT - $dbQuery = $modx->db->insert( $dbTable, $table_prefix . 'insertTableName' );
    		// UPDATE - $dbQuery = $modx->db->update( $dbTable, $table_prefix . 'updateTableName' );
    		// DELETE - $dbQuery = $modx->db->delete( $table_prefix . 'deleteFromTableName', 'some_field = 1 AND name=\''.$dbTable[name].'\'', '' );
    		// etc...
    				
    		// Run the db insert query
    		$dbQuery = $modx->db->insert( $dbTable, $table_prefix . 'insertTableName' );		
    
    		return true;
    	}
    	// Return empty string
    	return '';
    ?>
    


    Implementation:
    Add the snippet call before your eForm snippet call:
    [[eForm2db]]
    


    Utilize eForm's "callback functions" in your eForm snippet call:
    [!eForm? &noemail=`true` &formid=`contact` &eFormOnBeforeMailSent=`eForm2db` &tpl=`contactform` &thankyou=`contactthanks` !]
    


    NOTES: - &noemail param is optional. Here, I have used this call solely as a db capture form. Since no email is sent, there is no need to define things like: to, from, report, subject, etc. Simply disable mailing, and use the callback function to process your form's validated fields!

    - This is my first attempt at giving back to this community. MODx is definitely the next level. While I realize eForm2db is not modular in any way-shape-form, it is indeed its direction. What do you think? Would this make a better Module? Plugin? etc... What direction should we take this to allow modular, customizable processing of eForm submittal?
    More on the DBAPI:
    http://www.modxcms.com/dbapi.html


  • kudolink Reply #2, 5 years, 3 months ago

    Reply

    As soon as I start believing this is true I'll have other words.

    Sincerely this is a post to have this thread in my "Show new replies to your posts" page. But this is very, very very interesting, truly.


  • davidm Reply #3, 5 years, 3 months ago

    Reply
    Indeed !

    Really this really would take eForm to the next level... Not qualified to give you input as to which direction you should take, but it's really impressive and I am eager to see it in action...

    Bookmarking this thread also


  • sottwell Reply #4, 5 years, 3 months ago

    Reply
    Thank you! I've been meaning to dig into eForm to figure out how to use those two events, now I see how easy it is!

    Now all we need is another event in eForm, onBeforeFormLoad, where we can grab data from a database to populate the form fields with for profile editing!


  • pixelchutes Reply #5, 5 years, 3 months ago

    Reply
    @kudo/david/susan-- Thank you all for your interest, as well as your contributions!

    I'd also like to give a hand out to the developer(s) behind the DBAPI. Once I realized this piece was already in place, I couldn't believe how easy it really was.

    As you can see, a quick array and you're inserting/deleting/updating in no time! No connection logic, etc.
    Ya know, I like the onBeforeFormLoad idea...it actually would be quite easy. Thanks, Toby!




  • sottwell Reply #6, 5 years, 3 months ago

    Reply
    Ya know, I like the onBeforeFormLoad idea...it actually would be quite easy.
    However, I think TobyL's intentions may have been to keep [ eForm <-> "DB Stuff" ] separate to reduce "bloated code"? Especially since his callback functions allow for it the way I've illustrated here.

    Indeed, and I agree with the idea of keeping eForm itself clean. That's why I was thinking another event, so the database (or whatever... this could be used to load the $fields array with SESSION values, even) results could get loaded into the $fields array, but the developer would make his own snippet to do that, just as you have done.


  • pixelchutes Reply #7, 5 years, 3 months ago

    Reply
    Quote from: sottwell at Oct 19, 2006, 11:03 PM
    Indeed, and I agree with the idea of keeping eForm itself clean. That's why I was thinking another event, so the database (or whatever... this could be used to load the $fields array with SESSION values, even) results could get loaded into the $fields array, but the developer would make his own snippet to do that, just as you have done.

    I believe the form is not fully parsed until after it's first submission...wait, that can't be true since the parser DOES remove all" tags...

    In that case, we might need to create db2eForm


  • sottwell Reply #8, 5 years, 3 months ago

    Reply
    Exactly! But we need to be able to get that data before the form is parsed, so the data will get inserted as the form is being parsed. That means another event, so we can (with our db2eForm snippet) go get the data and tell eForm to insert it.

    I did something similar, getting data from the SESSION and loading it into the $fields array, but I hacked eForm to do it. Much better to have an event to work with.


  • pixelchutes Reply #9, 5 years, 3 months ago

    Reply
    Quote from: kudolink at Oct 19, 2006, 08:05 PM

    As soon as I start believing this is true I'll have other words.

    Sincerely this is a post to have this thread in my "Show new replies to your posts" page. But this is very, very very interesting, truly.

    BTW, believe it! I was up and running in 10 minutes and was inserting and deleting db records Your imagination is really the limit with this one. Just a nudge in the right direction...


  • xwisdom Reply #10, 5 years, 3 months ago

    Reply
    Very nice pixelchutes! Man you're light years ahead

    Some DB features are on the to-do list for version 3.0 but it's nice to see that you have gotten a good head start with the built-in events

    Here's one way I'm planning on adding support for data columns (or content fields) in 2.0 that you might find interesting:

    New attribute

    Note here that the -50 represents the length of the field. More on this in time to come.