Re: [CFCDev] Instances and persisted data

[Nando]

Hi Richard, >From what i see here, your question has a  interaction design element in it. Should the Save be implicit, or explicit. I've used implicit saves before in a multistep process. There's a Save button, but every time the user clicks the next step tab, the previous screen's changes are committed to the database. Behind the scenes, the state of the cfc containing the form data was persisted to the DB using a .persist() call to the DAO handing the mulitistep form's data every time a next step tab is clicked. In that application, it made sense to do it from an interaction design perspective. As far as a user goes, in most apps i've worked on a user has only one specific point to modify their data, and it's usually not a multistep form. In that case, i would handle it more or less like this: On login attempt (if there is one), instantiate a session scoped User, populate it with the data you have from the login form, authenticate the User, set your isLoggedIn variable to true in session.User and populate User with any other data needed. If the user navigates to the editUser form, populate the form with the data from session.User. When the user clicks Save, repopulate session.User with the new data, validate certain bits of data it if necessary, instantiate UserDAO and pass session.User into UserDAO.persist(). Simple - session.User is updated immediately and the data is persisted to the DB. If your user interface is more intricate than that, where a user can change there data at multiple points in the application, maybe from a pod that for some reason you don't want to have a save button there, Ok, don't know why you'd do that, but let's assume, then you could possible use Ajax with an onBlur event on that field triggers an update. Rob Gonda's your man in that case with his AjaxCFC. Google search and you'll find plenty of information. You could also use a Memento, in which you retain a snapshot of the User instance data at a specific point in the application flow, (i'd do a setMemento() within User itself) and compare the memento to the actual instance data at some defined point in your application flow. Lets say you have a multistep process that primarily is concerned with other data, but along the way, a user could change their user information. Let's also say that you don't want to commit that change unless the user completes the whole multistep process. Something like that. So in a case like this, if it made sense, you could use a setMemento() method that would save a struct of the User's data in User. At the end of the process, you compare the memento with the User data, and if it's different, you set User with the data from the memento and then persist User. My example isn't very good, but that technique is available if you want to delay persisting something. I've used it. hope something here helps, Nando Richard wrote: Hi Everyone. I'm new to this list, and new to CFCs, so bear with me if this is obvious. I'm struggling to decide how to handle the relationship between session instance data, and persisted data stored on the back end. I have a couple of related questions 1) If I have for example a session.user instance which has instance data that the user can modify (change email etc etc) should I commit this to the database at the same time in one transaction, or should I track whether the inszance data "is dirty" and manage the commit on the basis of an explicit save by the user, and maybe use the onSessionend event 2) If a user establishes two different browser session, we have effectively two different instances. This just complicates the above. Can I trap it (application variable?), or how should I handle this? I can always just reload instance data on each request, but that seems to defeat the purpose a bit I'm not sure whether these questions are just application related or whether they are CFC/component issues. Any pointers much appreciated Cheers Richard ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com