suggestions wanted concerning form handling "template"

[DJ Majestik]

OK, I am devising a php page that will handle a form submission, and
wanted to know if anyone has already setup such an idea, or if you had
links to point to good tutorials on this.

Basically I have a form (which I use smarty templating to display, and
smartyvalidator to validate).

The php page basically is driven by the action variable (add,
add_confirm, edit, edit_confirm, view, delete). When the form starts
out, it is in view mode. Then if you click the add button, it switches
to add mode. Confirming a new addition sends you into add_confirm
(which would write to a DB, etc.). Edit would work the same way, except
edit mode would lookup a record to display, edit_confirm would update
that record, delete mode would delete, and view mode would basically
display data (to edit/add/delete).

Sounds easy, but my code is pretty long and I am looking to simplify
this idea. Looking for how you all do this, and if anyone has a
"template" setup to do this.

Mine would be something like:

if ($action == "view") {
// do something

..... etc ....

Ideas? Let me know. Thanks,
Jim

[Kenneth Downs]

Re: suggestions wanted concerning form handling "template& quot;

DJ Majestik wrote:
[color=blue]
> OK, I am devising a php page that will handle a form submission, and
> wanted to know if anyone has already setup such an idea, or if you had
> links to point to good tutorials on this.
>
> Basically I have a form (which I use smarty templating to display, and
> smartyvalidator to validate).
>
> The php page basically is driven by the action variable (add,
> add_confirm, edit, edit_confirm, view, delete). When the form starts
> out, it is in view mode. Then if you click the add button, it switches
> to add mode. Confirming a new addition sends you into add_confirm
> (which would write to a DB, etc.). Edit would work the same way, except
> edit mode would lookup a record to display, edit_confirm would update
> that record, delete mode would delete, and view mode would basically
> display data (to edit/add/delete).
>
> Sounds easy, but my code is pretty long and I am looking to simplify
> this idea. Looking for how you all do this, and if anyone has a
> "template" setup to do this.
>
> Mine would be something like:
>
> if ($action == "view") {
> // do something
>
> .... etc ....
>
> Ideas? Let me know. Thanks,
> Jim[/color]

I don't know what you mean by "long", but our body of code that does this
is:

1) The HTML file at 332 lines
2) The processing file at 155 lines
3) About 200 lines of code in our main library

Each table also has a separate file that defines all of its parameters, but
these are computer-generated so we don't really think about length.

So anyway, your basic approach seems sound, but I'll warn you of one thing
we ran into. We allow two states, a browse of search results, and a
one-row detail view. This complicates the code a bit.

We've done away with the switch-to-edit-mode, it is not really necessary.
When a user views a row, they can save or not save, they are always in edit
mode.

We've done away with fancy client-side javascript control of the page and do
lots of round trips to the server. Here is one reason. If the user is
editing a row, then the column "state" might be a drop-down list of US
States. But if the user is in "search" mode, then you want free-form entry
there.

Hope this helps, we have done a complete version of this so I'd be happy to
answer any questions I can.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[DJ Majestik]

Re: suggestions wanted concerning form handling "template& quot;

Definitely helps, thanks! These are all things I hadn't thought about.
If anyone has any other ideas, they are definitely helping in
"solidifyin g" my code.

I want to basically write a template, then use that for other forms
(modifying stuff like DB, etc.) but the flow would remain the same.

Thanks again,
JJ

[Kenneth Downs]

Re: suggestions wanted concerning form handling "template& quot;

DJ Majestik wrote:
[color=blue]
> Definitely helps, thanks! These are all things I hadn't thought about.
> If anyone has any other ideas, they are definitely helping in
> "solidifyin g" my code.
>
> I want to basically write a template, then use that for other forms
> (modifying stuff like DB, etc.) but the flow would remain the same.
>
> Thanks again,
> JJ[/color]

Concerning templates, there are two schools of thought there, at least.

School one is the one-file-per-table method. Here the programmer codes up
the HTML and other stuff on a table-by-table method. Sounds easy at first
because one page goes fast, but it bogs down really fast when the system
grows. The advantage of OO here is illusory, you can do just as well with
wrappers. But whether you use OO or wrappers the unavoidable fact is that
there *must* be a file for each table, and that determines how the rest of
your life will go with this project.

School two, of which I am a humble member, is the library+data method. You
have a single library of generic code, and the only difference from table
to table is a body of meta-data that describes each table. The library
does HTML generation, formulates SELECT and INSERT statements and so forth.

My own opinion is that there is no real advantage to School One at all, it
appears that you can get working code faster, but it turns out to be an
illusion. The actual speed to *production* code is faster with School two,
because there is far less code to write. The real reason most people avoid
School Two is that it requires you to think a little bit before you code.

Another advantage of school two is that it is very flexible about when to
generate code. You can use the library to grind out a bunch of HTML
fragments for each table, or you can run them out on demand for each table
access, but you use the same code in both cases.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[DJ Majestik]

Re: suggestions wanted concerning form handling "template& quot;

Ken,

You and I are on the same wavelengths. I am actually utilizing your
"school 2" ideology presently in my coding. I think that OO would be
nice, but in a PHP 4 world, I think it makes more sense to use
libraries. I have basic common functionality broken out that does all
teh DB stuff, validation stuff, etc.

So that is exactly what I am doing. Do you use my idea of "actions" to
drive what you do in the PHP code.

As an aside, I use Smarty templating for the HTML, and PEAR for the DB
abstraction, etc. I am just trying to simplify the process.

So it appears that I am on the right track.

Thanks,
JJ

[Kenneth Downs]

Re: suggestions wanted concerning form handling "template& quot;

DJ Majestik wrote:
[color=blue]
> Ken,
>
> You and I are on the same wavelengths. I am actually utilizing your
> "school 2" ideology presently in my coding. I think that OO would be
> nice, but in a PHP 4 world, I think it makes more sense to use
> libraries. I have basic common functionality broken out that does all
> teh DB stuff, validation stuff, etc.
>
> So that is exactly what I am doing. Do you use my idea of "actions" to
> drive what you do in the PHP code.
>[/color]

Yes, this is our code for that:

switch ($this->gp_action) {
case "":
SessionSet("tab les_".$this->table_id."_sea rch",array());
case "searchexecute" :
break;
case "savesearch ":
SessionSet("tab les_".$this->table_id."_sea rch",CleanBoxes (true));
break;
case "del":
TABLE_DELETE($t his->table_id);
if (Errors()) {
$this->gp_action="edi t";
$this->display="boxes ";
}
break;
case "print":
$this->display="print ";
break;
case "save":
TABLE_SAVE($thi s->table_id);
$this->TriggersSaveAf ter();
$this->gp_action = "edit";
case "edit":
case "search":
case "ins":
$this->display = "boxes";
}
[color=blue]
> As an aside, I use Smarty templating for the HTML, and PEAR for the DB
> abstraction, etc. I am just trying to simplify the process.[/color]

I tend to avoid Smarty, seems to me a lot of work. Why tell Smarty that you
are using a variable called $MyValue and then put {MyValue} into a form
when I can just put <?=$MyValue?> into the form?

Pear DB looks really good. Have not put it in yet, since we wrapped
everything in our own routines anyway.
[color=blue]
>
> So it appears that I am on the right track.
>
> Thanks,
> JJ[/color]

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[DJ Majestik]

Re: suggestions wanted concerning form handling &quot;template& quot;

Nice code, looks like a lot of what I am doing (different routines,
same idea). Smarty is good in my environment because it allows design
abstraction, i.e. I have the designer do all that work, I make
available certain variables that I want him to have and do all the work
in the back end (hence the "template" scheme I am trying to revise).

Thanks for posting your code, all this has really helped in my flow.

Take care,
JJ