Hello, I'm using LLBLGen to develop an ASP.NET project and I have an entity collection which is passed to a web page, which is supposed to edit the entities contained in this collection. The same collection is also used by an underlying 'grid page' and when the edit page is closed the underlying page is refereshed. The collection is mantained by a state manager across roundtrips (could be session, httpcache or whatever).

Assuming that the edit page may make changes to the entity in various points and in various roundtrips, the problem is that if at some point the user decides not to confirm the changes and closes the browser window, the entity will actually keep the changes made and the underlying grid will display them, which is not good. I could refresh the underlying grid by refetching the data, but if you have lots of records to pull out it's another bad thing. The logical solution would be to work on entity clones, and then update the item in the collection by replicating the changes made on the clone.

In windows forms this would not be a problem since entities support IEditableObject allowing me to cancel any changes, but in windows forms I know when the user closes a form, on the web I don't.

Did you ever face this problem? Any suggestions?

Since I have a task performer to generate subclassed entities, I was thinking of adding a clone function to those, but thinking of how deep this could go condidering related entities I don't know if it's a wise solution.

Thanks for any help

The only way to avoid refetches is to edit clones indeed, and when confirmed, make the clones the real entities and toss away the old ones.

Cloning isn't that hard, you can use the binary serializer to serialize to a MemoryStream, then seek the stream to the beginning, then deserialize the MemoryStream into a new object and you're done. This of course clones the complete graph, which can be big, but if you keep the data hierarchy thin, i.e.: only fetch the data REQUIRED for the edit page, it should be ok.

Keep in mind that this problem you're facing is because you try to work around the principle of a webpage: you try to make a stateless architecture become stateful, which requires facilities which aren't there: as you said, you don't know when the user closes the browser.

But what happens when the user opens 2 browser windows and edits in one and refreshes in the other? Are these in sync? Or is that undefined?

Otis wrote:

The only way to avoid refetches is to edit clones indeed, and when confirmed, make the clones the real entities and toss away the old ones.

Cloning isn't that hard, you can use the binary serializer to serialize to a MemoryStream, then seek the stream to the beginning, then deserialize the MemoryStream into a new object and you're done. This of course clones the complete graph, which can be big, but if you keep the data hierarchy thin, i.e.: only fetch the data REQUIRED for the edit page, it should be ok.

Keep in mind that this problem you're facing is because you try to work around the principle of a webpage: you try to make a stateless architecture become stateful, which requires facilities which aren't there: as you said, you don't know when the user closes the browser.

But what happens when the user opens 2 browser windows and edits in one and refreshes in the other? Are these in sync? Or is that undefined?

I was just thinking about the binary serialization too and had started to implement it when I came to check for anwers to my post.. :-) Infact I usually load stuff I need to edit during the edit itself so the entity graph should not be too big.

About turning stateless architecture in a stateful one that is true, but then to give the user the tools required in my project I have no other choice. They want a rich UI and it must be on the web, so I'm trying to 'port' a desktop version of a framework we have to asp.net, with the obvious problems due to like you said an architecture which doesn't have the facilities required.

About the user opening two windows and refreshing one I was actually going to give each page a unique id, and it will retrieve the data from the state manager using this id, so two browser windows would work on separate data. You might say waste of memory but it's unlikely that a user will actually open two windows at the same time, and if he/she does then she'll get two separate objects to edit, and then everything will be handled by conccurrency control: last one to save is asked to force changes because someone else saved before him/her. Or, I can devise something to know if that entity is already being edited and deny the user the second window.

Thanks Frans

BlackMamba wrote:

About turning stateless architecture in a stateful one that is true, but then to give the user the tools required in my project I have no other choice. They want a rich UI and it must be on the web, so I'm trying to 'port' a desktop version of a framework we have to asp.net, with the obvious problems due to like you said an architecture which doesn't have the facilities required.

Yeah, that's always a joy. Having done some of these projects in the past I can assure you, the time-gain managers think to achieve is lost due to the much longer development cycle because the web simply can't offer you a winforms experience.