13 replies to this topic

[ikonia]

Hi all,

are there any existing snippets available for inserting values into a database ?

eg: a form submits 5 vlaues into a custom table in a mysql database ?

[Cris D.]

formHandler in your default snippet library.

[Ralph]

FormHandler is your easiest solution... You could also use $etomite->putIntTableRow() for internal database tables, or $etomite->putExtTableRow() for external database tables if you choose to create your own snippet... See the documentation for more information about these API functions...

[ikonia]

Ralph, on Nov 19 2007, 02:36 PM, said:

FormHandler is your easiest solution... You could also use $etomite->putIntTableRow() for internal database tables, or $etomite->putExtTableRow() for external database tables if you choose to create your own snippet... See the documentation for more information about these API functions...

Formhandler looks like a cracking solution, I'm wondering on your views suggested approach to using form handler but putting in

a.) validation for fields, eg: 8 of the 10 fields MUST be populated
b.) one of the fields I want to store is email address, I'd like to include an additional level of validation for an email style entry eg: bob@domain.com rather than just dklfjs;dlkfjsd in the field.

The only way I can think of doing this is

a.) mofidy the FormHanlder snippet to include this as a parameter for the fields, which is way out of my league.
b.) do some sort of checking script for the "onchange" value, so its outside of the actual FormHanlder snippet.


I think a seperate snippet will probably be needed as Ralph suggested but its worth asking your opinions.

Also as I'm connecting to tables in the eto database for this snippet can I modify formhandler to use EtoDBConnect style function and use the account information in eto, rather than hardcode a username and password into a snippet ?

thanks for your thoughts so far.

[Ralph]

I think the best solution would be to create a snippet which is loosely based on the FormHandler snippet code... When the FormHandler snippet was created, out of necessity, it was not intended for use on the public side of a website, hence the lack of validation and sanitation... It is not intended as a "one size fits all" solution but, rather, an example of how the Etomite API can be used to reduce overall coding...

If you are looking at using validation, be aware that regardless of whether or not you use client-side validation, you definitely need to have server-side validation as well as input sanitation... Client-side validation is of little help if Javascript is disabled in the client browser and also opens you up to cross server scripting attacks...

Without taking another look at the FormHandler snippet I think you could simply add in validation and sanitation routines immediately after the getFormVars() API function call, either near or replacing the calculated field assignment section... As long as all checks are performed before the two API functions that handle record inserts you should be fine... Adding in logic to redisplay a record that fails validation would also need to be taken into consideration...

To be honest, when I am coding data management interfaces for customers I don't always use all of the concepts demonstrated in the FormHandler example - usually due to task-specific complexities that offset any advantages of using a specific function...

I should also note here that Etomite does have a form class built-in, although it lacks documentation, which has Tigra Form Validation incorporated... This class allows an OOP approach to form creation... I have been playing with the code in recent days in an attempt to determine how to best document and/or improve the code...

And in closing, when working with internal database tables there is little need for passing DB related information other than the table name itself... Any of these variables could either be assigned within a snippet or passed in the snippet call itself if coded accordingly...

[ikonia]

interesting input Ralph,

big food for thought.

thank you for the input, puts more on a more realistic track rather than waste time.

[Cris D.]

Quote

Also as I'm connecting to tables in the eto database for this snippet can I modify formhandler to use EtoDBConnect style function and use the account information in eto, rather than hardcode a username and password into a snippet ?

I have had a lot of success with using the $GLOBALS variable to access etomite database variables:

$host = $GLOBALS['database_server'];	//localhost
$user = $GLOBALS['database_user'];	//root
$pass = $GLOBALS['database_password']; 	//password
$dbase= trim($GLOBALS['dbase'],'`');	//database

(Note the trim to remove the `backticks` from the database name.

There is also a lot of other etomite config variables have a look at etoInfo for the type of info available to snippet code that is collected straight from the etomite installation.

Quote

a.) mofidy the FormHanlder snippet to include this as a parameter for the fields, which is way out of my league.

b.) do some sort of checking script for the "onchange" value, so its outside of the actual FormHanlder snippet.

Regarding client-side validation, there is full documentation on setting up tigra Validation in the manager/media/tigra_form_validator/index.html. It's not as hard as you would think.

[EDIT] By the way, tigra validation goes in the form, not the formHandler snippet. [/EDIT]

Edited by Cris D., 21 November 2007 - 10:32 PM.

[Ralph]

Cris D., on Nov 21 2007, 03:45 PM, said:

I have had a lot of success with using the $GLOBALS variable to access etomite database variables:

$host = $GLOBALS['database_server'];	//localhost
$user = $GLOBALS['database_user'];	//root
$pass = $GLOBALS['database_password']; 	//password
$dbase= trim($GLOBALS['dbase'],'`');	//database

(Note the trim to remove the `backticks` from the database name.

I would recommend using the following class variables instead of $GLOBALS... These variables are created when the Etomite class in instantiated for convenience so why not take advantage of them...

$etomite->dbConfig['host']
$etomite->dbConfig['dbase']
$etomite->dbConfig['user']
$etomite->dbConfig['pass']
$etomite->dbConfig['table_prefix']
$etomite->db which is a shortcut for $etomite->dbConfig['dbase'].".".$etomite->dbConfig['table_prefix']

Quote

By the way, tigra validation goes in the form, not the formHandler snippet.

I write all of my validation code within the snippet because I use the form class to automate the process... There is a tutorial on my development site that covers this process, but it needs a re-write to convey a better method of use... I use something similar to the following code which creates the form input element, the element label, and the validation rule... I can then extract the entire validation script and place it directly into my code without any additional hand-coding...

// username input tag
$username = $form->input(
  array
  (
  'type'=>'text',
  'id'=>'username',
  'name'=>'username',
  'value'=>'',
  'label'=>
	array
	(
	'id'=>'username',
	'for'=>'username',
	'label'=>'Username:'
	),
  'validate'=>
	array
	(
	'l'=>'Username:',
	'r'=>'1',
	't'=>'username'
	)
  )
);

I know, I keep all the neat stuff to myself...

[Cris D.]

@Ralph...

Quote

There is a tutorial on my development site that covers this process, but it needs a re-write to convey a better method of use...

I tried to implement this based on the tutorial but was unsuccessful. I gave up trying when after the intro of the PL4 you said you were having problems getting it to work correctly. Have you updated your personal newForm class since PL4?

Also, when I said that the validation goes in the form not the snippet, I was referring to the use of the snippet formHandler not the newForm class. In this case it would be much easier (in my humble opinion) to place the validation in the form rather than hacking the formHandler snippet that may be used several times in a site. Just a thought.

[EDIT]
I don't want to harp on this, but it has got me genuinely perplexed. I really do not understand why the etomite class for getting the $GLOBALS variables is better than just calling them directly.

Have you seen how the etomite class is instantiated and how the variables are built? You probably wrote it...
$etomite->dbConfig['host']

is achieved with (index.php line 42)

function etomite() {
	$this->dbConfig['host'] = $GLOBALS['database_server'];

So if the class is relying on the $GLOBALS anyway, it seems more "convenient" to just call the $GLOBALS directly.

It seems you are recommending to write:
$b=$a;
$c=$b; (which now equals a).

Why not write $c=$a? or even just use $a?

I really am trying to understand this... it's probably my ongoing newbiness.
[/EDIT]

Edited by Cris D., 23 November 2007 - 12:45 PM.

[deadline]

Ralph, on Nov 19 2007, 03:36 PM, said:

FormHandler is your easiest solution... You could also use $etomite->putIntTableRow() for internal database tables, or $etomite->putExtTableRow() for external database tables if you choose to create your own snippet... See the documentation for more information about these API functions...

Hi Ralph,
As far as I understand, the terms "internal" or "external" database tables refer to the etomite database tables with prefix "etomite" (or custom one).

Since many web developpements need to add custom tables, wouldn't it be worth to let putExtTableRow() check for the default database connexion ids, avoiding then to give those extra parameters ($host, $user, $pass and $dbase) to each function call ?

On the other way, putIntTableRow() could add a single parameter (ie. $into) for our custom table (maybe the easiest and more effective way to achieve this goal)

Just a suggestion...
Thanks for your time.
Deadline

[Ralph]

@deadline

The real difference between putIntTableRow() and putExtTableRow() is that putIntTableRow() can be used to work with any table within the current database - the one your Etomite tables are in, whether using the same table prefix or not... The putExtTableRow() function is used to access a completely external MySQL database - even on on a different server...


@CrisD

Regarding the use of $etomite->dbConfig versus $GLOBALS... The idea of the Etomite class instantiation is to provide Object Oriented Programming, which means that $etomite->dbConfig is part of the currently instantiated class object... Once the values have been brought into the class object scope there should be no additional need to access the $GLOBALS... It's called good OOP practice - you can either follow OOP conventions or ignore them, it's up to you... That isn't to say that the Etomite class is the pinnacle of current OOP guidelines, but I didn't write it I just maintain it...

[deadline]

Ralph, on Nov 24 2007, 03:03 AM, said:

@deadline

The real difference between putIntTableRow() and putExtTableRow() is that putIntTableRow() can be used to work with any table within the current database - the one your Etomite tables are in, whether using the same table prefix or not... The putExtTableRow() function is used to access a completely external MySQL database - even on on a different server...

Thanks Ralph,

Then I think the API documentation should be revisited...

Quote

putIntTableRow($fields="", $into="")
// function to put a row into ANY internal database table
// INSERT's a new table row into ANY internal Etomite database table. No data validation is performed.
// $fields = a $key=>$value array: $fields=("name"=>$name,"email"=$email,"age"=>$age)
// $into = name of the internal Etomite table which will receive the new data row without database name or table prefix: $into="user_messages"
// Returns FALSE on failure.

[Ralph]

deadline, on Nov 23 2007, 09:51 PM, said:

Thanks Ralph,

Then I think the API documentation should be revisited...

The current code base reads as follows... Granted, the documentation on this site may need updating, but the API itself reads correctly... Read your index.php for the absolute newest and most accurate function documentation... If you'd like to volunteer your expertise to help amend the documentation just let either Dean or myself know...

  function putIntTableRow($fields="", $into="", $addPrefix=true) {
  // function to put a row into ANY internal database table
  // INSERT's a new table row into ANY internal Etomite database table. No data validation is performed.
  // $fields = a $key=>$value array: $fields=("name"=>$name,"email"=$email,"age"=>$age)
  // $into = name of the internal Etomite table which will receive the new data row without database name or table prefix: $into="user_messages"
  // $addPrefix = whether to check for and/or add $this->dbConfig['table_prefix'] to the table name
  // Returns FALSE on failure.

[Cris D.]

Quote

It's called good OOP practice - you can either follow OOP conventions or ignore them, it's up to you...

Oh, OK That makes sense : ) I'm still getting my head around the OOP programming style which is why it didn't "get it".

I've been developing an extention of formHandler based on some of the most common elements that I would like handled in a form. I was going to call it formHandler2 (very creative I know). It does everything Ralph's original FormHandler (it's based on it) does plus:

• Allows an input array of form fields to validate with PHP as "required fields".
  
• Validates an inputted email using several techniques including a valid domain check.
  
• It automatically creates the internal database table to store the data with fields 'id', each form field with a prefix added as 'fieldname' VARCHAR(100), email, datetime, and timestamp (the table can also be created manually of course).
  
• You can set the name of the form submit button so multiple formHandler2 snippets and forms can operate on a single page.
  
• A message on successful form submission can be set in the snippet call (optional).
  
• It comes with a complete, tested, fully commented, javaScript validated form as an example to customize.

The working version is here. Fee free to test it from the download below. I have not been able to get the datetime and timestamp auto-calculation fields to populate for some strange reason, apart from that it all works OK. This could probably do with some character- type checking, length, and header injections but too many generic checks on a generic form handler may make it difficult to use, they can alway be added later in a customisation of the snippet.

Let me know if anyone has any problems with this, I'll work on the timestamp and datetime.

@ Ikona, with compliments, let me know if you need help with the 2nd part of your project.

Attached Files

•  formHandler2.txt   8.92K   11 downloads

Edited by Cris D., 26 November 2007 - 11:20 AM.