Can someone explain something to me?

So this is a question that I keep trying to think through in my head
and it's the first time I've had to implement it in an application. I
come from a Visual Foxpro background and when I would want to add a
button to a form I could simply place it on the form and then modify
the clickevent with my custom code for that button.

In rails if I'm working on the New or Edit form I want to add a
button that finds the last record in the table, take the account
number, and then increment it by one and then replace the contents of
the account field on my form with that new number. Here's my
question....

Do I add a separate method in my controller simply for this button (ie
increment_account) or something like that? If I do this, how do I call
that from my view? Do I always call it within a form by itself? This
are fairly general questions, and probably ones I should know the
answer to, but I'm finding that I'm not entirely sure how to implement
little buttons that do special things within the "new" or "edit"
views. If someone has the time to give me an example that would be
awesome . I just want to know the proper way to implement something
like this..

Thanks!

Chris

Hello Chris:

I understand what you are attempting to do, but not sure the reasoning
behind it. In regards, to a new or edit forms, I would be incrementing
the account number when the form is posted. It might be worth looking
at the interface patterns developers use for ROR web applications
rather than thinking in terms of desktop Foxpro patterns.

However having said that, to add additional methods, in a RESTFul
world I probably add it as another resource/controller. For example,
to increment an account number I would create a controller called
AccountNumbersController (i.e. for the resource account_number) with
an update method that does the increment.

But without knowing your domain model this might be bad advice.

As a last resort, you can always add it as another method in the
controller, but I like to keep the controllers to the REST methods,
and identify the resource I'm attempting to update and create a
controller for that.

Cheers,
Nicholas

Firstly it is better to try and use a subject line that indicates
something about the problem.

Hello Chris:

I understand what you are attempting to do, but not sure the reasoning
behind it. In regards, to a new or edit forms, I would be incrementing
the account number when the form is posted. It might be worth looking
at the interface patterns developers use for ROR web applications
rather than thinking in terms of desktop Foxpro patterns.

However having said that, to add additional methods, in a RESTFul
world I probably add it as another resource/controller. For example,
to increment an account number I would create a controller called
AccountNumbersController (i.e. for the resource account_number) with
an update method that does the increment.

But without knowing your domain model this might be bad advice.

As a last resort, you can always add it as another method in the
controller, but I like to keep the controllers to the REST methods,
and identify the resource I'm attempting to update and create a
controller for that.

If you decide that a button to perform that action is what your UI
requires then the button should submit a POST to an action of one of
the controllers. It should be a POST as you are modifying the
database and you do not want google accidentally GETing the URL that
performs this action. You could have effectively an empty form with a
submit button to so this, but I expect there is a way of doing it
without a form, though I have never done this. Alternatively your
main form can have multiple submit buttons so the action will go to
the same action as your normal submit button but you can identify in
the action which button has been pressed. The button id or name or
something gets passed in the params. Look in the log at what happens
when you press a button and you will see it. Since the action you
describe does not seem to have anything to do with the main purpose of
the form however this does not seem like the best approach. However
you submit it, once the action is complete then display the original
view again.

Colin

Robert, that was a great explanation! I appreciate all of the other
replies too. A couple more question to make sure I understand
correctly...

So in all honesty this little button doesn't have much to do with the
overall process, but it makes it easier for the user to see the last
account number used so they can assign the next available account when
submitting new records. New records will be infrequent so the idea
that more than one user is posting them is probably unlikely but still
possible. I can check for this prior to saving the record.

Robert, to make sure I understand what you are saying let me summarize
my understanding...

The form submission "in it's entirety" is considered the "event" - the
only way to provide the user with information like what I want to do
is either when the page loads, via a refresh (Post) of some sort, or a
tricky ajax event. It's not possible to call little events via buttons
or forms when dealing with a web application unless I use ajax - is
that correct?

I really appreciate the help - this is something I have been grappling
with in my brain. It's simply a hold over from how I learned to
program - for better or worse.

Thanks!

Chris

internetchris wrote:

Robert, that was a great explanation! I appreciate all of the other
replies too. A couple more question to make sure I understand
correctly...

So in all honesty this little button doesn't have much to do with the
overall process, but it makes it easier for the user to see the last
account number used so they can assign the next available account when
submitting new records.

The user should probably not be assigning account numbers. That's a job
for the DB.

New records will be infrequent so the idea
that more than one user is posting them is probably unlikely but still
possible. I can check for this prior to saving the record.

Just avoid the problem entirely by letting the DB supply the number!

Robert, to make sure I understand what you are saying let me summarize
my understanding...

The form submission "in it's entirety" is considered the "event" - the
only way to provide the user with information like what I want to do
is either when the page loads, via a refresh (Post) of some sort, or a
tricky ajax event. It's not possible to call little events via buttons
or forms when dealing with a web application unless I use ajax - is
that correct?

Not quite. You can have as many forms or links to controller actions as
you like on a given page. However, absent JavaScript, each form can
only have one submit action.

I really appreciate the help - this is something I have been grappling
with in my brain. It's simply a hold over from how I learned to
program - for better or worse.

Thanks!

Chris

Best,

Marne,

Thanks for the advice - I implemented an auto-incrementing number that
the database assigns - much cleaner. My thought process was left over
from a previous app I used to work with. I just needed some help
thinking outside that box. I can auto-increment it and if the user
doesn't like it they can change it if they want.

Thanks!

Chris

internetchris wrote:

Robert, that was a great explanation! I appreciate all of the other
replies too. A couple more question to make sure I understand
correctly...

So in all honesty this little button doesn't have much to do with the
overall process, but it makes it easier for the user to see the last
account number used so they can assign the next available account when
submitting new records.

The user should probably not be assigning account numbers. That's a job
for the DB.

New records will be infrequent so the idea
that more than one user is posting them is probably unlikely but still
possible. I can check for this prior to saving the record.

Just avoid the problem entirely by letting the DB supply the number!

Robert, to make sure I understand what you are saying let me summarize
my understanding...

The form submission "in it's entirety" is considered the "event" - the
only way to provide the user with information like what I want to do
is either when the page loads, via a refresh (Post) of some sort, or a
tricky ajax event. It's not possible to call little events via buttons
or forms when dealing with a web application unless I use ajax - is
that correct?

Not quite. You can have as many forms or links to controller actions as
you like on a given page. However, absent JavaScript, each form can
only have one submit action.

Just a small clarification on this, each form can have only one submit
_action_ but it can have multiple buttons that call the action. So
you can, for example have two buttons labelled Do it and Cancel using
<%= submit_tag "Do it" %>
<%= submit_tag "Cancel" %>
and then in the action determine which button was pressed by examining
params[:commit]

Colin

So I can basically place "if" statements in the action based upon the
identification of the submit button right? That seems pretty easy
although I could see how this might be messy if a user has filled out
another part of the form and you want to make sure that information is
either saved prior to them using another type of submit button. Can
all of this be circumvented using ajax within the form? With the use
of Ajax can I submit a single call to an action without worrying about
anything else on that form?

Thanks

Chris

Many thanks to everyone, my questions have been satisfied.