Saving Dynamic (Web 2.0) homepages for user returns



  • My boss is wanting me to redesign the intranet and she wants to make it like the bbc homepage with all the customizable stuff it in. I'm going to use jquery to do the UI stuff, but I don't know in what direction I should go to save the homepage for when the user returns. Any ideas? 



  • @malfist said:

    Any ideas?

    Cookies, you don't even need to store user data if they only access it from one computer.



  •  It's an intranet, a bunch of users are going to be accessing it from a relativly small number of computers. I.E. 17 users, 5 computers. Cookies won't work for this, I'll have to use a database. 

    And that still doesn't answer my question, what am I supposed to put in those cookies (or database) that will allow to to reconstruct their homepage?



  •  I think I can figure it out.

    Store status as to not there, minimized, maximized. And then store the (x,y) for it. 



  • @malfist said:

    And that still doesn't answer my question, what am I supposed to put in those cookies (or database) that will allow to to reconstruct their homepage?

    Plz sent me the codes thx bye



    "The stuff that you need to reconstruct their homepage." is the only valid awnser that we can give with this amount of information.



  • If you're just asking where you can store the session information for a user, the answer is "anywhere". You could put it in a cookie, a database, a file, a server session object, anywhere. It's not too clear what you're after here.



  • @malfist said:

    And that still doesn't answer my question, what am I supposed to put in those cookies (or database) that will allow to to reconstruct their homepage?

    Simply an ID (either incremental or a GUID) would be stored in the cookie. In the DB I would store the minimal required information to rebuild the portal. For example if I allowed one of the side menus to be customized with an external RSS feed I would simply store rss://www.example.org/rss.xml in a varchar, then on each page load I grab a cached version of that rss feed, the cache would be refreshed through a cron job.



  • Okay, I have an idea about how I will do it now. Thanks. 



  • @malfist said:

    And that still doesn't answer my question, what am I supposed to put in those cookies (or database) that will allow to to reconstruct their homepage?
     

    You store whatever variables that determine what goes on their homepage. i.e.:

    show_weather_forecast = true;
    show_lotto_numbers = true;
    show_dailywtf_rss_feed = true;

    And so on. We can't tell you what you have to store, because you've provided absolutely nothing in the way of details. But we can tell you how to store them. If it's simple and small, then just store it in a cookie. If you've got a metric buttload of configurable options, then store a unique token in the cookie and use it as a handle to retrieve the data server-side (flat file, database, SSDS search.txt, whatever) and store the options in the user's session.


  • ♿ (Parody)

    @MarcB said:

    ...retrieve the data server-side (flat file, database, SSDS search.txt, whatever)
    If you're going to go this route, might as well just o ahead and randomize the home page in three second cycles.  No more need to store anything!



  • @Lingerance said:

    Simply an ID (either incremental or a GUID) would be stored in the cookie.

    Incremental IDs are easy to predict and most GUID/UUID implementations are not cryptographically strong.



  • @MarcB said:

    And so on. We can't tell you what you have to store, because you've provided absolutely nothing in the way of details. But we can tell you how to store them. If it's simple and small, then just store it in a cookie. If you've got a metric buttload of configurable options, then store a unique token in the cookie and use it as a handle to retrieve the data server-side (flat file, database, SSDS search.txt, whatever) and store the options in the user's session.

    Don't store it in cookies or session, store it linked to the user ID so the settings actually work across multiple sessions and on different computers. 



  • @morbiuswilters said:

    Don't store it in cookies or session, store it linked to the user ID so the settings actually work across multiple sessions and on different computers. 
     

    Why not? You'll presumably have to log into this beast, at which point the cookie will be created one way or another.

    Of course, I've never stored anything in a cookie except a session token. Just throwing out some examples for a very poorly worded question. 



  • @MarcB said:

    @morbiuswilters said:

    Don't store it in cookies or session, store it linked to the user ID so the settings actually work across multiple sessions and on different computers. 
     

    Why not? You'll presumably have to log into this beast, at which point the cookie will be created one way or another.

    Of course, I've never stored anything in a cookie except a session token. Just throwing out some examples for a very poorly worded question. 

    The data shouldn't be stored across sessions in a cookie.  For one, it limits the user to one computer.  Instead, it should be stored on the server's end.

    And it really doesn't make sense to store it as a cookie during a session, because you'll have to retransmit it over and over.  It's much more sensible to load it out of a database when the user logs in, and store it in the session data.



  • @MarcB said:

    Why not? You'll presumably have to log into this beast, at which point the cookie will be created one way or another.

    Of course, I've never stored anything in a cookie except a session token. Just throwing out some examples for a very poorly worded question.

    Uh, then you are saving them linked on user ID like I suggested, you are just adding extra complexity by duplicating the values in cookies and the session. 



  • @bstorer said:

    The data shouldn't be stored across sessions in a cookie.  For one, it limits the user to one computer.  Instead, it should be stored on the server's end.

    And it really doesn't make sense to store it as a cookie during a session, because you'll have to retransmit it over and over.  It's much more sensible to load it out of a database when the user logs in, and store it in the session data.

    That's a somewhat better idea, but I try to avoid duplicating the data altogether.  You avoid having two places where it could be pulled from and you don't have synchronization issues between the session and the database.  At least you don't have the extra step of validating the data from the cookies which is what you would have to do if you "cached" the settings there instead of session.  I prefer to only store user IDs in my session tables and just link everything to the user. 



  • @morbiuswilters said:

    That's a somewhat better idea, but I try to avoid duplicating the data altogether.  You avoid having two places where it could be pulled from and you don't have synchronization issues between the session and the database.  At least you don't have the extra step of validating the data from the cookies which is what you would have to do if you "cached" the settings there instead of session.  I prefer to only store user IDs in my session tables and just link everything to the user.
     

    It kinda depends on where you're storing you session data, though, too.



  • @bstorer said:

    It kinda depends on where you're storing you session data, though, too.

    Yeah, for a small-to-medium sized app you probably are using local files.  I prefer storing in the database if you are running load balanced servers because users don't lose their sessions if a web server crashes.  Also, it allows the user to connect to any web server which means the load balancer doesn't have to bother itself with maintaing a table of source IPs and the servers they are connected to and it also results in a more even distribution of load. 



  • @morbiuswilters said:

    @MarcB said:

    And so on. We can't tell you what you have to store, because you've provided absolutely nothing in the way of details. But we can tell you how to store them. If it's simple and small, then just store it in a cookie. If you've got a metric buttload of configurable options, then store a unique token in the cookie and use it as a handle to retrieve the data server-side (flat file, database, SSDS search.txt, whatever) and store the options in the user's session.

    Don't store it in cookies or session, store it linked to the user ID so the settings actually work across multiple sessions and on different computers. 

     

    Look, how many times do I have to say, I think I've got it, thanks. How about my explanation as to why I can't use cookies? Cookie's are not an option. Only cookie made by this will be the session cookie.

     Someone can close this now.

    Malfist 



  • @malfist said:

     

    Look, how many times do I have to say, I think I've got it, thanks. How about my explanation as to why I can't use cookies? Cookie's are not an option. Only cookie made by this will be the session cookie.

     Someone can close this now.

     

    Just so we're clear on this, while I'm glad you got your answer, at this point, we've all but forgotten about you.  We're debating the relative merits with one another now.  Threads around here have no loyalty to the OP or the OP's topic.



  • @bstorer said:

    Just so we're clear on this, while I'm glad you got your answer, at this point, we've all but forgotten about you.  We're debating the relative merits with one another now.  Threads around here have no loyalty to the OP or the OP's topic.

    QFT.  Also, OP is kind of a dick. 



  • @morbiuswilters said:

    QFT.  Also, OP is kind of a dick. 
     

    With ED.



  •  Some people should learn how to [url=http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx]just use gloves[/url].Or figure out how to read and actually talk about something they understand instead of making up things they don't.


Log in to reply