Say a user is halfway through filling-in a form. Then he decides that s/he has to do another thing first, maybe create another object or something entirely different. Usually, with web apps, in cases like this, the contents of the original form are lost and the user will have to enter them again latter. I would like to explicitly allow users to take a detour. What I haven''t figured out, yet, is a general solution to saving the temporary state of the original form. My current best idea goes along these lines: (1) The user can''t leave a form in an arbitrary direction, there are only specific exits. These exits all submit the current form, but before the submission reaches the save action of the relevant controller, it is intercepted by a before filter. This filter saves the request parameters in the session and redirects the browser to where the user wants to take the detour. (2) The user creates a new object on another form. After saving the object, it is taken into account that the user is currently on a detour and thus redirection leads back to the original form (new or edit action). (3) The new and edit actions of the controller don''t know anything about detours. They just set some instance variables. (4) When rendering the new view, attributes of these instance variables are updated with the data stored in the session in step (1). This is all still very shaky. A main consideration is that I don''t want to impose anything on how the action methods new/edit/save are written. Ideally, the additional functionality is completely hidden away in filters. I have no idea how to do this in step (4), as I need to intercept before rendering, not after it. In the latter case, after_filter would do the trick. Comments? Suggestions? Michael -- Michael Schuerig You can twist perceptions mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Reality won''t budge http://www.schuerig.de/michael/ --Rush, Show Don''t Tell
In the Agile Web Development with Rails book... A Cart object is created and added to the session, but never saved to the database. The continue shopping action (:list) takes you away from page displaying the cart information. The same could be done with another model class not tied to the database (not an ActiveRecord child). Instantiate an object of this class when the user first hits the form. Maintain the object in the session. When user returns to the view, repopulate form fields from object attributes from the object stored in the session. Should be pretty easy and a much better user experience as long any sensitive information is masked or eliminated. Ken On 9/1/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> > Say a user is halfway through filling-in a form. Then he decides that > s/he has to do another thing first, maybe create another object or > something entirely different. Usually, with web apps, in cases like > this, the contents of the original form are lost and the user will have > to enter them again latter. > > I would like to explicitly allow users to take a detour. What I haven''t > figured out, yet, is a general solution to saving the temporary state > of the original form. My current best idea goes along these lines: > > (1) The user can''t leave a form in an arbitrary direction, there are > only specific exits. These exits all submit the current form, but > before the submission reaches the save action of the relevant > controller, it is intercepted by a before filter. This filter saves the > request parameters in the session and redirects the browser to where > the user wants to take the detour. > > (2) The user creates a new object on another form. After saving the > object, it is taken into account that the user is currently on a detour > and thus redirection leads back to the original form (new or edit > action). > > (3) The new and edit actions of the controller don''t know anything about > detours. They just set some instance variables. > > (4) When rendering the new view, attributes of these instance variables > are updated with the data stored in the session in step (1). > > This is all still very shaky. A main consideration is that I don''t want > to impose anything on how the action methods new/edit/save are written. > Ideally, the additional functionality is completely hidden away in > filters. I have no idea how to do this in step (4), as I need to > intercept before rendering, not after it. In the latter case, > after_filter would do the trick. > > Comments? Suggestions? > > Michael > > -- > Michael Schuerig You can twist perceptions > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Reality won''t budge > http://www.schuerig.de/michael/ --Rush, Show Don''t Tell > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Sep 1, 2005, at 10:55 AM, Michael Schuerig wrote:> > Say a user is halfway through filling-in a form. Then he decides that > s/he has to do another thing first, maybe create another object or > something entirely different. Usually, with web apps, in cases like > this, the contents of the original form are lost and the user will > have > to enter them again latter.> (1) The user can''t leave a form in an arbitrary direction, there are > only specific exits. These exits all submit the current form, but > before the submission reaches the save action of the relevant > controller, it is intercepted by a before filter. This filter saves > the > request parameters in the session and redirects the browser to where > the user wants to take the detour.Uh oh! A bit generalized, but I''d be right much more than wrong if I said only ever store IDs (references) in the session; if even that. If you can''t store the data to the proper tables (maybe with some "incomplete" flag or some such), then store it to a "unfinished_po_forms" or "unfinished_new_employees" or whatever and just store the ID of the new row in that table in the session -- or don''t even do that. Put the user_id in the table and you can always look up "unfinished new order forms" for the user. Advantages: Your sessions won''t grow into a giant unstructured mess. You can write proper models for the "data-in-limbo". The data won''t go bye-bye if the session does. Database tables like that are much easier to scale than sessions (which, if you think about it, is just a different kind of databases). - ask -- http://www.askbjoernhansen.com/
On Friday 02 September 2005 07:43, Ken Barker wrote:> In the Agile Web Development with Rails book... > > A Cart object is created and added to the session, but never saved to > the database. The continue shopping action (:list) takes you away > from page displaying the cart information. > > The same could be done with another model class not tied to the > database (not an ActiveRecord child).But that''s exactly my case: I want to save an AR, or only its set of attributes, for latter. What makes this intricate is that I want to make it as transparent as possible from the perspective of the affected controller. Ideally, I want it to be completely hidden away in before/after filters. Michael -- Michael Schuerig Face reality and stare it down mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org --Jethro Tull, Silver River Turning http://www.schuerig.de/michael/
On Friday 02 September 2005 08:05, Ask Bjørn Hansen wrote:> On Sep 1, 2005, at 10:55 AM, Michael Schuerig wrote: > > Say a user is halfway through filling-in a form. Then he decides > > that s/he has to do another thing first, maybe create another > > object or something entirely different. Usually, with web apps, in > > cases like this, the contents of the original form are lost and the > > user will have > > to enter them again latter. > > > > (1) The user can''t leave a form in an arbitrary direction, there > > are only specific exits. These exits all submit the current form, > > but before the submission reaches the save action of the relevant > > controller, it is intercepted by a before filter. This filter saves > > the > > request parameters in the session and redirects the browser to > > where the user wants to take the detour. > > Uh oh! > > A bit generalized, but I''d be right much more than wrong if I said > only ever store IDs (references) in the session; if even that. > > If you can''t store the data to the proper tables (maybe with some > "incomplete" flag or some such), then store it to a > "unfinished_po_forms" or "unfinished_new_employees" or whatever and > just store the ID of the new row in that table in the session -- or > don''t even do that. Put the user_id in the table and you can always > look up "unfinished new order forms" for the user.This would a duplication of almost all of the "important" tables. Also, I''d have to periodically reap old data from those tables.> Advantages: > > Your sessions won''t grow into a giant unstructured mess.It doesn''t have to with another approach, either.> You can write proper models for the "data-in-limbo".But I don''t *want* to write anything. I want to make this functionality as unobtrusive and transparent for the programmer (me) as possible.> The data won''t go bye-bye if the session does.That''s actually a feature. I want the data to disappear after some time when the user has abandoned it.> Database tables like that are much easier to scale than sessions > (which, if you think about it, is just a different kind of > databases).I think that''s the point. Your approach is driven by the need for scalability. I don''t care much for scalability. I''m more concerned with convenience for users *and* developers. This is for an in-house application with a low number of concurrent users. Michael -- Michael Schuerig Those who call the shots mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Are never in the line of fire http://www.schuerig.de/michael/ --Ani DiFranco, Not So Soft
you can save an AR object in the session. i wouldnt do this with fetched records but with new records, there is no problem. @ask i see no problem in using the session... thats what its there for... your way is very handy if you never want to loose a step, but if someone leaves the site for a week i dont expect there form they half assed and didnt intend on finishing is still sitting there demanding they complete it. as well this will cause a lot more contention on the database. On 9/2/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Friday 02 September 2005 07:43, Ken Barker wrote: > > In the Agile Web Development with Rails book... > > > > A Cart object is created and added to the session, but never saved to > > the database. The continue shopping action (:list) takes you away > > from page displaying the cart information. > > > > The same could be done with another model class not tied to the > > database (not an ActiveRecord child). > > But that''s exactly my case: I want to save an AR, or only its set of > attributes, for latter. What makes this intricate is that I want to > make it as transparent as possible from the perspective of the affected > controller. Ideally, I want it to be completely hidden away in > before/after filters. > > Michael > > -- > Michael Schuerig Face reality and stare it down > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org --Jethro Tull, Silver River Turning > http://www.schuerig.de/michael/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>