proper way to import settings into a class instance?

[Leeoniya]

I've been pondering my current webapp design and trying to determine if it's optimal and good practice.

in my webapp, each From communicates with a specific table in the database, and has its own template in XHTML (maybe will convert to Smarty in the future) and a settings file which dictates form behavior on the frontend such as validation rules, which fields are not to be submitted, etc.

when a user requests the page where the form will appear, i have a Form class that loads the settings from a file (given the form_id), loads the form template and sends it to the client with the proper behavior settings (in javascript that is eval()'d on the frontend).

the way the settings are loaded into the class instance is very basic:

class:
class form {
private $id; // form id
private $upd_targ; // target update table
private $populate_qry; // db qry to return JSON formatted record data

public function __construct($id) {
include 'frm_'.$id.'_cfg.inc';
}

public function build() {
echo 'frm_'."$id.php";
}
}
settings file:
<?php
$this->id = myForm;
$this->upd_targ = 'testTable';
$this->populate_qry = "SELECT * FROM myTable JOIN myTable2 ON (myTable.id = myTable2.id) WHERE rec_id = $_GET[rec_id]";
?>
template file:
<form id="<?php echo $this->id; ?>">
<input type="text" id="testField" />
</form>

i have a lot of forms some are similar, other aren't. is this a good way to load unique settings to each form?

would i benefit from using an abstract class?

i would like to know how (and more importantly where) to add things like functions to update a Database with recieved form data...should this be a function inside the form class, or a static function in a DB abstraction class?

any help would be great,
Leon

[aedrin]

and has its own template in XHTML (maybe will convert to Smarty in the future)

Please don't, what you have is perfectly fine. You are already using a template language called PHP. No point in adding another template language which can introduce errors and have to learn/debug.

i have a lot of forms some are similar, other aren't. is this a good way to load unique settings to each form?

would i benefit from using an abstract class?

Yes. Your code isn't very movable right now. It depends a lot on external files.

You'd be better off if you could do something like this. Say you have a page called Tickets, where someone can submit new tickets.

tickets.php

$form = new Form();
$form->tableName = 'tickets';

$form->addTextField('subject', 20); // length = 20
$form->addTextAreaField('description', 50, 3); // cols = 50, rows = 3
$form->addSubmit('save');


You could further abstract this (and make it easy to extend by making it where you can do this:


$form = new Form();
$form->tableName = 'tickets';

$field = new TextField('subject');
$field->length = 20;
$form->addField($field);

$field = new TextAreaField('description');
$field->width = 50;
$field->height = 3;
$form->addField($field);

// etc.


There is no need to put the settings in a separate file. You already have a separate file, the file that is using it. If you are properly separating business logic and presentation logic, then this is the perfect place for it.

Yes, you could still keep it in a settings file. But I don't see a whole lot of benefit from it.

i would like to know how (and more importantly where) to add things like functions to update a Database with recieved form data...should this be a function inside the form class, or a static function in a DB abstraction class?

This is specific to the Form class, so you would keep it in the Form class.

The way I do it is I write the SQL dynamically based on what fields the form has. This works 90% of the time. There are always exceptions, but as long as you cover more than 80 of the 80-20 rule you are good.

There is no need to require the user of your Form class (you) to write SQL for every form. One of the reasons to use a Form class is to automatically do things like that. You just have to sit down once and write the code to create the SQL. Once that is done you can create fully functional forms in seconds.

[Leeoniya]

well the form interaction is AJAX based and the data is passed through a JSON object...so once json_decode() is called i already have the multidimensional array ready for the query building...that's the plan anyways.

there are a few good database abstraction classes (perhaps not for the actual purposes of abstraction, but rather collections of useful static functions) for transaction processing and doing things like multiple inserts from associative arrays)

i have a need to communicate to the database independent of forms, so i figured it would make sense to have any From functions in the form class to instantiate or utilize the functions in the database class rather than remaking the raw DB connection code and such.

on a side note, i just finished reading a long rant about how templating engines on top of PHP are redundant since PHP is a template engine itself. I agree, and will stick to XHTML/php templates. Also read another post about how database abstraction is pointless since 95% of migrating a database involves everything BUT php. that's not to say that you need to repeat while($row = mysql_fetch_assoc($result)) everywhere, but instead just make some helper functions for needed uses.

thanks for the advice.
Leon

[aedrin]

rather than remaking the rawn DB connection code and such.

That's what a DB class does. The form uses the DB class.

Alspo read another post about how database abstraction is pointless since 95% of migrating a database involves everything BUT php. that's not to say that you need to repeat mysql_connect() everywhere, but instead just make some helper functions for needed uses.

That's only one of the arguments for a Database wrapper. Although I don't agree with what they said.

If I wrap my Database class, I can easily switch out the mysql_connect()/mysql_query() calls for the proper calls. So yes, it does matter. Imagine trying to do that over your entire project with dozens of calls everywhere?

And if you're doing object oriented programming, why bother with creating functions? Classes are a much cleaner solution in that case.

[Leeoniya]

what they meant is creating a database abstraction class for the purpose of making a uniform interface to any database to ease a possible database migration process.

the author points out that during a switch like that, you are likely to be touching every piece of SQL code, every table index, foreign key and many other things that pertain to a real migration and that a class that provides the same interface to every database is not particularly that time saving.

I do think DB class is necessary but only to ease working with your specific DB without trying to make a one-fits all glove.

here is a direct link to the post if you want to give it a read:
http://jeremy.zawodny.com/blog/archives/002194.html

[Leeoniya]

also, the reason i keep the settings in a different file is because i may need to read or load a setting without recreating the actual form. if i put both into one file, i cannot import the settings without outputting the HTML (which also means running queries during output..etc).

One example i can readily think of is needing to determine what DB table a form needs to update on the backend, all i need to do is load the settings file to find this, which can be done without HTML output. Another instance is if i need to reset form behavior independent of outputting HTML.

i guess if there was a way to load the HTML into some kind of class property it would be ideal. but short of heredoc i don't know how to do this, without sacrificing code readability or syntax highlighting in my editor.

[aedrin]

I do think DB class is necessary but only to ease working with your specific DB without trying to make a one-fits all glove.

here is a direct link to the post if you want to give it a read:
http://jeremy.zawodny.com/blog/archives/002194.html

Two issues.

The article in a short summary says this (why does it always have to have so much bloat around it?):

- Switching a website from one database to another after it is developed is hard (no real reasons are given), so why bother with a wrapper class as it is the least of your problems
- I use a wrapper anyway because it makes it easier to switch from one database to another

Confused? I am. Credibility? Out the door.

One example i can readily think of is needing to determine what DB table a form needs to update on the backend, all i need to do is load the settings file to find this, which can be done without HTML output. Another instance is if i need to reset form behavior independent of outputting HTML.

I think you misunderstand. This is what I said earlier:

If you are properly separating business logic and presentation logic, then this is the perfect place for it.

Notice the separation bit.

Say you have a simple setup with model and view files.

model.form.php

$form = new Form();
// set a few settings
set('form', $form);


view.form.php

$form = get('form');
echo $form->getHtmlOutput();


Why do you need to read a setting of your form in something completely separate?