Guidelines for Building Webapps

Discussions

News: Guidelines for Building Webapps

  1. Guidelines for Building Webapps (14 messages)

    Brian McCallister has written a blog entry with five guidelines for building web applications, and explains each one in some detail. They are:

    • Separate view and model state
    • Manage view state like manually managed memory
    • Never change model state with an HTTP GET
    • Treat system tests like an alternate user interface
    • View complexity is usually higher than model complexity
    Most of his suggestions are simple. Are his guidelines valid? Are they sufficient? What would you add to them?

    Threaded Messages (14)

  2. o Separate GUI logic from design
    o Statemachines are not sufficient for the complexity of GUI logic
    o GUI logic will heavily depend on business logic. But the latter must not make any assumtions about the GUI logic
  3. With no irony intended, perhaps my suggestions might be:

    • Separate administration of your application from your primary presentation layer
    • Use J2EE technologies at your fingertips to the fullest
    • Watch for your failure points

    No comment as to the inspiration of those. :)
  4. No comment as to the inspiration of those. :)

    >;-)

    No further comment required I suppose... must have been a humbling experience.
  5. Guidelines for Building Webapps[ Go to top ]

    not sure what happened there, but it would be interesting to find out what the problem was, was it technology, the architecture, application design? Is there any chance of finding out more about it, because it a pretty large scale app...
  6. Guidelines for Building Webapps[ Go to top ]

    not sure what happened there, but it would be interesting to find out what the problem was, was it technology, the architecture, application design? Is there any chance of finding out more about it, because it a pretty large scale app...
    Probably it was an attempt to migrate to PHP ...
  7. Link didn't work[ Go to top ]

    Try

    http://kasparov.skife.org/blog/2005/04/12/#webapp-guidelines
  8. Link didn't work[ Go to top ]

    Thanks. Cut buffer didn't work and the moron editor (me) missed it. It's been fixed.
  9. Guidelines for Building Webapps[ Go to top ]

    Don't let end-users see error messages that reveal an awkward design.

    For example:

    java.rmi.RemoteException: EJB Exception: ;
    nested exception is: kodo.util.DataStoreException:
    ERROR: canceling query due to user request
    {prepstmnt 5191 SELECT t0.threadpk, t0.jdoversion, t0.creationdate, t1.forumpk, t1.jdoversion, t1.rssfeed, t2.categorypk, t2.jdoversion, t2.imagename, t2.summary, t2.title, t1.forumhref, t1.imagename, t1.lastupdated, t1.messagecount, t1.sitepk, t1.summary, t1.threadcount, t1.title, t0.hot, t0.imagename, t0.lastupdated, t0.messagecount, t0.subject, t0.summary, t3.messagepk, t3.jdoversion, t3.body, t3.creationdate, t3.noiselevel, t3.replycount, t4.messagepk, t4.jdoversion, t4.body, t4.creationdate, t4.noiselevel, t4.replycount, t4.parentmessagepk, t4.subject, t4.summary, t4.threadpk, t4.userpk, t3.subject, t3.summary, t5.threadpk, t5.jdoversion, t5.creationdate, t5.forumpk, t5.hot, t5.imagename, t5.lastupdated, t5.messagecount, t5.subject, t5.summary, t5.messagepk, t6.userpk, t6.jdoversion, t6.address1, t6.address2, t6.admin, t6.budgetcode, t6.city, t6.company, t6.country, t6.created, t6.developercode, t6.email, t6.employeecode, t6.fax, t6.firstname, t6.industrycode, t6.interest35, t6.interest21, t6.interest30, t6.interest17, t6.interest2, t6.interest13, t6.interest37, t6.interest34, t6.interest32, t6.interest33, t6.interest22, t6.interest11, t6.interest10, t6.interest9, t6.interest24, t6.interest19, t6.interest12, t6.interest36, t6.interest25, t6.interest16, t6.interest4, t6.interest8, t6.interest26, t6.interest7, t6.interest20, t6.interest31, t6.interest6, t6.interest15, t6.interest5, t6.interest23, t6.interest3, t6.interest28, t6.interest14, t6.interest29, t6.interest18, t6.interest1, t6.interest27, t6.last_login, t6.last_modified, t6.lastname, t6.password, t6.phone, t6.province, t6.scopecode, t6.state, t6.title, t6.titlecode, t6.username, t6.verified, t6.zip FROM public.threads t0 INNER JOIN public.forums t1 ON t0.forumpk = t1.forumpk LEFT OUTER JOIN public.categories t2 ON t1.categorypk = t2.categorypk LEFT OUTER JOIN public.messages t3 ON t0.messagepk = t3.messagepk LEFT OUTER JOIN public.messages t4 ON t3.parentmessagepk = t4.messagepk LEFT OUTER JOIN public.threads t5 ON t3.threadpk = t5.threadpk LEFT OUTER JOIN public.users t6 ON t3.userpk = t6.userpk WHERE (t1.forumpk = ? AND t1.sitepk = ?) ORDER BY t0.creationdate DESC LIMIT ? }
    [code=0, state=57014]
  10. Guidelines for Building Webapps[ Go to top ]

    Im a bit concerned about where to store the state view. Does it actually make sense storing it in the database the blog admits?

    The way I see it is that the database stores only the data related to the business logic and that you would use configuration files to manage the view.

    I havent put a lot of thought into it, "it just sounds right to me". Can someone more experienced share his thoughts please?

    Thanks in advance,
  11. View State[ Go to top ]

    Most often sticking it into the database doesn't make sense. Sometimes it does, then it makes sense. The key thing I was trying to express is that *sometimes* view state is, in fact, very long lived and needs to survive server reboots, etc. Most often view state which is in any way durable goes on the sesssion, which makes sense. Interestingly, not infrequently sessions get backed up to a relational database -- so view state goes into a database.

    It is more a matter of managing the view state however it needs to be viewed. Take /. for example -- your preferences for which stories you want to see, where to put sidebars, etc are durable preferences which ened to survive across multiple sessions. How would you like to save that information?
  12. Re: Key thing...[ Go to top ]

    ... The key thing I was trying to express is that *sometimes* view state is, in fact, very long lived and needs to survive server reboots, etc.

    The key thing in using the database example, that is =)
  13. View State[ Go to top ]

    Hi Brian,
    The key thing I was trying to express is that *sometimes* view state is, in fact, very long lived and needs to survive server reboots, etc. Most often view state which is in any way durable goes on the sesssion, which makes sense. Interestingly, not infrequently sessions get backed up to a relational database -- so view state goes into a database. It is more a matter of managing the view state however it needs to be viewed. Take /. for example -- your preferences for which stories you want to see, where to put sidebars, etc are durable preferences which ened to survive across multiple sessions. How would you like to save that information?

    The pattern I used to use with Weblogic was something like this:

    1) Users have a unique ID assigned by the application. This could be an email address, a sequence counter (assigned at registration), an LDAP identifier, etc.

    2) Sessions have a unique ID assigned by the server. The session ID is "transient".

    3) User data is persistent, and it can be loaded from the database.

    4) When a user is logged in or otherwise identified, the user id is placed into the session. The user data is "cached" in the session, either by dereferencing the ID or by storing the user object (the DTO that corresponds to the user ID) in the session.

    5) Sessions are NEVER stored in the database. If server failover is needed then use the app server's session failover (or Coherence*Web ;-)

    The problem with using the session itself as the cache for the user data is the same problem that sessions have always had -- it's only visible to that user (unless you jump though hoops). The result is that if you cache potentially read/write data in a session, it will not get updated when that data changes. For user data, that only matters when the user logs in more than once, or when an admin changes the user data. (If the user changes his/her own data, the app can update the session accordingly.)

    Where the problem tends to show up is when the user's prefs override the user's department's prefs which override the user's organization's prefs which override the default prefs, and they're all read/write. Then the question is "where do I store which?" That's why I tend to store the IDs (and the data that I don't want to be affected by someone else) in the session, and for data that is shared and that I want to see the changes for, I would only store the key in the session. Of course, back then if you didn't use the session to hold the objects, then you had to go to an entity EJB (which would in turn end up going to the database most of the time). Nowadays, I'd just set up a shared clustered cache for the user objects, one for the department objects, one for the organization objects, etc. That way I am not penalized in terms of scalable performance for the dereference-by-ID approach.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  14. View State[ Go to top ]

    5) Sessions are NEVER stored in the database. If server failover is needed then use the app server's session failover (or Coherence*Web ;-)

    Why so adamant about this one? What if the app server's strategy is to store session state in the database?
  15. View State[ Go to top ]

    5) Sessions are NEVER stored in the database. If server failover is needed then use the app server's session failover (or Coherence*Web ;-)

    Why so adamant about this one? What if the app server's strategy is to store session state in the database?

    Just a simple rule: Sessions are transient data. Transient data should not be stored in the database.

    Since most of the applications I've personally had to work on were database-bound, the first thing we did was get rid of all the waste of database cycles, and sessions are high on that list.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!