Edit interface not obeying .aspx extension

Topics: Developer Forum, Project Management Forum, User Forum
Mar 16, 2009 at 5:24 PM
I have a page name that ends with .aspx. I can create that page without any issues. After the page is created I hover over the page in the navigation tree and the URL that is displayed in the bottom left of my browser shows the URL without the .aspx extension. Since this is the case, when I try to view the page in the Edit interface I get an error.

I have an override for the Extension property of the page so we can allow users to set the extension they would like to use. Here is the code for the Extension override:

        public override string Extension
        {
            get
            {
                if (string.IsNullOrEmpty(this.Name))
                    return base.Extension;
                int nameLastIndex = this.Name.Length - 1;
                int extensionIndex = this.Name.LastIndexOf('.');
                if ((extensionIndex > 0) && (extensionIndex < nameLastIndex))
                    return this.Name.Substring(extensionIndex);
                return base.Extension;
            }
        }

I cannot figure out why the .aspx is getting removed from the URL. Any help would be appreciated.

Thanks
Daniel
Coordinator
Mar 16, 2009 at 8:29 PM
Any chance you have configured the site not to use extensions and you're running into one of those cases where base.Extension is returned?
Mar 16, 2009 at 9:02 PM
In the web.config the extension is not set as you suggested. But when debugging the code base.Extension is never returned, .aspx is always returned as the extension.

When I do add the .aspx as the extension in the web.config, the Url property of the page now has .aspx.aspx as the extension.

This worked in a previous version before 1.4.4, although I am not sure which one. After doing some research it seems like it might be how the URL is determined for the content item.

Thanks
Daniel
Mar 18, 2009 at 11:24 AM
I just wanted to ping this thread and see if there was any update on this? The /Edit interface is broken for all of our websites since upgrading (I work with dgelbaum) to the latest N2 because it is not obeying the Extension property of any page. How can we fix this?
Mar 18, 2009 at 1:48 PM
Using an HTTP Proxy, I looked at the request for when the tree loads the nodes that are having the issue and noticed something interesting: The HREF is wrong (it's missing the extension) however the REL attribute is correct (except that it has a slash on the end)!

Here's a sample:

<li><a href="/test/path/pagename" target="preview" rel="/test/path/pagename.aspx/"><img src='...'/>pagename.aspx</a></li>

Any ideas? I'm digging through the N2 source, but there are so many paths to follow I'm not making much progress.

Thanks -

-James
Coordinator
Mar 18, 2009 at 5:09 PM
Hi, I wasn't expecting anyone to put the extension in the name and I didnt consider the possibility of a breaking change here.

The string that appears as href in the link you posted is retrieved from the content item's Url property (via INode.PreviewUrl).

Try overiding the Url property and setting a break point in it.

        public override string Url
        {
            get
            {
                return base.Url;
            }
        }

From there you can follow the call stack and see why the url is getting stripped like that.

It might be useful to know how an url is mapped back to the content item. The UrlParser strips the extension and asks the start page to FindPath the url without the extension. Each page recursively iterates each child asking it if it equals the next segment of the url.
Mar 18, 2009 at 5:41 PM
> Hi, I wasn't expecting anyone to put the extension in the name and I didnt consider the possibility of a breaking change here.

I don't understand why the extension is not simply part of the name. What benefit does the concept of extension provide to N2? I cannot think of any, but I am still relativly inexperienced with the system. From my perspective, a far simpler approach would be to have an optional "ForceExtension" property that updated the name with the extension you want to force automatically (so a name of "page" gets forced to be "page.aspx" when ForceExtension = ".aspx"). If "ForceExtension" is not set, then there would be no extension other than that specified in the name. Would this not be a better approach?

> From there you can follow the call stack and see why the url is getting stripped like that.

The level of abstraction in N2 makes very powerful, but it also makes it very maze-like to those of us unfamiliar to the code base. We've been trying to follow the N2 code all day, but it feels like we're wasting time. 

> The UrlParser strips the extension and asks the start page to FindPath the url without the extension.

Again, I do not see the benefit in this. Asside from being unnecessarily complex, it is extra processing - if the name and the extension were not seperate then determining the URL would be a far simpler operation: Just concatenate parent item names with "/".

At this point we have decided to roll back to 1.4.3. In 1.4.4 we had a problem being unable to use "." in the Name. We hoped this would be resolved in 1.4.5 but now we are having this URL issue. 

What are our next steps to correct this issue and update to the latest version of N2? There are new features that our users are very eager for, and we are now stuck on an old version.

We greatly appreciate your help.

Thank you -

-James
Coordinator
Mar 18, 2009 at 6:01 PM
The way I see it using multiple extensions is a case on the very edge. What most people will use is either removing it entirely or setting it to .html.

The reason for this not beeing part of the name is to support deeper urls i.e. avoid urls like this: /page1.aspx/page2.aspx (the offending aspx in bold)

Sorry for the abstractions. I can't exclude it has gone too far. Part of the reason is an unexplicable urge to support scenarios like yours =)

I can't really see why you can't get this to work though. The situation is a bit similar to the file system where there are files with varying extensions. If you examine it you might find some clue that helps you.
Mar 18, 2009 at 7:25 PM
The way I see it using multiple extensions is a case on the very edge

Only for new sites. What about the millions of existing sites? N2 has been rendered unable to produce many exceptionally common URL structures.

> Sorry for the abstractions. I can't exclude it has gone too far. Part of the reason is an unexplicable urge to support scenarios like yours =)

It's one of the things that attracted us to N2. Of course, it can be a love/hate relationship... we love it when it works because the result is so elegant, but we hate it when it doesn't work because we cannot figure out what the heck is going on! :-)

> The reason for this not beeing part of the name is to support deeper urls i.e. avoid urls like this: /page1.aspx/page2.aspx (the offending aspx in bold)

Actually, I see that as another defeciency with the extension concept. The default structure of a site in N2 is very awkward... If both URLs /page1.aspx and /page1/page2.aspx then one would expect /page1/ to work also, but it does not. Not only that, there is no way (when using a non blank extension) to make it work. Hence the very practical need to have more flexible extensions.

> I can't really see why you can't get this to work though.

Neither can we :-(

All I can say is that it used to work, and we feel that the way it used to work is superior because it gave us more flexibility. Is there anything we can do to convince you to restore the old behavior? We do not know how. What would be lost if this functionality were re-added?
Coordinator
Mar 18, 2009 at 9:57 PM
Hi again, I spent some time trying to figure out what's going on on your end with no real success. I'll post some findings.

Since the new url parser strips the extension before asking the start node to resolve the path I had to change the way name equality is compared:

        public override string Extension
        {
            get
            {
                int index = Name.LastIndexOf('.');
                if (index > 0)
                    return "";
                return base.Extension;
            }
        }

        protected override bool Equals(string name)
        {
            int index = Name.LastIndexOf('.');
            if (index > 0)
                return name.Equals(Name.Substring(0, index), StringComparison.InvariantCultureIgnoreCase);
            return base.Equals(name);
        }

I added these extensions to the observed extensions (.aspx is required for the start page to work)
      <web extension="" observedExtensions=".html,.aspx" />

Hope this helps someone.