Continuous Form

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

Re: Continuous Form

On Aug 10, 8:03 am, Daniel 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

It seems to me is that you want a simple updateable view of a database
table(s). (P.S. In database terminology, at least, it would be called
an updateable view).

Depending on your situation, this could be something very simple and
could/should(?) be done with a simple Active Record pattern...or could
get relatively complicated since there are so many variables. On the
UI...do you want to have a page refresh between new records or do you
want to leverage AJAX?

Check out some more information on the Active Record pattern (http://
en.wikipedia.org/wiki/Active_record_pattern) and possibly something on
AJAX if you're so inclined (not a necessity, of course).

Re: Continuous Form

On Aug 10, 5:03 am, Daniel 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

Re: Continuous Form

On Aug 10, 10:33 am, "www.gerardvignes.com"
wrote:
> On Aug 10, 5:03 am, Daniel 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.

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.

Re: Continuous Form

ELINTPimp wrote:
> 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).
Check out jQuery (http://jquery.com/). DOM manipulation is pretty stinkin'
easy with this.

Re: Continuous Form

On Aug 10, 11:59 am, Carl Vondrick wrote:
> ELINTPimp wrote:
> > 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).
>
> Check out jQuery (http://jquery.com/). DOM manipulation is pretty stinkin'
> easy with this.

Indeed! jquery, prototype (http://www.prototypejs.org/), and
script.aculo.us (http://script.aculo.us/) are all great javaScript
libraries which also have built-in support for AJAX...cakePHP, which I
mentioned before, has helpers available for AJAX too. So, even if you
are using a library, if you have a situation that could benefit from
asynchronous transfers from the web server...not too much added voodoo
to make it AJAX capable. Thus my preference of AJAX over DHTML.

Now, with that said...even though I've been promoting AJAX, most of my
projects typically roll out without much (if any) DOM manipulation,
let alone AJAX. The situation will justify the time spent on a
project. I like to look at it as a cost/benefit angle. If I'm doing
some dynamic client side manipulation, and if AJAX can benefit the
situation, I'll do it every time.

Re: Continuous Form

ELINTPimp wrote:
> On Aug 10, 10:33 am, "www.gerardvignes.com"
> wrote:
>> On Aug 10, 5:03 am, Daniel 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
==================

Re: Continuous Form

On Aug 10, 1:39 pm, Jerry Stuckle wrote:
> ELINTPimp wrote:
> > On Aug 10, 10:33 am, "www.gerardvignes.com"
> > wrote:
> >> On Aug 10, 5:03 am, Daniel 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.

Re: Continuous Form

Geocities File Manager has an interesting solution.

You can transfer from 5 to 20 files in a single upload operation. The
default offering is 5, but you specify a number between 1 and 20. It
will present you with that many fields (each field is a file path).

This involves a trip to the server every time you change the count,
since the html is generated by the server and not DHTML. It does seem
to be an efficient approach, simply because you typically know how
many files you are going to upload. And if you ask for more fields
than you use, no problems, it ignores them.

It's not a sexy solution, but it works. I used it on and off for
almost 10 years. It is actually a very nice tool.

Gerard Vignes

Re: Continuous Form

ELINTPimp wrote:
> On Aug 10, 1:39 pm, Jerry Stuckle wrote:
>> ELINTPimp wrote:
>>> On Aug 10, 10:33 am, "www.gerardvignes.com"
>>> wrote:
>>>> On Aug 10, 5:03 am, Daniel 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
==================

Re: Continuous Form

I have found another way that I think will be the solution but I don't
know how it really works,
in the CPanel file manager not the geocities, the CPanel file manager
when we upload just after we choose the file needed for uploading the
system automatically starts the process and after it finish the upload
process it opens up the browse button and input path filed once more
without any page load,
if anybody know how this system works please let me know and am sure
this will help the problem of bandwidth and server call.

shror

Re: Continuous Form

Yeah, as Gerard Vignes mentioned, this can be done with DHTML as well
as the other methods he mentioned. Here's one example:

form.php:

You Entered

foreach ($_POST['items'] as $item) {
$item = trim($item);
if ($item != '') {
?>

Re: Continuous Form

shror wrote:
> I have found another way that I think will be the solution but I don't
> know how it really works,
> in the CPanel file manager not the geocities, the CPanel file manager
> when we upload just after we choose the file needed for uploading the
> system automatically starts the process and after it finish the upload
> process it opens up the browse button and input path filed once more
> without any page load,
> if anybody know how this system works please let me know and am sure
> this will help the problem of bandwidth and server call.
>
> shror
>

Not hard to do with a little javascript. But this is a PHP newsgroup.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================