Add UserControls in DirectEvents/Methods and have them automatically Reload on Post-back through messaging in Hidden Fields

Quote:

---

Originally Posted by michaeld

but I can honestly say, I've done it.

---

My congratulations!

Quote:

---

Originally Posted by michaeld

Yes, but what I mean more is the destroy-and-render pattern. The closest equivalent I've actually seen demoed in the examples is desktop. It seems to use a destroy-and-render pattern but more along the lines of windows which supports delete on close.

---

Do you mean this example?
https://examples2.ext.net/#/Desktop/...tion/Overview/

I don't quite understand where you see a destroy-and-render pattern... Could you, please, clarify?

Quote:

---

Originally Posted by michaeld

I don't mean MVC pattern or the programming language, I mean Facebook stays entirely in the client-side code between pages. It does not refresh it's page between clicks like a standard anchor. The address bar changes, the page changes, but though it looks entirely like you've moved to a different page, they have destroyed and rendered everything below the menubar on the client-side and remain stable. In fact, looking at the request and response headers, you find they are indeed moving the underlying page in the eval without performing a full refresh of the page.

---

Well, yes, they are doing something similar to what you are doing.

Quote:

---

Originally Posted by Daniil

https://examples2.ext.net/#/Desktop/...tion/Overview/

---

Yes!

Quote:

---

Originally Posted by Daniil

I don't quite understand where you see a destroy-and-render pattern... Could you, please, clarify?

---

I guess you're right, I only just started coining destroy-and-render in this last message, so I'll simply clarify that I started calling it this because of the analogous is simply container1.ReRender() in a DirectEvent. It's a destroy-and-render operation that does nothing but cleanup memory, client objects and layouts. Nothing too serious, but every operation is a client-side eval operation instead of a page refresh.

That is, we're just deleting a zone on a page and replacing it with another. It might not even contain the zones that were originally there or the page we started on. And I'm now doing this exclusively, even with the browser back and forth buttons.

The reason I feel a need to emphasize this description is that not only am I destroying-and-rendering new objects that no longer synch with the server's original page but now I'm also cross-posting without a redirect to other pages without the page having any idea of what was there on the client in the first place; only that it knows it needs to destroy-and-replace something. It's loosely-coupled.

So destroy-and-render, as a pattern, means to me that I no longer can rely on pages synching with the aspx information anymore because it may have been destroyed. It's up to me to pass back state information back and forth to the server about what's "actually" there just like you would on a form, except that instead of form data, about the controls that the form data may represent as well. The master page controls, for instance, are the bounders on the client. But they may have been created from an entirely different page. It's up to me to ensure the master page (or pages) have the common framework between so they hold together despite moving sideways without redirects.

So now that I'm going both upwards and sideways replacing sections of the screen contents, that's what I mean by destroy-and-render as a pattern. Maybe it's just a bad name but that's what I mean by it.

I mean conventional wisdom might say, this is a bad pattern cross-posting like this and I'd probably better off just building a HttpModule or HttpHandlers and just use user-controls for the primary contents of the page based on the url. The only reason I can't do this is I already have Modules and handlers dealing with a lot of specific overhead, and the pages already are loading a lot of user controls this way already too (I mean, that's what this entire thread is about). All I did here was prove it's possible now to have the option to offer both. Upwards (nested) and sideways.

Thank you for the detailed explanation. A destroy-and-render pattern... Personally, I like how you call it.

I'm long overdue with a new version of the code with some bug fixes but I'm trying to resolve a few issues first.