SitePoint Sponsor

User Tag List

Results 1 to 22 of 22
  1. #1
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Passing data between forms

    Ok, I've been trying to figure out the best method to pass data between related forms in an app. No, its definitely not a necessity to get this advanced right away, but I'm trying to lay a good system down for expansion. Here goes:

    What if I have a script stack located in the session, that keeps track of each "task" and it's data. So, if I view a list task, the stack would contain an entry for the list: (0=>list). If I selected an item to edit, the list script would add the edit task to the stack: (0=>list, 1=>edit), add selection data to that task, and then redirect to the edit page. At the edit page, if there is no selection data, the script will check the stack, and load the previous script (list). If there is selection data, the item will be displayed in a form for editing. After submitting the form, the data is saved and the user is redirected to the previous script in the stack, the list.

    That seems simple enough to program. However, I have been planning on a front controller, which puts a damper on scripts being in the stack. Do you think it might be possible to organize a stack that keeps track of tasks, but instead of a task mapping to a new script, it maps to a class, or a method of a class?

    Any thoughts are welcome.

    Thanks,

    Cory

  2. #2
    SitePoint Member Toby Somerville's Avatar
    Join Date
    Nov 2007
    Location
    Apollo Bay
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Might an easier solution be to store the data as hidden fields in the form?

  3. #3
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Toby Somerville View Post
    Might an easier solution be to store the data as hidden fields in the form?
    Depends on your definition of easier... easier to implement, maybe, but a mess to maintain... I just finished an inventory program for a client that allowed members of his site to manage their coke bottle collections... the master list and personal inventories each had 4-5 display variables that narrowed down the bottles listed. Every time the user changed a display variable, every other display had to be passed in a form in order to maintain the same view. Every time an admin edited a bottle, and returned to the master list, the view restarted because I didn't pass the display vars as hidden variables in the new form. Sure, I could have, but it would be a pain for every single child task to have to carry its parents' display variables inside its form. I kept thinking the whole time, there has to be a better way, but the project was a quick one.
    Last edited by allspiritseve; Nov 15, 2007 at 12:54. Reason: Threat was moved to general php... its back now though.

  4. #4
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How do other people implement passing data between parent and child forms? Ie, in a basic CRUD setup, how does your list pass the id of the item to be edited/deleted to the child form?

  5. #5
    SitePoint Enthusiast
    Join Date
    May 2007
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    easy way - store data as hidden fields. but that not secure , not recommended.

    good way - put data into session, then retrieve it back later.

    hard way - encrypt data, then retrieve later

  6. #6
    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 allspiritseve View Post
    How do other people implement passing data between parent and child forms? Ie, in a basic CRUD setup, how does your list pass the id of the item to be edited/deleted to the child form?
    As part of the URL. For example, this might be the URL of the parent (list of entities):
    http://www.example.org/articles
    And this is the URL of the child form:
    http://www.example.org/articles/42

  7. #7
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    As part of the URL. For example, this might be the URL of the parent (list of entities):
    http://www.example.org/articles
    And this is the URL of the child form:
    http://www.example.org/articles/42
    Well, here's the way I see it (and my opinion is loosely based off of here) is that since '42' for me would be the primary key of a database table, this could be edited and potentially used to access another row that a user didn't have permission to edit. I think it makes sense to hide all primary keys from the user, so what they see are /articles/list/ and /articles/edit/. Storing this data in sessions also allows me to save any information used to view the list of articles, for example if I were viewing all articles by a certain author. As soon as /articles/edit/ finishes, it can redirect back to the same view, instead of listing all articles in the database.

    I guess I'm suprised this isn't done more often, it seems pretty useful to me (though keep in mind I haven't attempted this yet, just been reading about it)

    Cory

  8. #8
    SitePoint Member
    Join Date
    Oct 2007
    Location
    East Sussex
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As kyberfabrikken says just put the post id in the url, then when you want to update or whatever check that the user has access to that record, using the users id stored in a session.

    eg UPDATE table SET field=data WHERE userId = x AND id = 42

  9. #9
    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 allspiritseve View Post
    Well, here's the way I see it (and my opinion is loosely based off of here) is that since '42' for me would be the primary key of a database table, this could be edited and potentially used to access another row that a user didn't have permission to edit.
    What prevents you from putting a check inside the handler for /articles/42, which checks the users permissions?

    Quote Originally Posted by allspiritseve View Post
    Well, here's the way I see it (and my opinion is loosely based off of here)
    (...)
    Storing this data in sessions also allows me to save any information used to view the list of articles, for example if I were viewing all articles by a certain author.

    I guess I'm suprised this isn't done more often, it seems pretty useful to me (though keep in mind I haven't attempted this yet, just been reading about it)

    Cory
    Mr. Marston got one thing right; Applications have state, and HTTP is stateless. There are two possible solutions to that mismatch. Either you try to maintain state at the server side (sessions) or you try to maintain it at the client side (Through URL's, cookies and other means). Initially, the former is the easiest to implement, but it has some serious implications. These manifests themselves as "the broken back button", or inability to bookmark pages, but they are all symptoms of the same illness. You can jump through all sorts of hoops, to make the server side state work, but you'll end up with such a complicated solution, that you'd been better off by using client side state in the first place.

  10. #10
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Although Google gears seems designed for working on data offline, do you think it would qualify as one of those "other means" in some situations?
    http://code.google.com/apis/gears/

    (Through URL's, cookies and other means).

  11. #11
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    What prevents you from putting a check inside the handler for /articles/42, which checks the users permissions?
    Well, nothing, but I do see sense in keeping primary keys hidden from users. Rather than monitoring all primary key input to an application, the input is shut down and data can only be accessed through the standard route, selecting it through a form.

    Quote Originally Posted by kyberfabrikken View Post
    Mr. Marston got one thing right; Applications have state, and HTTP is stateless. There are two possible solutions to that mismatch. Either you try to maintain state at the server side (sessions) or you try to maintain it at the client side (Through URL's, cookies and other means). Initially, the former is the easiest to implement, but it has some serious implications. These manifests themselves as "the broken back button", or inability to bookmark pages, but they are all symptoms of the same illness. You can jump through all sorts of hoops, to make the server side state work, but you'll end up with such a complicated solution, that you'd been better off by using client side state in the first place.
    Why does it HAVE to be overly complicated? I could see a simple system being set up that simply did what urls do, keeping an associative array of data for the script to access. Sure, its slightly more complicated in that you have to keep track of the data in sessions so its not given to other scripts, but its not so complex that I'd run away screaming. Maybe I'm wrong, but I guess I'll find out somewhere down the road, if I am in fact destined for "such a complicated solution"

    Cory

  12. #12
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't see any reason to hide the primary key. It would even be better for power users to show the primary key as a part of the url, since they could manually edit it if they remember a primary key.

    Even if you hide the primary key from the url, you still need to do a check to see if the user is authorized to edit the post. It's not more safe just because you store it in a hidden input rather than storing it in the url.

  13. #13
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That is true... though there could be ways to do the same thing, such as a "search by pkey" function that's only visible to power users. Another thing I just thought of, is the ability to edit/delete multiple items at the same time, which could be a little awkward passing through the url.

  14. #14
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, requests that change the state of an application should always be post requests, so what's stopping you from sending a bunch of pkeys to delete with form data?

    If you go to /articles/42/edit, you wouldn't expect to be able do delete a bunch of articles anyway, you would expect to be able to edit the post with pkey 42.

  15. #15
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, anything that is a post request I'd probably end up putting in sessions and redirecting anyways, to disable a back button repost.

    If I went to /articles/edit/42/, sure, I'd expect to edit 42... but if I went from /articles/list/ to articles/edit/ and selected 3 items, I could edit one, hit select+next, edit another, select+next, edit the third, and then submit and go back to the list... instead of having to go back and reselect an item each time I want to edit it.

  16. #16
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What do you mean by putting it in a session? I just do PRG (post, redirect, get). That way the only thing I need to put in a session is a message to the user to display after the redirect is done, if that message is necessary.

    I don't really follow you on what you mean by that last thing, but I'm sure it would be possible the pkey as a part of the url?

  17. #17
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When I post data, I post to the initial script, and then put the form data in sessions, and redirect to the script that handles the form. This way if a user hits their back button, the information is not re-posted.

    The second thing I was talking about was editing multiple items without going back to a list screen to select them. It could be possible as part of the url, if you have /articles/edit/1/3/8/, but thats a bit awkward.

  18. #18
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wouldn't it be better to consider this as one multistep form rather than "related forms" or parent-child forms? There are techniques for handling multistep (multipage) forms ...

  19. #19
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I am not familiar with those techniques... do you have any links where I can read up on them?

  20. #20
    SitePoint Member handry's Avatar
    Join Date
    Nov 2005
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It would better if we use session to parse data beetween 2 form.

    I would rather like to use pop up javascript method combine with session variables in parsing ID primary key.

  21. #21
    SitePoint Addict
    Join Date
    Aug 2007
    Posts
    365
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just be careful when dealing with sessions, they are great when there is only one instance of the web application but then users (like myself) like to play with the "open in new tab" button thing can go bad..

    eg
    User clicks edit a row
    - PHP stores the primary key in the session as id
    User opens a new edit of a different row
    - PHP overwrites the primary key with the new primary key

    User saves data from the first edit
    - BANG!! all data from the second records is overwritten by the first...

  22. #22
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    User opens a new edit of a different row

    You can track number of edited rows and if it is > 1 ... BANG!


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
  •