P
Peter Jaffe
I've seen a few posts on this topic, but still haven't found a clean
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?
The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.
Possible Solutions
------------------
I have considered the following options, but #2 seems like the only
"complete" solution, yet it still doesn't feel right...
1) Alter the ASP.NET framework's __doPostBack JavaScript method to
add the eventTarget to the query string of the form's action.
- This won't cover Buttons or ImageButtons since they don't use
__doPostBack
- It can result in cryptic page identifiers (e.g.
ucInquiryResult$grdList$_ctl5$_ctl0)
+ Implementation Options:
* A Response filter - quick POC provided feasible, but what is the
performance cost?
* Try to override the function that generates the __doPostBack
function, but it appears to be in the private method
System.Web.UI.Page.RenderPostBackScript(), so I don't think this is a
viable option.
2) Create custom WebControls that inherit from Button, ImageButton,
LinkButton, etc. These could expose a property whose value is passed
to client side JavaScript as part of the click event. The JavaScript
would rewrite the query string of the form's action attribute.
- Not sure how many controls this would involve. What about
LinkButtons in a ButtonColumn of a DataGrid...?
3) Implement a response filter that recognizes input and anchor
elements and inserts the necessary JavaScript to inject identifiers
into the form action's query string.
+ This is similar to #2, but would be implemented as a central
Response filter rather than having to use multiple custom WebControls.
- However, there is no clear place to specify the desired
"identifier" and therefore results in the same "cryptic identifier"
problem of option #1.
- The string manipulation to generate this additional JavaScript
could be messy and error prone.
4) Could do one-off logic on each relevant control that triggers a
PostBack.
- Hard to maintain. Requires a full sweep of the app and ongoing
diligence, or else the choice to respond to requests from those who
want to collect statistics. The later would have an annoying lag in
getting the requested "identifiers" into production.
5) Implement a page name mapping layer in an HttpModule so a set of
URLs (one for each "identifier") can be used to target the same page.
- This can help for recognizing multiple different entry points, but
the subsequent PostBack requests will be indistinguishable from the
previous without employing another strategy for altering the action of
the HTML form element.
6) Instrument from inside the application. Need to figure out how
this would be published so it can be consumed by the appropriate
people/tools.
Thanks for your time,
Pete
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?
The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.
Possible Solutions
------------------
I have considered the following options, but #2 seems like the only
"complete" solution, yet it still doesn't feel right...
1) Alter the ASP.NET framework's __doPostBack JavaScript method to
add the eventTarget to the query string of the form's action.
- This won't cover Buttons or ImageButtons since they don't use
__doPostBack
- It can result in cryptic page identifiers (e.g.
ucInquiryResult$grdList$_ctl5$_ctl0)
+ Implementation Options:
* A Response filter - quick POC provided feasible, but what is the
performance cost?
* Try to override the function that generates the __doPostBack
function, but it appears to be in the private method
System.Web.UI.Page.RenderPostBackScript(), so I don't think this is a
viable option.
2) Create custom WebControls that inherit from Button, ImageButton,
LinkButton, etc. These could expose a property whose value is passed
to client side JavaScript as part of the click event. The JavaScript
would rewrite the query string of the form's action attribute.
- Not sure how many controls this would involve. What about
LinkButtons in a ButtonColumn of a DataGrid...?
3) Implement a response filter that recognizes input and anchor
elements and inserts the necessary JavaScript to inject identifiers
into the form action's query string.
+ This is similar to #2, but would be implemented as a central
Response filter rather than having to use multiple custom WebControls.
- However, there is no clear place to specify the desired
"identifier" and therefore results in the same "cryptic identifier"
problem of option #1.
- The string manipulation to generate this additional JavaScript
could be messy and error prone.
4) Could do one-off logic on each relevant control that triggers a
PostBack.
- Hard to maintain. Requires a full sweep of the app and ongoing
diligence, or else the choice to respond to requests from those who
want to collect statistics. The later would have an annoying lag in
getting the requested "identifiers" into production.
5) Implement a page name mapping layer in an HttpModule so a set of
URLs (one for each "identifier") can be used to target the same page.
- This can help for recognizing multiple different entry points, but
the subsequent PostBack requests will be indistinguishable from the
previous without employing another strategy for altering the action of
the HTML form element.
6) Instrument from inside the application. Need to figure out how
this would be published so it can be consumed by the appropriate
people/tools.
Thanks for your time,
Pete