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 On Sep 2, 2:19 pm, Robert Walker <[email protected]> wrote: > internetchris wrote: > > 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. > > What's primarily tripping you up in your thinking has to do with the > difference between event-driven vs. request-response driven systems. > Foxpro is an event-driven system where an event loop constantly runs. > The loop monitors an event queue and responds to those events as they > arrive. This is not the case with web based applications, regardless of > the framework used to build them (apart from AJAX that is). > > Web applications work on a request-response cycle: > > 1. A user requests a form (GET /accounts/new) > 2. The server responds with HTML representing the account form > 3. The server continues processing other requests > ... time passes > 4. The user submits the form (POST /accounts) > 5. Rails routing system associates the request based on the HTTP method > (POST) and URL (/accounts) > 6. Rails calls the "create" method of accounts_controller > 7. Server response with HTML depending on the "create" action. > 8. Server waits for another request. > > This is also referred to as "stateless" communication. That's how the > web was designed. The notion of state was added onto HTTP later by using > cookies and other methods of identifying user state. > > Rather than thinking of the button as "having an event" it's really the > form itself that has the event (technically the "action" of the form). > The button is just a visual widget to provide the user a way to submit > the form. > -- > Posted viahttp://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
