I've some community integration within Umbraco. Each time a member registers, they have a profile page. Rather than create a new piece of content each time one Umbraco page/template is used (/users/member-profile). To this end I've setup my own UrlRewriting rules in the config; e.g. /user/user-name to redirect to /page/lookup-user.aspx
The idea here is that the custom .aspx page looks up the users ID based off the username in the querystring, this works fine. The problem is when I try to server transfer from this page to the Umbraco page/template. If I perform a server transfer to /users/member-profile?member-id=X .NET throws an "Error executing child request" exception. If I change the path to /users/member-profile.ASPX?member-id=X .NET throws an error because it tries to validate that that physical file exists (which of course it doesn't, it's in Umbraco). A response.redirect works but this isn't an option, the URL has to stay in the /user/user-name format. Transferring to /default.aspx?umbPageID=[PAGE_ID]&member-id=X gets confused cause it only expects the umbPageID param.
What are my options here? Any help would be appreciated.
I've used a server transfer to a custom, physical .ASPX page and this page performed a call to umbraco.library.RenderTemplate, did a response write of the output and a response end. This seems more cumbersome than I'd like though.
You can get the member id from the membership API if they're logged in. So you shouldn't need to pass it around on the querystring. You can just put a Macro with a user control in it, and have the user control pull out the info you want to display using the API. There's some code examples here: http://our.umbraco.org/wiki/how-tos/membership-providers
Thanks for your suggestion Tim but it's not applicable in this case. Sorry, I should have mentioned that this is a custom member/community instance, not the in-built Umbraco one.
Ahhh! How about having the /member/username redirect to the umbraco page instead of the intermediate page, and then have a user control on that page that looks up the user and pulls out the information to display, cutting out the middle page and the need for the server.transfer?
I think the issue is that when you request an Umbraco page it sets up a lot of stuff to do with the context, and when you call server.transfer it keeps the existing context and then tries to set it up again, causing the error that you're getting. Server.Transfers are treated as a "child" request of the page you're actually executing, whereas a Response.Redirect returns a header to the client and initiates another request, so you don't run into this issue.
That is a possibility but the member ID is the primary key, naturally. As such all the BLL methods accept it as an argument when performing any member related functions. I didn't want to overload all these methods with username as an argument. There are numerous controls on a page which use member data, I could make them smarter and have them perform the username to member ID mapping but having an intermediary page that did this before the controls had to seemed the best solution, though perhaps not now that I've delved into it a little more. So, my options I guess are to use a custom intermediary page and a 2nd custom page which calls render template OR update all the necessary controls to perform their own username to member ID mapping? These are my only options?
There is another option. On an old CMS system I wrote, long before Umbraco, I had a similar issue, where I wanted the content class to be available to all of the user controls on the page, without having to get the content on every control (with up to 15 controls per page, it would have been waaay too DB heavy). So what I ended up doing is this:
On the PreInit of the page, I looked at the URL, used it to look up the content, populated a content class with all the important stuff, and the stuck the object in the HttpContext.Items (a per request cache, if you're not familiar with it, more info here: http://www.4guysfromrolla.com/articles/060904-1.aspx). I also handled things like invalid URLs (member names in your case) in there, as well as anything else to do with loading the content. Once that was done, all of my user controls could just check the HttpContext.Items collection for the class, and never needed to go back to the database to get the page info.
You could do something similar with your pages, to make them only have to get the member info once. If you want an example of the code, I can probably dig it out from my old site archive if you like?
Server Transfer issue
Hi,
I've some community integration within Umbraco. Each time a member registers, they have a profile page. Rather than create a new piece of content each time one Umbraco page/template is used (/users/member-profile). To this end I've setup my own UrlRewriting rules in the config; e.g. /user/user-name to redirect to /page/lookup-user.aspx
The idea here is that the custom .aspx page looks up the users ID based off the username in the querystring, this works fine. The problem is when I try to server transfer from this page to the Umbraco page/template. If I perform a server transfer to /users/member-profile?member-id=X .NET throws an "Error executing child request" exception. If I change the path to /users/member-profile.ASPX?member-id=X .NET throws an error because it tries to validate that that physical file exists (which of course it doesn't, it's in Umbraco). A response.redirect works but this isn't an option, the URL has to stay in the /user/user-name format. Transferring to /default.aspx?umbPageID=[PAGE_ID]&member-id=X gets confused cause it only expects the umbPageID param.
What are my options here? Any help would be appreciated.
Cheers
I've used a server transfer to a custom, physical .ASPX page and this page performed a call to umbraco.library.RenderTemplate, did a response write of the output and a response end. This seems more cumbersome than I'd like though.
You can get the member id from the membership API if they're logged in. So you shouldn't need to pass it around on the querystring. You can just put a Macro with a user control in it, and have the user control pull out the info you want to display using the API. There's some code examples here: http://our.umbraco.org/wiki/how-tos/membership-providers
Hope that helps!
:)
Thanks for your suggestion Tim but it's not applicable in this case. Sorry, I should have mentioned that this is a custom member/community instance, not the in-built Umbraco one.
Ahhh! How about having the /member/username redirect to the umbraco page instead of the intermediate page, and then have a user control on that page that looks up the user and pulls out the information to display, cutting out the middle page and the need for the server.transfer?
I think the issue is that when you request an Umbraco page it sets up a lot of stuff to do with the context, and when you call server.transfer it keeps the existing context and then tries to set it up again, causing the error that you're getting. Server.Transfers are treated as a "child" request of the page you're actually executing, whereas a Response.Redirect returns a header to the client and initiates another request, so you don't run into this issue.
That is a possibility but the member ID is the primary key, naturally. As such all the BLL methods accept it as an argument when performing any member related functions. I didn't want to overload all these methods with username as an argument. There are numerous controls on a page which use member data, I could make them smarter and have them perform the username to member ID mapping but having an intermediary page that did this before the controls had to seemed the best solution, though perhaps not now that I've delved into it a little more.
So, my options I guess are to use a custom intermediary page and a 2nd custom page which calls render template OR update all the necessary controls to perform their own username to member ID mapping? These are my only options?
There is another option. On an old CMS system I wrote, long before Umbraco, I had a similar issue, where I wanted the content class to be available to all of the user controls on the page, without having to get the content on every control (with up to 15 controls per page, it would have been waaay too DB heavy). So what I ended up doing is this:
On the PreInit of the page, I looked at the URL, used it to look up the content, populated a content class with all the important stuff, and the stuck the object in the HttpContext.Items (a per request cache, if you're not familiar with it, more info here: http://www.4guysfromrolla.com/articles/060904-1.aspx). I also handled things like invalid URLs (member names in your case) in there, as well as anything else to do with loading the content. Once that was done, all of my user controls could just check the HttpContext.Items collection for the class, and never needed to go back to the database to get the page info.
You could do something similar with your pages, to make them only have to get the member info once. If you want an example of the code, I can probably dig it out from my old site archive if you like?
Ended up going with the RenderTemplate approach. I can always cache that output if needed.
is working on a reply...