This project is read-only.

Possible Friendly URL Rewriter problem

Topics: Developer Forum
Dec 2, 2008 at 3:28 PM

I have the problem with the friendly URL rewriter. I have a register page where the user registration process goes in few steps like:

Step 1: Enter email and system sends verification code
Step 2: Enter verification code
Step 3: If the code is valid user enters his profile data (password, first name, last name, company etc.)
Step 4: Confirmation screen shows

All these steps are on one page implemented in a MultiView control as custom Views. when the user comes on the page for the first time always Step 1 is shown. To go to the page this url is used:

After the Step 1 is executed (the verification code is sent to the user) the MultiView just changes the active View and the view for Step 2 is shown. In this moment if you take a look at the url in the browser address bar this is what you see:

Does anybody knows what might be the problem here? I am not messing around anywhere with rewriting the url's by myself...

Dec 2, 2008 at 5:16 PM
This is an unfortunate side-effect of using RewritePath to pass the request to the correct page handler. There is a workaround in the template project. It configures a control adapter to rewrite the html action to the frindly url. You could do something similar.
Dec 3, 2008 at 11:51 AM
A somewhat related issue: when page is referenced by an "hostile" URL (e.g.: [ */Template.aspx?page=N ]), then a default template from [TemplateAttribute] gets not applied.
Here's the possible fix (though, i'm unsure of it's correctness):

<file name="20081203-n2-urlparser-fix_template.patch">
Index: UrlParser.cs
--- UrlParser.cs (revision 501)
+++ UrlParser.cs (working copy)
@@ -66,7 +66,8 @@
  ContentItem item = TryLoadingFromQueryString(url, "page");
  if(item != null)
- return new TemplateData(item, item.TemplateUrl, url["action"], url["arguments"]).UpdateParameters(url.GetQueries());
+ return item
+ .FindTemplate(url["action"] ?? TemplateData.DefaultAction);
  string path = Url.ToRelative(url.Path).TrimStart('~');
Dec 3, 2008 at 11:56 PM
Looks good, I'm adding it.
Dec 8, 2008 at 12:23 PM
Now exactly the same issue happens in Zone control: when children are added, only their .TemplateUrl property is being considered..

The fix might be this:

<file name="20081208-n2-TemplateUrlEventArgs-fix_zone_children_template.patch">
Index: TemplateUrlEventArgs.cs
--- TemplateUrlEventArgs.cs (revision 508)
+++ TemplateUrlEventArgs.cs (working copy)
@@ -12,7 +12,7 @@
  public TemplateUrlEventArgs(ContentItem item)
  this.item = item;
- this.templateUrl = item.TemplateUrl;
+ this.templateUrl = item.FindTemplate(TemplateData.DefaultAction).TemplateUrl ?? item.TemplateUrl;
  private string templateUrl = null;

Though, i don't like it much. Here's the plan i'd think will play better in fixing attribute-based templates:

1) Incorporate default template resolution into ContentItem.TemplateUrl property (there'll be no need to heavily modify all sources to extinct all reference to the former, for instance. consider: Control IContainable.AddTo(Control container) in ContentItem.)
2) Drop DynamicTemplateAttribute
3) Implement mechanism for resolving a default template without [2]. (The trickies moment, as for me)
Dec 8, 2008 at 1:19 PM
Sorry, my previous patch is incomplete. I've posted a cummulative patch to google code. A general idea is this:

1) An overridable ContentItem.TemplateUrl property is left intact (though, i think it's worth refactoring)
2) Added non-virtual assembly-wide property ContentItem.DefaultTemplateUrl wich considers both TemplateUrl and FindTemplate(..) paths to obtain a template.
3) All over N2 project replaced a references to TemplateUrl with DefaultTemplateUrl.

Note: the patch contains some of my previous tweaks to N2, they're not critical, as far as i can see now, thus should be ignored. Sorry for soaking your time with that..

Dec 8, 2008 at 8:57 PM
I'll check it out, thank you =)