|
|
Posted by Jerry Stuckle on 08/10/07 21:47
ELINTPimp wrote:
> 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).
>
Assuming they want the data pushed to the database immediately. They
may not. That's where the requirements need to be determined more fully.
> 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.
>
Understood :-)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|