SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 64 of 64
  1. #51
    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
    It's quite nifty to store the form data in sessions and redisplay it after the redirect in the correct form fields.
    Are you referring to a valid or invalid form submission?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  2. #52
    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 dagfinn View Post
    Are you referring to a valid or invalid form submission?
    Yes, I should have been clearer; The problem is how to handle an invalid submitted form. You can do validation at the client side to prevent invalid submission in the first place. But then you have to write the same validation code twice (in PHP+javascript). It won't work for complex rules, which depends on other server side resources.

  3. #53
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    Are you referring to a valid or invalid form submission?
    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.

  4. #54
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Norway - Oslo
    Posts
    198
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My point of view: Persisting resource data is crucial once you hit high volume, if we were to cut our local cache of huge composite objects that are frequently used then basicaly just about every of our database servers would kneel.
    This has, as already said here, little to do with application state. I would store as little as possible in sessions, basicaly it means i store authentication state and probably a user id, from there i look data up when needed, and since this data is persisted its quick to fetch.

    In the situation of PRG you can often make decisions based on post data or referer data, for more complex needs then yes, sessions is a solution.
    But really, the less state you maintain the easier you make it, and the easy route is always what we want, so i would always try to find simple solutions and only be advanced when there really arent any other options.

    Regarding CPU cycles; Have anyone here had a php app that actually is close to using a lot of CPU? IO is the only problem i've ever seen with a php app. I bet we could run most our stuff on 10 year old CPU-s but in terms of memory it needs lots (try to avoid disk IO as much as possible).
    Raymond Julin
    Developer: Hardware.no, Amobil.no, Gamer.no, Prisguide.no ...
    Owner: Kulturo.no

  5. #55
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wysiwyg View Post
    It's quite nifty to store the form data in sessions and redisplay it after the redirect in the correct form fields.
    IMO this is a bad idea. Most browsers out there now feature tabbed browsing. Certainly power users have already adopted such browsers (FF, IE7, Opera).

    You run the risk that power users work in multiple tabs (or just multiple windows or even frames/iframes) concurrently. They all share the same session and you will have a race condition on your hands. Your users will start receiving *strange* confirmations or errors because the tabs will steal "messages" from eachother. You run the risk that the power users deem your application/site unreliable.

    The problem is amplified by the fact that you'll have to protect the session with an exclusive lock so that only one request access the session data at any one time. This means that the next request (if any has been received) is likely already queued up. When you send the redirect to the browser it will respond by a new request which will land at the end of the queue, behind requests for other tabs, windows, iframes etc, increasing the likelihood that one of these requests will interfere with the logic.

    The session should not be used for page to page communication. It is for session state.

  6. #56
    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 honeymonster View Post
    The session should not be used for page to page communication. It is for session state.
    I can see I was too quick in starting a new thread; I see now how the two are interrelated. In Michael Jouravlev's recommended method, session state is used for page to page communication. A "GUI object" can have a message attached to it. I've just implemented messages in session, and discovered that I had to make the message self-destruct after it was used once. So yes, it's unnatural, but it could still be the best choice.

    As for interference between windows or tabs, Jouravlev solves that problem, too, or most of it, by storing objects in session by object ID. That should prevent interference unless you're editing the same object twice, which is a problem in any case. On the other hand, this seems to imply that you need to assign an ID to an object that hasn't been saved to the database yet. That could be tricky.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  7. #57
    SitePoint Enthusiast
    Join Date
    Oct 2005
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog View Post
    Yes, http is stateless, but most applications are not. In php, we must concentrate too much on protocol details, while net or java developer can build an application as if environment was stateful, with their framework taking care of protocol details.
    http://www.sitepoint.com/blogs/2007/...hp-and-python/

    Tac

  8. #58
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    I've just implemented messages in session, and discovered that I had to make the message self-destruct after it was used once. So yes, it's unnatural, but it could still be the best choice.

    As for interference between windows or tabs, Jouravlev solves that problem, too, or most of it, by storing objects in session by object ID. That should prevent interference unless you're editing the same object twice, which is a problem in any case. On the other hand, this seems to imply that you need to assign an ID to an object that hasn't been saved to the database yet. That could be tricky.
    One issue with non redirecting is that when the form is invalid the user could not only hit the Back button but also the Reload button and resubmit the same invalid values. Since the values are invalid, there's been no manipulation of the underlying data store. I have a vague memory of someone here objecting to the POST data dialog popping up and uising redirects to avoid that, but I think it makes more sense to redirect after receiving valid data and storing it.

    As for Findus' message problem, this is very much like placing a security token in a hidden field and comparing its submission to a value stored in a session. (Chris Shilflett has explained this a number of times but I can't find a URL right now.) Same issue: you have to destroy that session variable. If the user reloads the form with invalid values, the security token may be regenerated and would then be deemed invalid. So if you want to include that sort of security mechanism, you're going to have to do this. I think it would also solve the problem of multiple tabs. Once the form values have been found valid, the security token is no longer in the session and the form in the other tab, if resubmitted, won't validate. (I think... haven't tested it.)
    Last edited by auricle; Apr 25, 2007 at 15:55. Reason: typographical error
    Zealotry is contingent upon 100 posts and addiction 200?

  9. #59
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Summing up what I've seen so far, here is "PRG lite":

    • Always redirect on valid form submission
    • Don't redirect on invalid form submission.
    • After a valid form submission, instead of displaying a confirmation message, make sure the result of the form submission is apparent from the contents of the result page.

    This is what I've been doing for the past few years. The benefit of this procedure is it doesn't require session data. The downside is the fact that the user may be confused by using the reload or back buttons after invalid form submissions. That may be a real problem sometimes (depending on the skill level of the users), but nowhere near as big a problem as getting a the ugly re-submit message when hitting reload on the result page.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  10. #60
    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 dagfinn View Post
    As for interference between windows or tabs, Jouravlev solves that problem, too, or most of it, by storing objects in session by object ID. That should prevent interference unless you're editing the same object twice, which is a problem in any case. On the other hand, this seems to imply that you need to assign an ID to an object that hasn't been saved to the database yet. That could be tricky.
    This is basically the solution, I'm using as well. It is a problem for forms without an identity (Eg. create new entry), but in my experience, a race condition isn't as likely to happen for these forms. When a user enters a form for creating an entry, they are likely to complete that task, before beginning a new, similar one.

  11. #61
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I store a unique token in the session, but it's the only thing I store, however...

    > you have to destroy that session variable. If the user reloads the form with invalid
    > values, the security token may be regenerated and would then be deemed invalid.

    You do not need to destroy that given variable, generated for that given request, because you can reuse it... What I do is to preserve the unique token from past request, as well as the current request in an array;

    You only ever need to keep two versions of the token at any one time, so in your form validation script, if the unique token passed in the form doesn't match one, it'll definitely match it's opposite

    Here is some script, which is executed once the Request is instantiated,

    PHP Code:
    final class QRequest_Filter_Unique implements QFilter_Interface {
            private 
    $queue_name;
            
            public function 
    __construct$queue_name ) {
                
    $this -> queue_name $queue_name;
            }
            
            public function 
    process() {
                
    $args func_get_args();
                
    $dataspace array_shift$args );
                
                
    $queue = array();
                
    $unique QCommon::unique();
                if( 
    $queue $dataspace -> get'__session' ) -> get$this -> queue_name ) ) {
                    if( 
    is_array$queue ) && count$queue ) >= ) {
                        
    array_shift$queue );
                    } 
                }
                
    $queue[] = $unique;
                
    $dataspace -> set$this -> queue_name$unique );
                
    $dataspace -> get'__session' ) -> set$this -> queue_name$queue );
            }
        } 
    Problem solved.

  12. #62
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston View Post
    PHP Code:
    final class QRequest_Filter_Unique implements QFilter_Interface {
            private 
    $queue_name;
            
            public function 
    __construct$queue_name ) {
                
    $this -> queue_name $queue_name;
            }
            
            public function 
    process() {
                
    $args func_get_args();
                
    $dataspace array_shift$args );
                
                
    $queue = array();
                
    $unique QCommon::unique();
                if( 
    $queue $dataspace -> get'__session' ) -> get$this -> queue_name ) ) {
                    if( 
    is_array$queue ) && count$queue ) >= ) {
                        
    array_shift$queue );
                    } 
                }
                
    $queue[] = $unique;
                
    $dataspace -> set$this -> queue_name$unique );
                
    $dataspace -> get'__session' ) -> set$this -> queue_name$queue );
            }
        } 
    Actually I can not see how helpful can this class be. It is much easier to store the data right in the session and work with it directly, than create a wrapper class with getters and setters.

  13. #63
    SitePoint Wizard Mincer's Avatar
    Join Date
    Mar 2001
    Location
    London | UK
    Posts
    1,140
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mihd View Post
    Of course, there are lies, damn lies, and statistics...

    Java - 30+ entries
    PHP - 6 entries (of which only 'php' would commonly be php)
    .NET - 2 entries (I wonder how often people search google with a '.net' they didn't really mean??)
    Ruby - 30+ entries


  14. #64
    SitePoint Member
    Join Date
    Nov 2004
    Location
    Warszawa
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey.. it appears that there is a solution for real object persistence in PHP .. check this PHP application server


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
  •