advanced question: feasability of using delegates on original objects for AJAX calls

[PJ6]

I'm stuck on this and need someone with more ASP.Net knowledge than I to
weigh in...

I've been toying around with writing my own .Net AJAX framework and been
looking at associating GUID's with delegates as my main approach:

--(from within a web control)
Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
btn.ID = Me.ClientID & "_btn"
Server.AddClientSideEventAction(Me.Page, btn, "OnClick", AddressOf
OnClick)
MyBase.OnLoad(e)
End Sub

AddClientSideEventAction simply adds a new GUID and delegate to a dictionary
and adds this to the control render:

<button id="ctl02_btn"
OnClick="AjaxRequest('9713e7bc-df1c-46fa-8ee0-afd139f5d693');">BUTTON
1</button>

What happens is this server-side object can now have a method fired from
outside its original page context, an AJAX call. From the containing page we
can handle an event invoked from within this method and call another control
enabled to handle changing states both server and client-side... for
instance, a WebControl that encapsulates and serves the properties of a
TextArea:

Public Property Text() As String
Get
Return tb.InnerText
End Get
Set(ByVal value As String)
If Not value Is Nothing Then value =
value.Replace(Environment.NewLine, "\r")
AsyncEvent.SetClientProperty(Me.Page, tb.ID, "innerHTML", value)
tb.InnerText = value
End Set
End Property

AsyncEvent.SetClientProperty sends JavaScript back to the client to update
the control, if we are executing from within an AJAX context.

Unorthodox? Bad practice? This is my reasoning for exploring this approach -

1. ViewState is eliminated
2. Simple use (the code looks and acts the same as regular postback)
3. Simple, efficient communication of events between enabled controls

I have a reasonably articulated proof-of-concept working and I really like
how it works.

But there's one problem - delegate accumulation. Periodically I need to
flush the delegate dictionary to remove items associated with sessions that
have expired. Unfortunately Session.Abandon() will *not* put the server side
objects or session into a state where calling delegates / accessing the
controls will fail, or otherwise notify me that the session has terminated -
possibly because I've got pointers to them. If I can't find a good way to
deal with this, than I'll have to toss this idea out the window.

Paul

 

[Guest]

Paul,
Before you reinvent the wheel, why not take a look at some of the "AJAX"
frameworks that are already out there with free source code and see how
others have tackled your problems?

Specifically, you can look at Anthem.Net and MagicAjax, both of which are
hosted on sourceforge.net. If you are really ambitions, Microsoft makes
available the source code for Microsoft ASP.NET AJAX as well.

Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net

 

[PJ6]

I am re-inventing the wheel, but deliberately, as a learning exercise.

I believe you have pointed me in the right direction - I have to see how
this method finds its way to the relevant page object within the appropriate
session:

Anthem_InvokePageMethod

Thanks
Paul

 

[PJ6]

OK, I get it now. Even as the old-school postback does, all these AJAX
frameworks recreate any associated objects for each call to a server-side
object - even the entire page again, if necessary. This is where view state
comes in, since we have discarded the original objects yet need to recreate
their states server-side.

While this is a good model for a regular website, I do bot believe it is for
real business applications. How absurd to recreate a grid control, and
possibly a whole page and all of its controls, for every AJAX-enabled edit.
I believe this could be improved upon in both performance and design
simplicity by persisting objects server-side and using a login, not the
sessionid, as a key. I believe I'll have to abandon having more than one
page available, but I always wanted to free my web architecture from that
silly mode of one-file-per-page. I think I'll make it one page, and all the
content dynamic. Fun!

Paul

 

[Guest]

The general "preferred" concept is to preserve the stateful Page object
rather than using external handlers. Exactly how you do this is of course up
to you. Some frameworks only marshal back the part(s) of the page that have
changed.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder(BETA): http://www.blogmetafinder.com