Posted by ELINTPimp on 08/10/07 18:36

On Aug 10, 1:39 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> ELINTPimp wrote:
> > On Aug 10, 10:33 am, "www.gerardvignes.com" <gerardvig...@gmail.com>
> > wrote:
> >> On Aug 10, 5:03 am, Daniel <d_pinea...@hotmail.com> wrote:
>
> >>> Hello,
> >>> Could someone explain/demonstrate how I can create a 'continuous
> >>> form' (similar to access) but in a webpage using php. What I am
> >>> trying to do is have and entry input, if the user enters info then
> >>> make another input available and so on. This way they can enter as
> >>> many items as they need. Then loop through each of their entry and
> >>> perform my action. If there is a proper web term for what I am trying
> >>> to accomplish could you please let me know so I start using the proper
> >>> terminology.
> >>> Thank you for the help.
> >>> Daniel
> >> Hi Daniel,
>
> >> I've seen this done using DHTML (JavaScript and DOM). If you support
> >> only the later versions of most major browsers, it should be cross-
> >> browser enough to be viable. If you go all the way back to IE4/NN4,
> >> you will probably run into critical differences between those two
> >> browsers. Pain.
>
> >> An event (either on a text box, radio button, check box or button)
> >> invokes a JavaScript that adds additional elements to a form.
> >> JavaScript can manimulate the web page (and thus the form) via the
> >> Document Object Model. This is a standard API which allows you to
> >> create additional nodes (div, input, ...).
>
> >> You could do it with only HTML and PHP, but it would require a round
> >> trip to the server each time the user needs to add another input. That
> >> is a bad thing.
>
> >> You can also use an Ajax solution to process input back to the server
> >> as it is typed in the browser by the client. This is a fancy version
> >> of the DHTML solution I suggested earlier. This is probably also a bad
> >> approach, since the traffic generated could easily overwhelm a busy
> >> server. A complex and inefficient solution. The worst of both worlds.
>
> >> I wonder if the Dojo toolkit can handle this problem? I believe it
> >> integrates well with Cake or ZendFramework.
>
> >> I hope this helps you.
>
> >> Gerard Vignes
>
> > All good points from Gerard...
>
> > Agreed, AJAX could be overwhelming to a server if not done properly,
> > however, when triggered correctly to contact the server, really
> > doesn't create the doom and gloom scenario. We're not turning the web
> > server into a 1sec/call RSS server, I'm talking triggered (event-
> > oriented) submissions. AJAX gives a large benefit in many web
> > application scenarios in that it does no longer require (hope) the
> > user *remembers* to click Save before they exit/session expires/etc.
>
> > No offense to DHTML, but in my opinion, all that DOM manipulation work
> > to just have to save the form once the user is complete seems like a
> > waste of time to me (most of the time). You're still going to have to
> > do a page refresh anytime the user wants to save, if the user
> > remembers to save periodically (depending on the application, of
> > course). If you're not wanting to do AJAX (which CakePHP supports but
> > I don't think a project like this definitely warrants a full-blows
> > MVC), perhaps the best/easiest would be to just do a refresh per row.
> > Assuming bandwidth isn't too bad, a call to the server to process an
> > individual request and send back a completed table with a new row.
>
> Isn't it a lot MORE waste of time to make a complete round trip to the
> server - not to mention unnecessary server load.
>

Yes, of course it is. I guess here I was trying to point out that if
I was doing DOM manipulating for a project like this to make a new
row, I would go the extra step to have AJAX push the data to the
server behind the scenes to save the record at the same time. If it
was a small project and needed to be done in a real hurry, and those
other variables I mentioned (bandwidth, etc) weren't a concern, I
might do it without client-side. (Also if browser compatibility was a
concern).

Perhaps I'm a bit jaded with the type of applications and type of
customers I typically have.

> > Client side scripting has it's place, and this project might not
> > warrant it, but often times if I'm going to do something fancy with
> > DHTML, AJAX is only a hop away to a more desktop-application-like
> > product.
>
> This is a perfect use for client side scripting. No extra trip to the
> server needed just to add a new row to the window.
>
> AJAX has it's place. But it's not the answer to everything.
>

I guess I was coming off a bit strong as AJAX or the highway, but I do
see utility in even a seemingly simple type of application as the
original post was about. I truly don't feel that AJAX is the solution
to everything, I guess I'm having a pro-AJAX day.

[Back to original message]