Temporary web data store problem

Posts   
 
    
uydo
User
Posts: 43
Joined: 09-Dec-2003
# Posted on: 13-Aug-2004 19:16:58   

Hi all,

We have a web application that basically, every task(add/update/delete) is done via one page. Now our client wants to do all the tasks altogether and then, finally, data will be saved until he presses a Submit button. For example, he'd delete a car, then add a new car, then change a driver's billing address, and then press 'Final Submit'. Until then, the actual data are processed and persisted in datastore.

We decided to do this with the wizard machanism, that is, each of the task can be done via one page, but we dont know how and where to store the temporary data on each page among the pages. Please advice if you have any idea on this problem, Thank you and have a good weekend.

Uy.

P.s: We are using Self-servicing model.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39826
Joined: 17-Aug-2003
# Posted on: 14-Aug-2004 13:27:12   

UnitOfWork will come within a few weeks in the new runtime library upgrades which will allow you to call Save(), Delete() and other routines without having them do anything until you commit the unitofwork. Also will entities have multi-versioning for field values, which means that you can save an entity's values under a name and restore these values to that state later on, if the user presses cancel for example.

Until then, you have to do that yourself. That's not that hard though. Simply create a couple of entitycollection instances and use one for entities to save and another for the delete entities. When the user deletes an entity, remove it from the collection you're showing to the user and add it to the collection with entities to delete. When the user adds a new entity, add it to the entities to save. You can also leave that, and simply use the entity collection you're showing to the user for the entities to save. Store these collections in the user's session object.

When the user is done with the forms/wizard, save the collection with entities to save calling SaveMulti() and delete the entities to delete AFTER THAT with calling DeleteMulti() on the collection with the entities to delete.

Frans Bouma | Lead developer LLBLGen Pro
uydo
User
Posts: 43
Joined: 09-Dec-2003
# Posted on: 16-Aug-2004 16:55:40   

Thanks so much for the explanation. I'll head this way for now, and will transfer to the new model whenever you ship it within your product.

One more question about the user session, is it gonna be too big to handle all the collections/entities in session object? Is there any other way to approach this, like saving these objects in a temporary xml file for example? I have no experience with this matter before, so please just give me your input. Thanks again.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39826
Joined: 17-Aug-2003
# Posted on: 16-Aug-2004 18:42:21   

uydo wrote:

One more question about the user session, is it gonna be too big to handle all the collections/entities in session object? Is there any other way to approach this, like saving these objects in a temporary xml file for example? I have no experience with this matter before, so please just give me your input. Thanks again.

Well, storing big collections for a lot of website visitors can be problematic for memory of course. But most of the time you don't have a lot of objects to store (say 10 or 20) and it should be ok.

You can also store them in the viewstate. By doing that, the ojbects are serialized into the HTML (encrypted, that looooooooooooong string in the html simple_smile ) and you don't suffer from a lot of objects in memory, but it's slower as more data has to be send back and forth between the webclient and server and the serialization/deserialization can be slow too.

Frans Bouma | Lead developer LLBLGen Pro
uydo
User
Posts: 43
Joined: 09-Dec-2003
# Posted on: 16-Aug-2004 20:47:54   

It seems like viewstate has some benefits that i need to look more closely. Thanks again for the glue and I'll try both viewstate and session and I'll go from there.