Topic: [Snippet] eForm2db 0.1BETA - Manipulate DB records via eForm and MODx DBAPI  (Read 72296 times)

Pages: 1 [2] 3 4 ... 10   Go Down

#21: 9-Jan-2007, 07:12 PM

capricorn116
Posts: 14

Is there an example of the full snippet from the example given back in October?  I've gotten eform working.  I've gotten eForm2db inserting rows in the MySQL table with each eform submission, but it's not inserting any data.

I've got a feeling that I'm missing a part of the snippet.

Also, are there future plans to make eForm2db so that it accepts parameters like eform does?  I'd like to have one instance of eForm2db running and then manipulate the variables for each form that needs it.

#22: 11-Jan-2007, 01:31 PM

Coding Team

pixelchutes
Posts: 886

WWW
Give me a moment and I'll provide something for you! Wink
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#23: 11-Jan-2007, 06:19 PM

capricorn116
Posts: 14

Pixelchutes, your timing couldn't be better.  I've been working on converting one of my employers Web sites to MODx, but without eform2db, the project will be scrapped.  My clients always want their data dumped back to MySQL.  Appreciate the help.

#24: 11-Jan-2007, 07:23 PM

Coding Team

pixelchutes
Posts: 886

WWW
Pixelchutes, your timing couldn't be better.  I've been working on converting one of my employers Web sites to MODx, but without eform2db, the project will be scrapped.  My clients always want their data dumped back to MySQL.  Appreciate the help.



I have sent you a PM Cheesy
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#25: 11-Jan-2007, 11:40 PM

Coding Team

sirlancelot
Posts: 576

PHP, XML, XSL Supporter

WWW
I'm looking to expand this article about form population on the wiki, perhaps pixelchutes could offer some revisions?

#26: 12-Jan-2007, 04:06 AM

Coding Team

pixelchutes
Posts: 886

WWW
I'm looking to expand this article about form population on the wiki, perhaps pixelchutes could offer some revisions?

Nice write up! Wink I'd be happy to, once a little free time swings my way!
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#27: 15-Jan-2007, 12:49 AM

Coding Team

TobyL
Posts: 1,024

I'm looking to expand this article about form population on the wiki, perhaps pixelchutes could offer some revisions?

Nice article indeed but what is this line of code in the snippet quoted in the wiki article?
Code:
<?php
$evt 
=& $modx->event// The Snippet call event (not eFormOnBeforeFormParse event)
?>


New to me that snippet parameters are available through the modx event object without the use of a plugin  Huh Aren't you missing something essential in the tutorial?

#28: 15-Jan-2007, 04:16 PM

Coding Team

sirlancelot
Posts: 576

PHP, XML, XSL Supporter

WWW
but what is this line of code in the snippet quoted in the wiki article?
I've updated the wiki with some extra linkage, however the API pages aren't completely documented yet, but I think the article explains line 8 a little better.

Thanks for the input!

#29: 2-Feb-2007, 04:31 AM

Mouskam
Posts: 2

Hi,

I'm new to Modx but I suspect it to be of great interest...

I'm very interested in this eform2db snippet and I wonder if someone has used this snippet to dynamically generate back office forms.

My idea is to create a table structure by hand and then have modx generate dynamically the form to handle this table's data (a back office page).

A modx admin would be able to remove some fields (ids,...) from the form by unticking the unwanted fields (he's able to configure the form).
The normal user would only get the ticked fields (he gets the configured form).

I'm sure I'm not the only one who wants to avoid the creation of forms when 'all' the work has already been done on the DB side...

Am I dreaming ?

Mouskam

#30: 2-Feb-2007, 02:15 PM

Coding Team

pixelchutes
Posts: 886

WWW
MODx itself is a dream--that's the beauty. When in the world of MODx, limitations end only with your imagination.

I am currently using eForm / eForm2db methods to populate dynamic forms/assessments/surveys based of of database table definitions, and also am using eForm2db to capture/calculate assessment scores, lead capture data, etc. ...all on a multitude of production web sites.

It can be done.
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#31: 23-Mar-2007, 09:01 AM

Darkelve
Posts: 131

So do you think this could end up in one of the next ModX versions? Smiley

#32: 23-Mar-2007, 09:19 AM

Foundation

rthrash
Posts: 11,348

WWW
I suspect that eForm itself will indeed contain the functionality in a future release.
MODx is a content managmeent framework that allows web professionals to turn over sites to end-users for daily maintenance without worrying. Please help us help you when asking for assistance and read the wiki. Searching the forums from the top level helps, too.
Ryan Thrash
MODx Co-Founder
Principal @ Collabpad
work productively.
work intelligently.
work together.

#33: 23-Mar-2007, 10:19 AM

Coding Team

sottwell
Posts: 10,505

WWW
Well, I don't think that's really necessary. As it is, it's a great all-purpose "contact form" type application. The events make it extremely powerful on a custom-need basis. I'm afraid any more built-in functionality would just need to be hacked and modded half the time as it would not quite fit the needs of most people, while creating functions to trap the various events is endlessly customizable without touching the core eForm code.

What is needed is more examples and tutorials and "how-to" articles on using the various events. So this is a call to anybody making functions for any eForm events to please add them to the Wiki for our edification!
sottwell.com has moved to a lovely Solaris 10 server!
Log in username guest, password guestuser.
Templates are now becoming available at http://sottwell.com/templates.html

#34: 23-Mar-2007, 11:17 AM

Coding Team

pixelchutes
Posts: 886

WWW
Well, I don't think that's really necessary. As it is, it's a great all-purpose "contact form" type application. The events make it extremely powerful on a custom-need basis. I'm afraid any more built-in functionality would just need to be hacked and modded half the time as it would not quite fit the needs of most people, while creating functions to trap the various events is endlessly customizable without touching the core eForm code.

What is needed is more examples and tutorials and "how-to" articles on using the various events. So this is a call to anybody making functions for any eForm events to please add them to the Wiki for our edification!

Susan is completely right. Just like MODx and its System Events, eForm is very powerful and extensible because of its built in injection functions. I have used the SAME eForm core code with quite a  few DIFFERENT variations of eForm system event functions, etc, all making for a completely customized experience.

Understanding "eForm2db", as its called, is no more difficult than reading through the DBAPI documentation and understanding the submittal process of eForm.
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#35: 23-Mar-2007, 10:19 PM

Coding Team

TobyL
Posts: 1,024

Susan is completely right. Just like MODx and its System Events, eForm is very powerful and extensible because of its built in injection functions. I have used the SAME eForm core code with quite a  few DIFFERENT variations of eForm system event functions, etc, all making for a completely customized experience.

How true! And the next major version will in fact concentrate even more on core functions and improve the ease of extendability. Some of the functionallity will in fact be removed from the core and be implemented as "default" extensions. How events (and other extensions) are called will be standardized and have access to all eForm parameters and variables.

#36: 23-Mar-2007, 10:29 PM

Testers

ZAP
Posts: 1,619

It seems as if it would be really useful to include a library of functions, extensions, and regex expressions available that people can make use of with the package or in the repository somewhere.
"Things are not what they appear to be; nor are they otherwise." - Buddha

"Well, gee, Buddha - that wasn't very helpful..." - ZAP

Useful MODx links: documentation | wiki  | forum guidelines  | bugs & requests  | info you should include with your post | commercial support options

#37: 23-Mar-2007, 10:50 PM

Coding Team

pixelchutes
Posts: 886

WWW
It seems as if it would be really useful to include a library of functions, extensions, and regex expressions available that people can make use of with the package or in the repository somewhere.

...and possibly make them very basic, and perhaps extendible themselves? Wink Ah, plugins for eForm...NOW we're talking!
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

#38: 20-Apr-2007, 07:19 AM

Raavi
Posts: 165

I love MODx!

Great snippet. very very useful. I actually got it to work  Grin

One issue... resubmitting the form i.e. if I refresh the page... re-enters the data in the database. Whereas eForm shows a message like this "This form was already submitted succesfully. There is no need to submit your information multiple times."

How can we curb multiple/duplicate entries in to the database of the same form data.

#39: 20-Apr-2007, 07:22 AM

sderuiter
Posts: 138

Great snippet. very very useful. I actually got it to work  Grin

Would you be able to post your working snippet code? Thanks.

#40: 20-Apr-2007, 09:58 AM

Coding Team

pixelchutes
Posts: 886

WWW
Great snippet. very very useful. I actually got it to work  Grin

One issue... resubmitting the form i.e. if I refresh the page... re-enters the data in the database. Whereas eForm shows a message like this "This form was already submitted succesfully. There is no need to submit your information multiple times."

How can we curb multiple/duplicate entries in to the database of the same form data.


Are you by chance using &gotoid= parameter? I think if you use gotoid to point to a different page, that refreshing the ending page does not resubmit POST data. This may be one way to prevent your issue.

Another possible solution is to use a plugin/snippet to create a unique SESSION_ID for the current user. If you can insert this SESSION_ID in your table during INSERT/UPDATE, write the logic to first check that the currently defined SESSION_ID does not exist in the table prior to INSERT, etc.

If you can't alter your db table, you could always set some sort of BOOLEAN/FLAG on successful insert and store in PHP's
$_SESSION
scope.

If eForm is throwing the message the form was already submitted, but db insert is still occuring, try using an alternate eForm custom function handler other than eFormOnBeforeMailSent, such as eFormOnMailSent (Thanks, TobyL!)

NOTE: I have updated the primary example to use this function.

I have done this before using and a custom preventDupes function:
Code:
&eFormOnBeforeFormMerge=`preventDupes`

function preventDupes()
    {
	
    global 
$modx;
	
    
	
	
// Confirm if dupe
	
	
$checkDupe_sql $modx->dbQuery('
	
	
	
select
	
	
	
	
count(*) as count
	
	
	
from
	
	
	
	
your_database.your_table
	
	
	
where
	
	
	
	
session_id = "'
.$_SESSION[unique_id_defined_earlier].'"
	
	
'
);

	
	
// NOTE: The above section could be modified to check for a flag stored in $_SESSION, rather than in the db table...

	
	
// Check that dupes don't exist for provided temp_id
	
	
if( 
array_shift$modx->fetchRow$checkDupe_sql) ) > )
	
	
{
	
	
	
// Set placeholders
	
	
	
$chunkArr = array(
	
	
	
	
'dupe_entry' => 'It appears you have already completed this action. Duplicate entries are not allowed. Thank you.'
	
	
	
);

	
	
	
// Output the dupe alert
	
	
	
echo 
$modx->parseChunk'dupe_entry_tpl'$chunkArr'[+''+]' );
	
	
	

	
	
	
// Prevent form load
	
	
	
return 
false;
	
	
}

    
	
return 
true;
    }

This is where dupe_entry_tpl is a Chunk containing a Duplicate Entry Error placeholder [+dupe_entry+] and any other markup for styling of the message, etc.

Just a possible way to help with dupe inserts...I'm not sure it's the fault of either eform or eform2db, rather the result of one's browser navigation behavior negatively impacting a simplistic design (e.g. The main eForm2db example is very simple and not very cautious)


« Last Edit: 20-Apr-2007, 02:00 PM by pixelchutes »
Mike Reid - www.pixelchutes.com
MODx Team Member / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.
Pages: 1 [2] 3 4 ... 10   Go Up
0 Members and 1 Guest are viewing this topic.