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.