|
|
Posted by Jerry Stuckle on 08/10/07 17:39
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.
And you have to call javascript anyway.
> 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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|