Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Form and Response

Status
Not open for further replies.

xwb

Programmer
Jul 11, 2002
6,828
GB
I've always coded the form and response in two separate files. Recently, I picked up a PHP book that said it would be better to put them both in the same file. I actually find this confusing as I tend to mix up the form generation code with the validation code. Probably a hangover from my asp days.

As I'm the only PHP coder in my group, I've got nobody to ask. Which is the preferred technique: form and response together or separately?
 
It really depends on what you are doing.

Usually its easier to have the processing in the same file as the form as it makes re-rendering the form with the values, and output any messages directly onto the form easier and just slightly quicker, since you don't have to redirect, and then store any form values you wish to be re-displayed in the form.

Of course there can be times when you have a very complex display generation, and its cleaner to have a the form separate from the rest of the processing.







----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.
 
Personally I like to keep everything in one file, with lots of commented lines so I can see how the file splits down, but it's not always the best choice. However, I don't think it makes too much difference to how fast things execute, so either way.

I think if the calculation on form process is not too complicated then it's purely down to personal preference, books will always advise you of how the author likes to do things, which does not always make it better.
 
Which is the preferred technique: form and response together or separately?

personally i use a modified despatch technique for all my applications. instead of separating my files into execution/display etc, the files are separated into entity based elements. each entity page then has its own sub-despatcher (mostly). it is very rare that i have a file dedicated solely to html.

whilst this does not answer your question directly, it should give you some useful architectural backdrop, and once you've gone through the information in the link and checked out a few samples of dispatch based programming you'll probably find that, like me, coders nowadays keep form display and form processing in the same scope.
 
There is also the MVC apprach (Model, View, Controler) pattern which seperates the View (i.e. the HTML) from the code (the php) and the bit in the middle that controls it all (the Controller). If you use a template engine such as Smarty you have no real option other than to sperate them this way.
Another advantage to seperating the code and the HTML is you can have two people working on it. I.e A graphic person doing the HTML (not me !!) and a techie doing the code.
Either way you might end up with a bit of php in the htm to call the php routines to the the work and to display the values to the form.
Finally my fave is if you put the php in seperate files you get some reuse as the code isn't embedded in the HTML, you might for example eant to expose sonme functionality as a web service. A usefull approach when PHP6 comes out and you can just re-engineer the php code itself and test in isolation before you get to web servers and stuff like that.
Proabbly a million ways to do it really !
 
Had a bit more of a think about this as well.
AJAX is becoming more and more popular and completly changes how we think about web app, much more of the orchestration will be done in the browser via JavaScript with the PHP simply providing business services. Of course the main page may be PHP or might even be flat HTML.
Going back to the original point of seprating code from HTML. The Microsoft .NET framework encourages and supports this by a technique they call code behind.
 
Thanks for the very interesting responses.

Also thanks to jpadie for the link - I tried the spoofing techniques (nothing to do with this thread) to break my own site but I'd already built in some protection so they didn't quite work. Quite useful to know.

MS has quite an interesting technique: they use some form of encrypted javascript which calls a server side routine.
 
@ingresman

are you allowed to mention .Net in a php forum without spitting and throwing salt over your left shoulder (link)?
 
.net in this case is just web services which can probably be implemented in php. No need to waste the salt. Just call it web services - the generic name.
 
Salt at the ready !, we can learn a lot from MS (both good and bad)
no .Net here is the framework itself. If you create a web service using, say asp.net as a .aspx you can use code behind to place the code in a sperate file. I was just taking about the technique.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top