SitePoint Sponsor

User Tag List

Results 1 to 21 of 21
  1. #1
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PRG and sessions

    Quote Originally Posted by wysiwyg View Post
    Both, actually. When the form is invalid, the form data must be redisplayed after the redirect. When the form is valid, you want to show your user a message that the form was valid and that something happened. Sure, you could trigger such a message with a query string, but then someone can trigger that message by browsing their history, and if it's a message saying that something was deleted, it's not so good.
    Since this is a slightly different subject than the one that started the object persistence thread, I'm starting a new one. You're right, and I'm starting to get it. I've never seen the problem until now. I appreciate the need to redirect after a successful form submission. In my experience, this has generally not required session handling. But right now I'm refactoring an application to use PRG, and it's sending messages to the user confirming that the form submission was successful. To maintain that behavior, I need to send that message across the redirect. That's exactly the problem you're pointing out.

    I finally read Michael Jouravlev's recommendations more thoroughly, but I'm still questioning the need to redirect after an invalid form submission. The double submit problem doesn't occur in that case.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  2. #2
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, if the form was invalid, and it gets redisplayed without storing the form data in a session, the user might hit the Back button to check for perhaps the name of the person that recruited him/her, and then hit the Forward button to get to the form. Then the user will be promted to post the form again, which is not so user friendly.

    And there is also the advantage that the user can fill out different forms and come back to an old form later, and still have the old form data.

  3. #3
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe that's a different topic, but there is also the problem if the form contains a <file> field. In this case, you need to store the file at the server, or the user will have to re-upload it. It may be the right thing to do from an architectural viewpoint, but it surely isn't very practical.

  4. #4
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wysiwyg View Post
    Well, if the form was invalid, and it gets redisplayed without storing the form data in a session, the user might hit the Back button to check for perhaps the name of the person that recruited him/her, and then hit the Forward button to get to the form. Then the user will be promted to post the form again, which is not so user friendly.
    You're right. But I'm not sure that's enough of a problem to justify the extra complexity of storing the form data in session. If that happens frequently, the form page itself is probably lacking information that should be present.

    Something similar is true of the problem of sending messages on redirect. In my experience, the result of the form submit is usually apparent from the result page, and if it isn't, it might be better to change the contents of the page than to display a message. But obviously, there will be exceptions to this.

    P.S: I'm saying that it's a good idea for the result page to reflect the actual modified state of the Model. Just sending a message with the redirect seems less robust, since you don't know for sure that the operation was successful until you've retrieved the updated data.
    Last edited by dagfinn; Apr 24, 2007 at 05:38.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  5. #5
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see what you mean, and I agree, but sometimes you perform operations that can't easily be shown on the page after the redirect. Like if you send a message to a user in a community. You could send the user to an outbox and display the sent message there, but an outbox wouldn't be where the user would want to go after sending a message. There are also times when you need to inform the user about things that aren't displayed on the resulting page.

    Another example is when you have a list of items that you can edit. You click on one of them, edit some details but not the headline. After the redirect, the user expects the list of items to be displayed since he/she might want to edit other items. And in that list, you can't see if an item has been edited or not, since the user doesn't have to edit the headline.

    But I agree with you that in those cases where the change is so obvious on the resulting page, there is no need for an extra message. But if you have a list of 30 items, and you delete one, it's not easy to tell on the resulting page if the item is actually gone.

  6. #6
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    > Then the user will be promted to post the form again, which is not so user friendly.

    Well, that really isn't our concern, from a developer point of view, is it? We are not responsible for the actions, or the inactions for that matter, of a given user; I don't store form related data in a session, but I can understand why some people would like that convienence.

    But it's more than just that convienence, though as you are basically adding more data to a session which has to be persisted between requests. This whole idea of putting the form data in sessions reeks of a bad code smell to me

    > But I'm not sure that's enough of a problem to justify the extra complexity of storing the
    > form data in session. If that happens frequently, the form page itself is probably lacking
    > information that should be present.



    You've just gone and hit the nail on the head; Some would argue that it's a UI concern that the data should be persisted if the user does something wrong, but in so far, it's also part of the UI to explain to the (dumb) user how to use the form in the first place.

    To explain to them what they can and can't do, and to what to expect when they do something they shouldn't - such as hitting the back button. Regular Internet users know what to expect in a bog standard form when you hit the back button, so why deviate from that huh?

    Isn't the expected behaviour part of some sort of protocol no?

  7. #7
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Then the user will be promted to post the form again, which is not so user friendly.
    >> Well, that really isn't our concern, from a developer point of view, is it?

    Why isn't it our concern? I suppose that depends on how you look at it. You either see it from the user experience side, or how easy the application is to maintain.

    Even if most Internet users knows what to expect from a standard form, not everybody does. At least my mother - and I'm guessing she's not alone - blanks out and panics every time the page goes blank and she's asked to repost the form data. She doesn't know what it means, and she don't want to know either, she just wants it to work.

  8. #8
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Idealy it would be the browsers concern to keep this state, if anyone at all...
    The real solution is: create an application where invalid form submissions does not exist. Who said we need invalid form submissions? Its a pain in the ***, no one gets it right, so why even support it? Sure we can do better. When submitting a 10 field form, with one error, the last thing i want is to be thrown back to the form with a ugly error message complaining about me, the customer, not being good enough.
    Idealy, if my form have one error, then i still have 9 of'em right? Store these and ask me again about the one missing field. Theres no need to keep track of this through sessions, rather ask the model "whats missing" each time.

    Oh, and always try to minimize the need to fill out forms at all, users dont like forms.
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  9. #9
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Reposting invalid form data is simple to do and helps the user experience. When I get a form submission wrong, e.g. I make a typo, it annoys me if the form is returned blank and I have to fill it in again.

  10. #10
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Findus View Post
    Idealy, if my form have one error, then i still have 9 of'em right? Store these and ask me again about the one missing field. Theres no need to keep track of this through sessions, rather ask the model "whats missing" each time.
    In order to ask the user about the missing field, you need to remember the remaining 9. That's server side state. And since the form isn't completed, it's application state, and not resource state.

  11. #11
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Falesh View Post
    Reposting invalid form data is simple to do and helps the user experience. When I get a form submission wrong, e.g. I make a typo, it annoys me if the form is returned blank and I have to fill it in again.
    I don't think anyone is advocating blank forms. The question is how to populate the form with the data that has been entered. If you don't redirect, the data is available in $_POST. If you redirect, you can store it in session, preferably using an object ID as a key. Another alternative might be to store explicitly it in a cookie. Is anyone doing that?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #12
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think anyone is advocating blank forms.
    Ah, my mistake.

    One advantage I have found for using sessions to keep form data has been when using a multi part form. For instance I am building a shopping cart that has three forms, first add items/quantities, second enter personal details, third confirm. Since I store all the form data in sessions the user can move forwards and backwards through the forms without having to re-enter any data or experiance odd refresh issues. This is a very different scenario from a single form though.

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > ...users dont like forms.

    Tough. The -beep- Internet is built on information, God that is it's -beep- purpose, so if someone doesn't like filling in forms, then tough luck... That is the Internet for you mate, and form submissions are part and parcel of the every day Internet grind.

    No one is forced into using the Internet, are they? If you don't like it, then don't use it. Simple really, and yes my attitude is bad but there you go...

    I've got better things to do, rather than pander after the whims of disgruntled site users.

  14. #14
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Falesh View Post
    This is a very different scenario from a single form though.
    I think it's a different story indeed, but not because multipage forms per se needs to be treated radically different than single page forms. You can simply pass the fields from the previous pages as hidden fields.

    With the checkout process of a webshop, as you mention, your users generally expect to be able to leave the form completely, and as long as they don't leave the site (~session), they can come back and complete it. I think that the reason why a checkout form is expected to behave in this way, is because the application is already stateful; The typical webshop has a shopping cart, and that concept can't in any practical way be implement in a stateless fashion. Since the checkout process is coupled to the shopping cart (You're buying the contents of it), it must follow the same rules.

    Interestingly enough, this is an example of server side application state, which works well (And probably won't work well otherwise). I'd guess that the thing that makes this work is, that the action is tied to the users identity; It generally makes sense to have just one shopping session at a time, per user. In contrast, a form for editing an article in a cms is tied to the identity of a domain model object.

  15. #15
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    In order to ask the user about the missing field, you need to remember the remaining 9. That's server side state. And since the form isn't completed, it's application state, and not resource state.
    No you dont need to remember the remaining 9 of them, atleast most of the time. Most things that gets typed into forms will be posted into a database, why do you need to remember the remaining 9 when you can instead look it up in your persistent storage.

    Most forms are there so a set of data can be related to "you" (you typicaly being an user account, a program session etc), when entering personal information for example, does it really matter if you forgot the last name, instead store all that you got, and when the last name is actually needed (when placing an order), add a field in that form asking to supply the last name as its missing.

    Quote Originally Posted by Dr Livingston
    Tough. The -beep- Internet is built on information, God that is it's -beep- purpose, so if someone doesn't like filling in forms, then tough luck... That is the Internet for you mate, and form submissions are part and parcel of the every day Internet grind.

    No one is forced into using the Internet, are they? If you don't like it, then don't use it. Simple really, and yes my attitude is bad but there you go...

    I've got better things to do, rather than pander after the whims of disgruntled site users.
    Im not advocating that we should skip forms, thats impossible, but we should limit its usage to where its needed. Dont ask for information that arent needed, make the user experience as fluent and good as possible.
    Skip those forms that arent either required, or adds pure value for the end user somehow. And you its often possible to solve a problem multiple ways, some forms can be replaced by links for example.
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  16. #16
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Findus View Post
    Most forms are there so a set of data can be related to "you" (you typicaly being an user account, a program session etc), when entering personal information for example, does it really matter if you forgot the last name, instead store all that you got, and when the last name is actually needed (when placing an order), add a field in that form asking to supply the last name as its missing.
    You may be right for a certain type of application. It doesn't fit my experience, though. I would guesstimate that less than 5 per cent of the forms I've created are for that kind of personal information.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  17. #17
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    You may be right for a certain type of application. It doesn't fit my experience, though. I would guesstimate that less than 5 per cent of the forms I've created are for that kind of personal information.
    Well, clearly there are no "one size fits all" solutions.
    Form dealings is an interesting discussions because its a rare one. For clarification, what types of forms would we say exists?
    Can we group forms in a limited set of groups relating them together in terms of functionality?
    • Information registration/collection. (User registration, preferences) Heavily used for social networks specialy, but most sites have a user registration somewhere
    • Search/Query.


    Thats the type of forms I can think of right now (not thought about it for long), anything to add? Imo there is little difference in personal information forms and typing an article in a cms, its both information registration.
    Am I being to generic?

    There are issues in entity creation (adding a product in a webshop maybe) where you would require all data to be present, but really there is no reason why one shouldnt be allowed to submit a partial product, forgot the productname you say, so what, have a default fallback mechanism and store it anyway, and the webshop would not display it since the product is incomplete. But its still a product.

    It requires your application to work a bit different if you have a public view where certain fields for an entity is required, it would need to check for consistency before displaying it, or where possible, fall back on default behavior.
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  18. #18
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Findus View Post
    Imo there is little difference in personal information forms and typing an article in a cms, its both information registration.
    Am I being to generic?
    (...) but really there is no reason why one shouldnt be allowed to submit a partial product (...)
    It might work as a strategy, but it would require some fundamental changes to the application. I don't like the idea of having to allow inconsistent data into the database (Or whatever the model uses as backend).

    As mentioned before, I think it may make sense to distinguish between forms for manipulating domain model entities (Such as an article in a CMS), and forms for manipulation of something related to the user. The difference between the two must be the scope; In most applications, it's reasonable to presume that there is only one user on each client, and that the same user can only act through one client at a time. The session is globally scoped for each client, so as long as the form is unique for that scope, it is somewhat safe to store application state at the server.
    It's not something I've thought long and hard about, but that's how it appears to me.

    Quote Originally Posted by Findus View Post
    Search/Query.
    This is simple enough; A query should propagate its state over the URL. No need for PRG.

  19. #19
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    It might work as a strategy, but it would require some fundamental changes to the application. I don't like the idea of having to allow inconsistent data into the database (Or whatever the model uses as backend).
    Yeah, I'm mentioning it as an overall strategy, thats the idea. I'm not talking about inconsistent data. How often do you really have a required field that can't be filled with a default value until the user decides to fill in real data?

    Quote Originally Posted by kyberfabrikken View Post
    As mentioned before, I think it may make sense to distinguish between forms for manipulating domain model entities (Such as an article in a CMS), and forms for manipulation of something related to the user. The difference between the two must be the scope; In most applications, it's reasonable to presume that there is only one user on each client, and that the same user can only act through one client at a time. The session is globally scoped for each client, so as long as the form is unique for that scope, it is somewhat safe to store application state at the server.
    It's not something I've thought long and hard about, but that's how it appears to me.
    By user i mean user account, not the user session. To be absolute; Theres nothing that a session needs that should be entered through a form, everything entered in a form is meant to hit the model, either by read or write. (Feel free to argue )

    What I'm proposing is a strategy where the idea of invalid data does not exist, and where things like gigantic forms does not exist, where multi-step forms does not exists. Sure there are domains where these things are needed, but most of the time its not. By multi-step (wizards etc) i mean things that have to be run in a certain order and blocking if something is missing in a previous step.

    In a simplistic world you'd fill out your email adress when registering, nothing more, then receive an email with an autogenerated username and password. Once inside you could change what you want, when you want. Updated the username, add a first name, add a surname. Some sites does this, kudos to them - its very easy for me as a user.
    Webshop backend adding a product: Type a name - done. Add more if you want.
    And so on.

    To be honest I've never really given this a lot of thought earlier, and im curious if you think I'm totally off with this strategy? (Since I haven't thought about it before i certainly haven't employed it).
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  20. #20
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,190
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Maybe that's a different topic, but there is also the problem if the form contains a <file> field. In this case, you need to store the file at the server, or the user will have to re-upload it. It may be the right thing to do from an architectural viewpoint, but it surely isn't very practical.
    Ah, what a beautiful security nightmare it would be if we were allowed to manipulate the <file> field.

    Quote Originally Posted by Findus View Post
    Idealy it would be the browsers concern to keep this state, if anyone at all...
    The real solution is: create an application where invalid form submissions does not exist. Who said we need invalid form submissions? Its a pain in the ***, no one gets it right, so why even support it? Sure we can do better. When submitting a 10 field form, with one error, the last thing i want is to be thrown back to the form with a ugly error message complaining about me, the customer, not being good enough.
    Idealy, if my form have one error, then i still have 9 of'em right? Store these and ask me again about the one missing field. Theres no need to keep track of this through sessions, rather ask the model "whats missing" each time.
    In an ideal situation this would be great, though in reality its no major improvement from displaying all the form fields again and populating them. It also depends on what kind of information you are collecting from the form.

    It is quite common for people to leave a form, and if they do not fix the remaining fields. Then you will have a incomplete information input in the database. Which again forces you to create a cron that will clean up the table from time to time.
    While if you did not store the completed forms, you would not need to clean up the table.

    Another issue is that storeing incomplete information can lead to redundant information beeing stored. If you for example let people add their firstname, last name and address in a form. A normal approach before storing this would be to check if the person already had added their information. But if you store incomplete data, you would have no idea if "John Doe, 44 road" were the same person as "John, 44 road".

    Quote Originally Posted by Findus View Post
    Im not advocating that we should skip forms, thats impossible, but we should limit its usage to where its needed. Dont ask for information that arent needed, make the user experience as fluent and good as possible.
    Skip those forms that arent either required, or adds pure value for the end user somehow. And you its often possible to solve a problem multiple ways, some forms can be replaced by links for example.
    I agree with that. Forms should only be used when its needed and not for the sake of having forms.

  21. #21
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Findus View Post
    Yeah, I'm mentioning it as an overall strategy, thats the idea. I'm not talking about inconsistent data. How often do you really have a required field that can't be filled with a default value until the user decides to fill in real data?
    Quite often, I think. It's a bit hard to tell though, because you would have to rethink the entire application, to follow this strategy. My immediate thought is that it's implausible; For certain types of applications, you might be able to follow it through, but not in all cases. In fact, I think that it would be impossible for most scenarios. That's not to say, that one could try to apply the idea in the amount that makes sense.

    Quote Originally Posted by Findus View Post
    By user i mean user account, not the user session. To be absolute; Theres nothing that a session needs that should be entered through a form, everything entered in a form is meant to hit the model, either by read or write. (Feel free to argue )
    Yes, ultimately it is. I was mentioning it in relation to the pattern of storing incomplete forms in session. My argument was, that it's less likely to cause trouble, when the data is directly coupled to the user (The physical person).

    I don't think it's realistic to get rid of using session for storing the state of incomplete forms. Even so, allow partial data (As we might call the pattern, you're suggesting), can be a wrench in our toolbox, that allows us to avoid the impure incomplete forms approach, in some cases. My estimate is, that it's only useful in few cases -- certainly not as a generic strategy. As such, we still need to figure out how to best implement incomplete forms.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •