Re: Glimpse Web Forms

[Nik Molnar]

<<Trying an experiment to move this to the dev list. If it doesn't work out, I'll re-post. Everyone has been BCC'ed so your replies should just go to the public mailing list>>

These are all great idea's Graham. I really appreciate you taking the time to brainstorm this. I really like the idea of getting something going for data binding because I still remember the pain involved there.

I echo Chris's statement, in a slightly generalized tone: Now we need to figure out if/how we can implement these things. As you know, WebForms isn't the most extensible framework in the world.

Thinking particularly of data binding (though the question is open for all items), do you have any ideas about how we might pull this off?

Thanks,
Nik

On Mon, Nov 4, 2013 at 10:38 AM, Christophe Gijbels <christoph...@gmail.com> wrote:

Hey Graham

Thanks for the feedback to start with!

The issues you mention with the Requests are known ones, for instance for the PageMethod we have the following issue that has been opened recently (https://github.com/Glimpse/Glimpse/issues/596). 

Unfortunately all of them are the result of prematurely aborting/short-circuiting the asp.net request pipeline processing. They all call  httpApplication.CompleteRequest() at some point.

The Response.Redirect(url) does an endResponse by default, the ScriptModule does the same once the webmethod did its thing and the Server.Transfer, well it does the same...

I'm not sure how we can intercept this, but there are no pipeline events indicating that the pipeline is being aborted prematurely... but we're still looking into this, hoping that there is a solution somewhere ;-)

Cheers

Christophe

On Sun, Nov 3, 2013 at 6:58 PM, Graham Mendick <graham....@gmail.com> wrote:

Hi,

I've jotted down some high level ideas about where Glimpse Web Forms could go next. I haven't gone into any implementation details because I thought it best to see what you think first.

Requests

Glimpse should support all different types of Web Forms request. Currently it doesn't support the following:

1. Response.Redirect - only the second request is captured, the first doesn't show up in the History tab.
   
2. Server.Transfer - 'crashes' Glimpse, all the tabs disappear.
   
3. PageMethod - the request isn't captured.
   

Control Tree

I've come up with a dev tools-inspired redesign of the Control Tree Tab. The Controls are displayed in a expandable tree where hovering over a Control in the tree highlights the corresponding rendered element in the web page. 

The details panel to the right of the Control Tree is where context information is displayed for the selected Control. The ViewState and ControlState would feature here, as would Control Event timings. This way we could remove the Page Life Cycle tab and display these event timings in the details panel when the Page is selected in the Control Tree.

Because Web Forms is Control-centric any new Glimpse Web Forms development can be displayed within this details panel rather than creating a new tab.

DataBinding

Glimpse should add support for Web Forms DataBinding, displaying consistent information regardless of whether .NET 4.5 Model binding or DataSources are used. There's no need for a separate DataBinding tab because the information can be displayed in the Control Tree's details panel when a DataBound Control, e.g., ListView, is selected.

Looking forward to your feedback.

Cheers,

Graham

[Christophe Gijbels]

Alright, I did some investigation and we should be able to handle those Request issues, but then we need to make sure the EndRequest on the Glimpse Runtime is not only called when the PostReleaseRequestState event is raised, but also (or partly) when the "real" EndRequest event is raised, the one on the initial System.Web.HttpApplication, which is currently not available on the wrapping Glimpse.AspNet.HttpApplicationBase class.

On the other hand, that real EndRequest event is raised late in the pipeline, which might impact plugins aggregating data (like it is the case for session aware plugins), so this must be investigated thoroughly.

The positive thing is that failing requests might be stored as well...

[Steve Ognibene]

Hi,
I'm still getting my feet wet with this project, but I do agree that it would be great if Glimpse could help troubleshoot data binding.  Data binding is very much a black box and a simpler way to shed light on what is actually happening would have saved me several hours on a few occasions.  I'd love to help with that effort if I can.
-Steve O

 

[Steve Ognibene]

Hey Graham,

I'd love to get started on some of this work.  What are your ideas for how the data binding user experience would go?  What information would the user see and what actions (if any) could they take or what guidance could Glimpse give?

The control tree design sounds like a fairly big effort.  Have you done any coding or just the design work?  I like your layout idea - it's certainly familiar for devs who know the F12 tools.

Cheers,

-Steve O

[graham....@gmail.com]

Hi Steve,

Thanks for getting in touch. I think the sort of data binding questions Glimpse could answer are:

1. What Controls were data bound?
   
2. When in the Page life cycle did the data binding occur?
   
3. What values were passed to the data binding methods?
   
4. Where were these values sourced from, e.g., Query string, Control properties?
   
5. What database queries were executed as part of the data binding method calls?
   

As part of the Glimpse Web Forms release, Anthony came up with a clever way to hook into ASP.NET Controls. It involves registering a runtime ControlAdapter, you can see an example Adapter for the Page class and where it's registered in the ControlTree tab.

A similar technique could be used to create ControlAdapters for each different type of DataBound Control, e.g., ListView, FormView. This should help answer questions 1 and 2.

For questions 3 and 4 different techniques will be needed before and after .NET 4.5. Prior to .NET 4.5 data binding was done using DataSource Controls, e.g., ObjectDataSource, SqlDataSource. So, registering ControlAdapters for these Controls is probably the way to go. After .NET 4.5 DataSource Controls became obsolete and data binding switched to a ModelBinding architecture more familiar to MVC. This means a more familiar Glimpse Inspector could be used to proxy the default ModelBinder.

In the Glimpse Web Forms HUD, database queries are slotted underneath their corresponding Page life cycle event. I'm not sure how this was done but perhaps a similar technique could be used to slot the database queries underneath their corresponding data binding event.

I haven't done any coding towards the Control Tree design. The general idea is why create new tabs when there's a logical place to show the information in an existing tab? It makes sense to display the data binding details against the data bound Control in the Tree. Also, it would be nice to be able to communicate between tabs, e.g., clicking on a data bound database query could navigate to the query details in the entity framework tab?

Cheers,

Graham

[Anthony van der Hoorn]

RE the proposed design changes. Its definitely possible that we could create a layout that supports this style of master detail layout. Also its not the first time its been suggested that we could benefit from a tree view. Both of these changes are probably a bit bigger than what we can get done within the next few weeks. 

Given this, I would progress assuming that this isn't here for the moment and we can start up a discussion on how to best to move that work forward.

Cheers

Anthony

--
You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Steve Ognibene]

Hi Graham,

I think you've done some really excellent analysis here and this sounds like an excellent and comprehensive feature.  Wow - this would have saved me hours over the years.

Perhaps we can start very small to stay nimble.  Do you think that you could code up a ControlAdapter for just a data bound ListView (or similar) to prove the concept?  If so, how long do you think that would take you?  Even if it just spit out useful debug messages rather than going through the trouble of hooking it in to the UI, that would be great.  Then let's discuss it and decide the best way to move forward with 1 and 2.

If you need any help with how to contribute code to the project, let me know.  I just started contributing myself so the initial setup stuff is fresh on my mind.

-Steve O

[Steve Ognibene]

Folks - At Anthony's suggestion, I've looked into doing some minor refactoring on the ViewState formatter which has hopefully improved rendering for RadioButtonLists.

https://github.com/nycdotnet/Glimpse/commit/8c5ff6e96fbdaf8a8c660ebb9d04a4b563cc0d28

This code could be extended to several other related controls, and there are several controls that I have noticed that have somewhat awkward rendering with the current ViewState formatter.

Secondly - would everyone agree that it makes sense for all "List" controls to show the list item viewstate first (before the base control viewstate)?

Cheers, -Steve O

[graham....@gmail.com]

Hi Steve,

It's great you like the sound of the data binding features.

Totally agree with starting small, so I've gone down the route you suggested by knocking together a very simple Web Form, with one ListView hooked up to an ObjectDataSource. I've attached an Adapter to the ListView and written out the Parameter types and values to the page.

What's the best way to wing this over to you?

Also, any advice on contributing code would be much appreciated.

Cheers,

Graham

[Steve Ognibene]

If I wrote up a step by step guide to creating your own fork of Glimpse and installing the GitHub prereqs, would you help me test and edit it?

[graham....@gmail.com]

Sure, I'd like that.

[Anthony van der Hoorn]

Great work guys, keep it up. So excited to see this work moving forward!

--

[Steve Ognibene]

Graham,

Please take a look at this guide and let me know if any parts are confusing, lacking in detail, or incorrect.  I'd love to hear any one else's feedback as well!

https://github.com/nycdotnet/FromZeroToPullRequestWindows/blob/master/FromZeroToPullRequestWindows.md

That is written generically, but it should have all of the information you need to be able to start using Git and GitHub effectively on Windows.

As for collaborating on this data binding idea, you wouldn't even have to follow anything after "Creating a Pull Request".  If you just commit and sync your code to a branch on your own Glimpse fork, I will be able to clone that and take a look.

-Steve O

[graham....@gmail.com]

Steve,

The guide's brilliant. I love the thinking behind it, explained in the introduction, and you really stuck to that ethos throughout. I found the branches section really helpful, now it's clear to me why a single fork is all that's needed. Clarifying when I need to switch to the command line was just what I was looking for because I've never seen it detailed before.

In the Pull Request section I couldn't see a "compare & pull request" button on Github, was this before the Github redesign?

I've created a Github project for the data binding proof of concept, https://github.com/grahammendick/GlimpseDataBinding and I've made you a collaborator on it.

Graham 

[Stephen Ognibene]

Hi,

This is great feedback.  Thank you.  Tell you what - I'm going to try to fork and push something to the other repo you have and correct whatever is wrong with the instructions.  I'm sure it's something I forgot to say.

Thanks for setting me up as a collaborator.  I will take a look this week.

Cheers,

-Steve O

--
You received this message because you are subscribed to a topic in the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/getglimpse-dev/dXtAuQg3UaA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to getglimpse-de...@googlegroups.com.

[Steve Ognibene]

I took a look at this.  Very good work, Graham.  I think it came out really nicely.  I wonder how this would work/render with multiple controls on the page?

I thought it would be interesting to know if the data bound event fired at all.  If my recollection is correct (it's been so long) as long as the posted data is the same and not blank, it doesn't fire, but if the input changes then the event does fire and that is interesting for me to see.  I created a branch with a few changes and posted it to your repo.  Let me know if that looks OK to you.  Sorry I didn't have a ton of time to look at this yet.  I've been polishing up my Git guide since Saturday night.  It should be much improved from when you looked at it the other day and I realized late that pull requests are actually immediately updated when you sync if you're still working on the same branch that was tagged in the pull request (if that was what your question was).

Perhaps you can try to add two more ListView controls (one more data bound, and one not) to ensure that that situation is handled smoothly?  If we can do that, then question 1 is definitely proven solvable, and we can start working on question 2... which is probably some sort of interaction with the Page Adapter then.

Nice work!  I should have another chance to look at this again later in the week.

-Steve O

On Monday, November 18, 2013 3:39:06 PM UTC-5, Steve Ognibene wrote:

Hi,

This is great feedback.  Thank you.  Tell you what - I'm going to try to fork and push something to the other repo you have and correct whatever is wrong with the instructions.  I'm sure it's something I forgot to say.

Thanks for setting me up as a collaborator.  I will take a look this week.

Cheers,

-Steve O

[graham....@gmail.com]

You're right about data binding only firing when the parameters change, in the demo you'll see the table disappear if you press search without changing the text. However, there's a problem with showing a data bound indicator. A control can be databound without using a DataSourceControl, by binding to the DataSource directly. I don't think we should try and catch this scenario because it would get messy and we could never get any parameter information anyway.

I think there's a bit more work to do for question 1 because we mustn't forget about the new 4.5 data binding mechanism. It's more in keeping with MVC model binding and doesn't use DataSourceControls at all. Do you fancy enhancing the demo to get the parameter information for controls bound in this way?

Graham

[Stephen Ognibene]

I definitely did a lot of binding to business objects without using a DataSource control.  While I agree that it's fairly impossible to cross reference to parameters, it should be at least noted that it was bound to an object directly, and there are other controls that have very basic data binding models (such as dropdowns) where it would be at least interesting to know the field names being used on the datasource.  I will look into the model binding thing if you look at the other stuff.  I can't promise that I'll be able to get to it until the weekend, though.

Thanks for your efforts so far!

[graham....@gmail.com]

That's a good point about drop downs. I'll have another think about direct data binding and see what we can offer. 

No rush, I think we're both a bit busy at the moment.

[Anthony van der Hoorn]

Hey guys, just wondering how we are going with this one?

Any progress on this one? Just wondering if there is anything we can do to help with the model binding work?

Cheers

Anthony 

--

You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.

[Stephen Ognibene]

Hi,

Thanks for following up.  I expect to be able to get back to this next week.  If you want to take a peek, please take a look at the demo page on Graham's repo.

-Steve O

[Anthony van der Hoorn]

Cool! Will pull it down and take a look :)

[Steve Ognibene]

Hello Graham and all,

I had some time this evening to post an update to the "DataSourceIDAndIndicateIfEventFired" branch of the data binding demo project that returns useful data when a control is data bound using the "simple" method that is commonly used with controls like DropDownLists

The demo code displays the name of the data source (such as the method name if the data is provided by a function call) as well as the name of the Value and Text properties.  I had to adjust the existing control adapter to be a "DataBoundControlAdapter" which is the common class for both ListViews and DropDowns, but it still works fine in the previous scenario and should additionally work for any other derived class now.  A different solution will probably be required for basic data bound controls such as textboxes.  Screenshot here of the two types of controls:

This branch of the demo project is here: 

https://github.com/grahammendick/GlimpseDataBinding/tree/DataSourceIDAndIndicateIfEventFired

One thing that I'm confused about is what the +<>D__3 stuff means on the DataSource field value, but GetColors is the correct name of the method in that class, so it's still usable.  The other thing is that the data source name disappears when you're doing a postback (since the data source bind code isn't called) and this makes the control forget its original source.  We may be able to plug into Glimpse infrastructure to solve this when writing the real code, but persistence across requests is something we'll have to keep in mind.

Graham, I know I said I'd look at the model binding stuff and that you would think further about the simple data binding for lists.  I forgot about that before I dove in tonight, and I didn't re-read how we said we'd divide it up until I was already done and writing this update.  I'm sorry and I hope I didn't ninja anything you were working on.  I would love to hear if you came up with anything in the meantime, or if you have any thoughts on what I've put together.  I think the skeleton that you put together for the control adapter has worked out wonderfully.  Thank you so much for that.

I'll try to look at the model binding stuff in the next week or so, or else you may be able to code something up for that?  I haven't used it much yet.

Cheers,

-Steve O

[graham....@gmail.com]

Hi,

Steve, nice to see your latest data binding forays. I'm still sceptical of the benefits of showing data binding details if DataSourceControls or ModelBinding aren't used because I don't think there's any useful information we can display. Although it looks like you're showing the method name in your example, unfortunately this isn't the case; you're showing the type name of the DataSource and, because you're using the yield keyword, this ends up being the name of the enumerator type auto-generated by .NET (which explains the +<>D__3 stuff). If you return an ArrayList instead, you'll see what I mean. I like that the data binding details disappear across post backs because it indicates that no data binding occurred, that no parameter values changed.

I've added a model binding example to the demo project. It uses a ModelBinder to get it's hands on the information rather than an Adapter. However, it still uses the Adapter to tie the model binding parameters to the respective Control (this relies on the synchronous nature of model binding). You'll notice that I get exactly the same information as in the DataSourceControl example, so we can present a consistent data binding story regardless of which approach is adopted.

I think the DataSourceControl and Model Binding examples prove the concept. Would you be interested in moving this into the Glimpse code base? There's some interesting work involved and I'd be happy to support you along the way.

Cheers,

Graham

[Stephen Ognibene]

Hi Graham,

Thanks for looking into this further.  Your explanation makes sense and I'll investigate that.  I've greatly enjoyed working on this as it has given me a better understanding of the reality of how these various "magic bits" actually inter-operate behind the scenes.  I'll review what you've posted as soon as I have time - should be a few days.

If we have proved the concept, I'll see what I can do to get this integrated with the Glimpse WebForms package if that makes the most sense (or do you think that your model binding work will make more sense as its own data binding plugin?)

Cheers,

-Steve O

--

[Anthony van der Hoorn]

Great teamwork guys! Really excited to see this get out.

--

You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.

[graham....@gmail.com]

Hi,

If you've enjoyed it so far, then you've got a treat in store incorporating this into the Glimpse code. The Glimpse code base can be a bit daunting, but I've got enough of an understanding to help you through turning the demo into a working Glimpse WebForms Data Binding tab. If you'd like I can provide an initial high level spec, detailing the different classes and guide to their implementation?

Cheers,

Graham

[graham....@gmail.com]

Hi Steve,

How're you getting on? Have you looked through the demo and started integrating it into Glimpse?

Cheers,

Graham 

[Stephen Ognibene]

Hi Graham,

I've been a bit distracted by the holidays and family visits, but I will get back to Glimpse soon.  Thanks for all of the hard work you did on this piece.

-Steve O

[Steve Ognibene]

Hi,

I was struggling a bit to get things working, but I think that it's in a pretty good place now. Even though it's incomplete, I see the light at the end of the tunnel.  I'm working here:

https://github.com/nycdotnet/Glimpse/tree/ASP.Net-Web-Forms-Data-Binding-Support

This Glimpse WebForms data binding initiative provides support for both DataBoundControls (such as lists and dropdowns), and also regular WebControls such as text boxes and checkboxes, etc.  It is based significantly on the code that you cooked up, Graham, but to get support for both types of controls, I had to drop the DataBoundControlAdapter down a bit on the inheritance chain.  I tried ControlAdapter first, but this was causing conflicts with the page adapter.  Anthony was kind enough to explain a bit to me regarding the history of the adapters and the previous work to get the Glimpse WebForms module to work with multiple page adapters.  I was getting ready to implement this, but then realized that there was a middle class available that still met my requirements.  When I switched DataBoundControlAdapter to inherit from WebControlAdapter, everything started working much better.  (Thanks for the help, Anthony; it was very useful to talk it out a bit.)  I also refactored the code to use a Dictionary of a specific type instead of a Tuple to ensure it would compile with .NET 3.5 (I have not tested it there yet).

So the current databinding functionality as implemented in that branch is as such:

On each request, a WebControlAdapter is programmatically registered in the HttpContext (doesn't require a browser file).  This adapter registers a handler for the control's DataBinding event.  If the event fires, the UniqueID of the control will be added as a key to a Glimpse DataBindingInfo dictionary in the HttpContext.  The flag indicating that the event did fire, and related parameter values, if available, will be added as sub-records.

This all seems to be working OK, and I'm now able to see that dictionary populated with all of the data-bound controls in the same method in Glimpse that maps out all of the ViewState.  So now it's hopefully a matter of merging the data binding dictionary in to the ViewState "pair" structures, or else passing in that dictionary and having the ViewState mapping method add extra sections for the controls that were data bound.  Not sure which will work the best yet - I have only just gotten to this point.

Does anyone have a concern with calling into the HttpContext current state on potentially every control rendering?  Is that fairly light-weight?  Is there a better way to get what the control adapter finds back into Glimpse?

I'll keep working on this, but I hope that a fully working demo (including the rendering) should be available within a week or two.  You can see the dataBindingInfo dictionary in action immediately by pulling down the above-linked branch and putting a breakpoint on line 32 of ViewStateFormatter.cs before running the ASP.NET sample project.

Any thoughts would be welcome and greatly appreciated.

Thanks,

-Steve O

[graham....@gmail.com]

Hi Steve,

Seasons greetings and it's great to see where you're up to. I've some comments that will hopefully help you on your way.

• Tab - Originally the idea was to slot the data binding info into the ControlTree tab, but this would need significant UI work (e.g., master/detail layout), which is currently out of scope based on Anthony's earlier comments. So let's create a separate Data Binding tab and keep the code entirely separate from the existing WebForms ControlTree tab.
• Control Adapter - Registering the Adapter without a browser file is the right idea, but we need to be careful we're not removing any Adapters already registered, so we'll need to use the same Generic Adapter technique employed by Anthony for the PageAdapter. First, loop through all currently registered adapters and if the type of the Control inherits from BaseDataBoundControl register our new Generic Adapter in its place. Then register a catch-all adapter for the BaseDataBoundControl (if not already done when performing the first loop). This should handle pretty much all scenarios. (We don't need a flag to indicate whether the Control was data bound because if it wasn't then it simply won't appear in the DataBinding tab. Neither are the Control_DataBound listener nor the overridden Render method required).
• Model - I like the DataBoundControlItemModel and Dictionary you created (the Tuple was only for proof of concept code). It might be cleaner to initialise a new dictionary in the Tab instead of the Adapter.
• HttpContext - there's currently no better way to return the Adapter's results back to the Glimpse tab. There's no performance cost involved because it's an in-memory collection.

This is only half the story because Model Binding also needs to be plumbed in. This should go in the Data Binding tab and can use the same Adapters registered above but will need a new ModelBindingInspector to run the code in the proof of concept. If you want any help let me know.

Cheers,

Graham 

[Anthony van der Hoorn]

I'm not sure how much data binding info we are looking at being displayed for a given control when data binding info is available, but for the short term I had envisioned that it would appear in the UI just like ViewState currently does. If a given control has both ViewState and data binding info, the data binding info would just show just under the data binding info thats currently there. Does that make sense? 

--

You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.

[Stephen Ognibene]

Hi Anthony,

There should only be a few pieces of databinding info per control.  I think there was some confusion regarding the overlap of the scope of this new feature and the new tab layout proposed by Graham.  If I may put words Anthony's mouth, he was saying "let's keep the UI simple for v1 and work on an improved UI layout once the core functionality is solid".

Graham - Thanks for the detailed feedback, info, and good wishes.  I agree with everything you've said except that I think it might be best to do a cheap/easy/ugly UI for this in v1 by just piggy-backing on the existing view state rendering.  As you pointed out, there is still work to do regarding WebForms model binding which will also take some time.  (Also my small brain will have to puzzle through the generic work-around - thanks for the extra explanation!)

My main reason for this is that (as I understand it) Anthony and Nik are working on some stuff for Glimpse v2 that perhaps could be leveraged.  So basically it's probably best to get the core data binding functionality shipped (simple controls + lists + model-bound)  even if there is a known-poor UI, and then do the good UI once we know what the v2 Glimpse environment will look like.

Is that agreeable to you?

Happy New Year,

-Steve O

[Anthony van der Hoorn]

Sounds good from my end.

[graham....@gmail.com]

Data binding in Web Forms is analogous to Model Binding in MVC which is why I thought it should have its own tab until master/details layouts are supported. But I'm more than happy for it to be displayed under the ControlTree tab because that's its proper home.

Cheers,

Graham

[Anthony van der Hoorn]

Great! As Steve said, UI placement of stuff will be changing in V2 to try and find better "homes" for data and like you, I think having it in the control tree is better and inline with what we are doing for v2.

[graham....@gmail.com]

Hi Steve,

The dictionary implementation doesn't quite work as is because the same control can be data bound multiple times within a single request.

Cheers,

Graham

[Stephen Ognibene]

Interesting. Would you be so kind as to put an example of that in the sample spike project you had originally created so I can experiment with it?

Thanks!

[graham....@gmail.com]

I've added an example to the sample project, https://github.com/grahammendick/GlimpseDataBinding/commit/7abbfc33184ecc36b9cae3ea5effca7c90fac739

I've rejigged the code so it looks more like yours; the Tuple's replaced with a DataBindParameter class and a Dictionary in Context keyed off the Control's UniqueID holds the data binding information. The important difference is that the value of this Dictionary is a List of Lists so it can keep track of multiple data binds against the same control. 

I hope this helps, just shout if anything isn't clear.

Cheers,

Graham

[Stephen Ognibene]

Hi Graham,

Thanks for doing this work.  I took some time to check out this code and I see what you've done.  I will get started with the integration soon.  Cheers!

-Steve O

[Nik Molnar]

Just wanted to drop a note of encouragement and say to keep up the good work guys!

I presented at a user group in NJ this week and the attendees were very excited about our WebForms support and the work you guys are doing in this area.

Thanks,
Nik

[Stephen Ognibene]

Thanks Nik.  It's getting there.

[graham....@gmail.com]

Thanks for the support, Nik. It's Steve that's doing all the hard work.

[Stephen Ognibene]

Folks,

I've made some progress, but there is still quite a bit of work to do.  I'm working here:  https://github.com/nycdotnet/Glimpse/tree/ASP.Net-Web-Forms-Data-Binding-Support

I figured out how to get data binding info to render in Glimpse for controls that also have some ViewState.  I haven't yet figured out the right way to get controls to render in Glimpse for those that lack ViewState (for example, txtIDNumber on DataBindingTests.aspx which I added to the WingTip sample project).  I'm sure it's simple, but I could use a hand figuring this out.  I'm currently digging around in ViewStateFormatter.cs between Process() and ProcessRecord() looking for the magic sauce.

For the controls that are rendering properly (mostly list-view style controls for now), I've improved the data that is collected and I think it's generally useful stuff.  Controls now support rendering data binding info for multiple data binds in a single page life cycle (thanks, Graham) including the count of items rendered in each.  Also, on .NET 4.5, they show the ItemType and SelectMethod used if available.  For simple controls, I've also started collecting the bound value based on what interface the control supports such as ITextControl or ICheckBoxControl (these aren't rendering properly yet, though, due to the above).

Still on the to-do list is migrating the model binding functionality already spiked out by Graham.  Also, I would like to ditch the marginally useful "data bound = true" and instead say "data bound during = page_preinit event" or "data bound during = page_load event", etc. to give a sense of relative timing of the data binding events for a control in the page lifecycle.  I think that this would be useful, especially in cases where a single control is bound multiple times.

I attached a recent screenshot of the visualization for a ListView.

Anyway, this feature is getting there.  I'm slowly learning how this all hangs together, but I am a bit stuck on the rendering thing.  I'd love to hear your feedback.

-Steve O

[graham....@gmail.com]

Hi Steve,

You were running into problems because you were hanging the processing off the ViewStateFormatter, when what you needed was your own Formatter. To this end, I've created a Glimpse branch https://github.com/grahammendick/Glimpse/tree/WebFormsDataBinding with a DataBindFormatter and changed the rendering to be more in keeping with the existing tab by adding a new Row to the Layout object of the ControlTree.

I've taken the opportunity to simplify things in this branch so it's more in keeping with the original propotype. For example, I've pared back the Adapter and data collected. I've also added the Generic Adapter pattern patented by Anthony so it works when there's already an Adapter registered (you'll see that I've added a ListViewAdapter in the WingTips sample). When I implemented this I encounted a couple of crazy .NET bugs which meant I had to change the order of things in the ControlTree (if the adapters are added before tracing is enabled then no data is shown in the ControlTree when the page first loads; and if the DataBoundControlAdapter is registered before the PageAdapter then the ViewState data isn't displayed).

I hope you like the changes I've made.

Cheers,

Graham

[graham....@gmail.com]

I've enhanced my Glimpse branch https://github.com/grahammendick/Glimpse/tree/WebFormsDataBinding to qualify the data binding parameters with the name of the page event when the data bind occurred. I've attached a screen shot showing the display (I've called DataBind four times in the example, but in reality it won't be called more than twice and never within the same page event). I extracted the page event information by using the PageLifeCycleMessages generated for the Page Life Cycle tab.

Cheers,

Graham

[Stephen Ognibene]

Hi Graham,

Thanks so much.  I will have some more time later this week.  Do you intend to work on this further or should I just pick up where you've left off?

-Steve O

[graham....@gmail.com]

Hi Steve,

The DataSource work is more or less finished, so we should move onto Model Binding using my branch as the starting point. Perhaps for Model Binding it would work better if I provide a high level spec, outlining the classes and methods we need to create, so that we're starting out on more solid ground. What do you think?

Cheers,

Graham

[Stephen Ognibene]

Hi,

Graham, so far your work and contributions have been really valuable; you've obviously got very deep expertise with WebForms and I'd love for you to contribute in whatever way you're willing (speaking as peers in this project).  If you're able to generate and deliver a spec for model binding beyond the spike we worked on already, I'm certainly willing to fill in the blanks.  We can always iterate more collaboratively once we've got the thing working.

Thanks again - I'll have time to look at your code in detail later in the week.

-Steve O

[graham....@gmail.com]

Hi Steve,

I'd like for you to have as much input as possible, so just trying to think of the best way to make that happen. I've got a pretty clear idea of how to implement this feature which is why I was thinking a spec might be a good way to go. But I can see how that might be less fun for you so am open to suggestions.

Cheers,

Graham

[Christophe Gijbels]

Hi Steve, Graham

 

I don’t know if you guys know about the tool VS Anywhere (https://vsanywhere.com) but it is like pair programming but remotely ;-)

If you combine that with a Skype session so that you can hear each other, then maybe Graham can help Steve without having to fully write down a spec and it might still be fun for Steve?

 

I tried it together with Nik and when we did it felt a lot better than when one of us is just sharing his screen, because it is a lot easier to show the other person where in the code for instance you would like him to have a look or to type something because those intentions are effectively visualized. I can remember a Skype screen sharing session where I was constantly clicking with my mouse on the screen-share of Nik to indicate Nik where I wanted to go, but that somehow had no effect ;-)

 

Maybe that can help you guys collaborate?

 

Cheers

 

Christophe (@CGijbels)

 

Van: getglim...@googlegroups.com [mailto:getglim...@googlegroups.com] Namens graham....@gmail.com
Verzonden: maandag 20 januari 2014 20:44
Aan: getglim...@googlegroups.com
Onderwerp: Re: [getglimpse-dev] Re: Glimpse Web Forms

 

Hi Steve,

 

I'd like for you to have as much input as possible, so just trying to think of the best way to make that happen. I've got a pretty clear idea of how to implement this feature which is why I was thinking a spec might be a good way to go. But I can see how that might be less fun for you so am open to suggestions.

 

Cheers,

Graham

On Monday, January 20, 2014 7:10:13 PM UTC, Steve Ognibene wrote:

Hi,

 

Graham, so far your work and contributions have been really valuable; you've obviously got very deep expertise with WebForms and I'd love for you to contribute in whatever way you're willing (speaking as peers in this project).  If you're able to generate and deliver a spec for model binding beyond the spike we worked on already, I'm certainly willing to fill in the blanks.  We can always iterate more collaboratively once we've got the thing working.

 

Thanks again - I'll have time to look at your code in detail later in the week.

 

-Steve O

On Mon, Jan 20, 2014 at 12:51 PM, <graham....@gmail.com> wrote:

Hi Steve,

 

The DataSource work is more or less finished, so we should move onto Model Binding using my branch as the starting point. Perhaps for Model Binding it would work better if I provide a high level spec, outlining the classes and methods we need to create, so that we're starting out on more solid ground. What do you think?

 

Cheers,

Graham

On Monday, January 20, 2014 12:51:26 PM UTC, Steve Ognibene wrote:

Hi Graham,

 

Thanks so much.  I will have some more time later this week.  Do you intend to work on this further or should I just pick up where you've left off?

 

-Steve O

 

On Sun, Jan 19, 2014 at 10:31 AM, <graham....@gmail.com> wrote:

I've enhanced my Glimpse branch https://github.com/grahammendick/Glimpse/tree/WebFormsDataBinding to qualify the data binding parameters with the name of the page event when the data bind occurred. I've attached a screen shot showing the display (I've called DataBind four times in the example, but in reality it won't be called more than twice and never within the same page event). I extracted the page event information by using the PageLifeCycleMessages generated for the Page Life Cycle tab.

 

 

 

Cheers,

Graham

 

This branch of the demo project is here: 

[graham....@gmail.com]

Thanks Christophe, VS Anywhere looks ace - much more fun than a boring old spec!

To unsubscribe from this group and all its topics, send an email to getglimpse-dev+unsubscribe@googlegroups.com.

[Stephen Ognibene]

I'm just laughing that we're focused on what's more fun for Steve.  :-)

I'll have some time later this week to dive into this and let's give that a shot later on if you've got time and are willing.

Cheers,

-Steve O

[Nik Molnar]

I can also give a big thumbs up for VS Anywhere.

It was a little fishy to get set up, but once it was we were rocking.

Thanks,
Nik

[Anthony van der Hoorn]

As a side note, love the way things are looking. If you need help on any layout stuff, make sure you let me know.

Also, just wondering, in the last screen shot, it showed "Load" and "Load 1" what is the difference between the two? Is it the difference between the referrer and the current page?

[Stephen Ognibene]

Controls can sometimes be databound multiple times, so that's showing that it was bound 2x and both happened during the Page_Load event.

[Anthony van der Hoorn]

Ok cool... I wonder if there is a better way of showing that. 

Maybe if there are multiple times that it occurs in the one event, instead of having Load and Load 1, we just had Load, and in the value cell we have a dictionary where the key is an int which shows the position/index and the value shows what we currently have.

I think this should be pretty easy to do based on if there is already a value for a given event. If there is, we pull it out and replace it with a dictionary and go from there. 

Let me know what you think.

[graham....@gmail.com]

Having two databinds against the same control within a single event would never really happen, I just forced it into the WingTips sample to make sure no parameter information was lost. You'd have to be doing something pretty odd for it to happen in the wild.

But it can definitely be done as you suggest if you think it's still warrants it?

[Anthony van der Hoorn]

If we think its that rare than I'm cool leaving it as is. Just thought if it was more common that it might be a little clearer whats happening.

[graham....@gmail.com]

Hi Anthony,

Even though it's a rare scenario I made the change to the display. Have a look at the attached image and let me know if that's what you were after.

I've run into a problem that you can no doubt help with. I'm using the PageLifeCycleEventMessages to match up the data binding to its corresponding page event. It all seems to work when I run in debug mode, but when I run without debugging the events don't match up properly - I'm using the StartTime added to the event by the PageLifeCycleInspector. Is the problem that the trace messages are fired asynchronously? How do you match up the SQL queries to the page life cycle event in the HUD?

Cheers,

Graham

<span style="color:windowtext

...

[Anthony van der Hoorn]

First up I like the design update. As a side point, if you wanted the width of the key column to be less, instead of using an dictionary, you could use a list with an object that has a Key and Value property. This would allow the Value to open up a little more. By default dictionary key columns have a min width. It was thought that most of the time dictionaries would have string values and hence a min width made sense.

In terms of matching up the events to sql queries, this is done via looking at the start times. Since the PageLifeCycle events have a start time and the SQL events have a start time, I just use that. It works sense even though PageLifeCycle events can be async, they still happen in order.

Does that help?

[graham....@gmail.com]

I'm still a bit confused. I'm within a ControlAdapter so I'm not able to raise Glimpse messages (because I don't have a Glimpse context). Instead I'm just storing a DateTime.Now in the Request. When it comes to the GetData I compare this stored DateTime with the PageLifeCycleEventMessage StartTimes to find the corresponding event. However, this DateTime isn't matching up correctly - is it because I'm mixing up my own DateTime with Glimpse's StartTime? (Note, this only seems to go wrong when I'm not debugging)

...

[graham....@gmail.com]

Hi Anthony,

I've fixed my timing/event issue but it's a bit of a 'hack' so I'm hoping you can tell me the Glimpse way to fix it.

Outside debug mode the code runs so fast that the DateTime.Now's were all evaluating as equal. For example, a few PageLifeCycleEvents all had exactly the same number of ticks and this prevented the event matching from working correctly.

I saw that a lot of the Glimpse code uses a TimerStrategy and compares Offsets instead. So I switched to using the TimerStrategy and the event matching works. However, I'm currently calling a deprecated Glimpse method to get the TimerStrategy, https://github.com/grahammendick/Glimpse/blob/WebFormsDataBinding/source/Glimpse.WebForms/Inspector/DataBoundControlAdapter.cs#L43

Firstly, is what I'm doing correct?

Secondly, how can avoid calling the deprecated method - remember I'm in a ControlAdapter so haven't got access to the Glimpse context.

Cheers,

Graham

On Wednesday, January 22, 2014 9:20:23 PM UTC, avanderhoorn wrote:

</

...

[Anthony van der Hoorn]

Nik is going to take a look at this to make sure we are on the same page, but using `Glimpse.Core.Framework.GlimpseConfiguration.GetConfiguredTimerStrategy()` is currently correct. Its a hack that we found we have to use in v1 but in v1 this will change. 

--

[Nik Molnar]

Yep, as Anthony said what you are doing is correct for version 1.x but it will break in version 2.0 of core.

In the future you'll have static access in places like this, here's a sample of the current usage code from the version-2 branch (this could change slightly!)

if (GlimpseRuntime.IsInitialized)
{

    var timer = GlimpseRuntime.Instance.Configuration.TimerStrategy();

    var token = timer.Start();

    // do some work

    var timerResult = timer.Stop(token);

}

Alternatively, if all you want to do with the timerResult is publish a timeline message, you could use the API created for end users, which currently looks like this:

using (GlimpseTimeline.Capture("name of event", "timeline subtext"))
{
    // do some work
}

Let me know if you have any questions!

Thanks,
Nik

[graham....@gmail.com]

Thanks guys.

In version 2 is there going to be a way to statically raise messages? In Web Forms we're using control adapters instead of inspectors, which means we haven't got access to the glimpse context and so can't raise messages to communicate with the tab. The way we currently pass data is by storing variables in the Request which we can later access from the tab. But if we could raise messages from a control adapter then we can remove this 'messy' code.

Cheers,

Graham

<a href="https://lh3.googleusercontent.com/-ysXL7Uu3xkQ/UtvvqveFHQI/AAA

...

[Anthony van der Hoorn]

That is the intent. We want to make dealing with cases like this much easier that what we have now.

--

[graham....@gmail.com]

Hi All,

Steve, I know we were going to have a session on the work still to do but I got in the zone today and finished it off. Before I put in a pull request I'd be grateful if you could have a look over it. The code can be found at https://github.com/grahammendick/Glimpse/tree/WebFormsDataBinding

DataSources and Model Binding are both now supported. I spent some time ensuring the displayed data is consistent across the two scenarios. To achieve this two main changes were needed which are outlined below, taking a Control as the example parameter binding source (although the same applies to all data sources):

1. Instead of showing the text 'ControlParameter' and 'ControlValueProvider' I lopped off the words 'Parameter' and 'ValueProvider' so it just reads 'Control'; and I renamed the column from Type to Source.

2. The DataSource display was showing the name of the method parameter rather than the Control Id displayed in the Model Binding case. I corrected this by using the DefaultProperty attribute that decorates a ControlParameter to gain access to the ControlID property.

I've also incorporated the two design suggestions from Anthony. 

Returning to the first post in this thread, the only issue outstanding is regarding certain Web Forms Requests that aren't handled by Glimpse (Response.Redirect, Server.Transfer and PageMethods). I saw Christophe raised PR #606 a while back but nothing has happened on it for a while. Is this waiting for version 2?

Cheers,

Graham

On Monday, November 4, 2013 1:29:22 PM UTC, nikmd23 wrote:

<<Trying an experiment to move this to the dev list. If it doesn't work out, I'll re-post. Everyone has been BCC'ed so your replies should just go to the public mailing list>>

These are all great idea's Graham. I really appreciate you taking the time to brainstorm this. I really like the idea of getting something going for data binding because I still remember the pain involved there.

I echo Chris's statement, in a slightly generalized tone: Now we need to figure out if/how we can implement these things. As you know, WebForms isn't the most extensible framework in the world.

Thinking particularly of data binding (though the question is open for all items), do you have any ideas about how we might pull this off?

Thanks,
Nik

On Mon, Nov 4, 2013 at 10:38 AM, Christophe Gijbels <christoph...@gmail.com> wrote:

Hey Graham

Thanks for the feedback to start with!

The issues you mention with the Requests are known ones, for instance for the PageMethod we have the following issue that has been opened recently (https://github.com/Glimpse/Glimpse/issues/596). 

Unfortunately all of them are the result of prematurely aborting/short-circuiting the asp.net request pipeline processing. They all call  httpApplication.CompleteRequest() at some point.

The Response.Redirect(url) does an endResponse by default, the ScriptModule does the same once the webmethod did its thing and the Server.Transfer, well it does the same...

I'm not sure how we can intercept this, but there are no pipeline events indicating that the pipeline is being aborted prematurely... but we're still looking into this, hoping that there is a solution somewhere ;-)

Cheers

Christophe

On Sun, Nov 3, 2013 at 6:58 PM, Graham Mendick <graham....@gmail.com> wrote:

Hi,

I've jotted down some high level ideas about where Glimpse Web Forms could go next. I haven't gone into any implementation details because I thought it best to see what you think first.

Requests

Glimpse should support all different types of Web Forms request. Currently it doesn't support the following:

1. Response.Redirect - only the second request is captured, the first doesn't show up in the History tab.
   
2. Server.Transfer - 'crashes' Glimpse, all the tabs disappear.
   
3. PageMethod - the request isn't captured.
   

Control Tree

I've come up with a dev tools-inspired redesign of the Control Tree Tab. The Controls are displayed in a expandable tree where hovering over a Control in the tree highlights the corresponding rendered element in the web page. 

The details panel to the right of the Control Tree is where context information is displayed for the selected Control. The ViewState and ControlState would feature here, as would Control Event timings. This way we could remove the Page Life Cycle tab and display these event timings in the details panel when the Page is selected in the Control Tree.

Because Web Forms is Control-centric any new Glimpse Web Forms development can be displayed within this details panel rather than creating a new tab.

DataBinding

Glimpse should add support for Web Forms DataBinding, displaying consistent information regardless of whether .NET 4.5 Model binding or DataSources are used. There's no need for a separate DataBinding tab because the information can be displayed in the Control Tree's details panel when a DataBound Control, e.g., ListView, is selected.

Looking forward to your feedback.

Cheers,

Graham

[Stephen Ognibene]

Hi Graham and Team,

I'm very pleased with pull request 716 (https://github.com/Glimpse/Glimpse/pull/716).  I still want to do more testing on my apps before I'm comfortable with recommending that it be merged in, but I think it's a big improvement to the Glimpse WebForms project for sites that use data binding.  This is great news - well done Graham!!  The team has been very generous with regards to spreading praise around, but I want to make sure that everyone understands that Graham did the majority of the work on this one and really deserves most of the credit.  It's great.

I do have a minor concern that this feature may be too limited in scope as currently implemented.  It works wonderfully for controls that inherit from DataBoundControl such as list views and dropdowns.  However, it won't work with DataGrid or DataList controls, nor any of the elementary controls such as Checkbox, Textbox, etc.  In my opinion, this should be addressed since these types of controls are so core to the "WebForms thing".  I'm just thinking of a new developer looking over an unfamiliar project wondering how a certain textbox got its value.  Wouldn't it be nice if Glimpse could provide the answer "well, it got the correct value in the Page_PreLoad event, but then it looks like it was rebound unexpectedly in the Page_Load event to some other value".

A few weeks ago, Graham expressed skepticism about being able to show useful information in situations outside of those involving DataSourceControls or ModelBinding.  I'd like to advocate that at least identifying the page events when these types of controls were bound, how many times they were bound, and perhaps collecting their values at bind time might be quite useful, even if it were just for instructional value or for helping to make unlikely situations such as multi-binding more obvious.  I'd love to hear any other opinions on this.

Supporting other control types would probably involve refactoring the "DataBoundControl" ControlAdapter down to a "WebControl" ControlAdapter (the highest common class between DataBoundControl and the elementary controls).  Graham will know if this is technically possible or not.  A WebControl ControlAdapter was working in an earlier branch (minus the generic fix wizardry and any sort of useful rendering, of course), so I hope it will still be possible to adjust the new robust implementation to support those other controls.

Anyway, I wonder what folks' thoughts are regarding support for a larger variety of controls and binding scenarios (and, in particular, if Graham thinks it would be technically possible to use a WebControl ControlAdapter at all).  If the response is positive, I'd still probably recommend to ship this thing as-is (allowing for more time for testing first, etc.) and then perhaps get the other stuff working in a following patch.

Best regards all-around.  Thanks again, Graham, for your excellent work.

Cheers,

-Steve O

Reference:  DataBoundControl and WebControl (you can see the inheritance trees)
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.databoundcontrol.aspx
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.webcontrol.aspx

PS: I suspect that the Response.Redirect, Server.Transfer and PageMethod support may have to wait until v2, but Christophe, Nik, or Anthony will know more definitively

--
You received this message because you are subscribed to a topic in the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/getglimpse-dev/dXtAuQg3UaA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to getglimpse-de...@googlegroups.com.

[Nik Molnar]

Hey guys.

Want to start off by once again saying that you are doing a fantastic job and we're thrilled to see what happens next for the WebForms package.

I do tend to agree with Steve that having support (if at all possible) for more general controls would be a great thing. However, the way I tend to view the world is in breaking changes.

What I mean is if we release what we have now, and a little ways in the future have support for more controls, will that be a breaking change for users? I don't think it will be - but I'm just making sure that users don't have to change code or config for this to work. I think users would just have to update their NuGet package and the Binding tab would instantly be better.

If my assumption is right, than I think you can release what you have now (once you feel confident it's been tested) and work towards adding more support with even more user feedback.

If my assumption is wrong, or you'd basically have to do an entire rewrite to add in the extra functionality - then it may be best to hold out.

Basically, we take major version changes pretty seriously and that should be considered. ;)

As far as the Response.Redirect, Server.Transfer support - I don't think we need to wait until V2 of that. Chris has implemented a fix for that against the master (V1) branch - but Chris can tell you why he's hesitant about pulling it in. (I think he said it just needs more testing.)

Thanks,
Nik

--

You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.

[Nik Molnar]

Graham,

Yes, in version 2 of the runtime you'll be able to access everything statically once Glimpse is initialized.

Your code will look something like this:

if (GlimpseRuntime.IsInitialized){

    var mb = GlimpseRuntime.Instance.Configuration.MessageBroker;

    var l = GlimpseRuntime.Instance.Configuration.Logger;

    var currentRuntimePolicy = GlimpseRuntime.Instance.CurrentContext.ActiveRuntimePolicy;

}

Let us know if you have any feedback with this approach.

Thanks,

Nik

[Anthony van der Hoorn]

I agree with Nik. Unless there is some reason not to, lets release the feature set we have, making it known what the current limitations are. From there we can working on the next iteration of the feature set which includes support for the wider control set.

[graham....@gmail.com]

Cool, I'll spell out the limitations in the release notes.