Brian Gernhardt wrote: > On Jun 13, 2007, at 11:27 PM, Oliver Baltzer wrote: > >> I think it should. I don't see why not. > > Flat out simplicity. The AliasPage just has a find_by_url that > returns the other page. And since a page can have child pages, if I > didn't just re-route the request I'd either have to have an alias for > each subchild (ugly) or do some complicated trickery involving > creating Page objects on the fly that don't actually exist in the > database (which I don't like, but can do if it becomes necessary).
I see how this works now. It's clever, but I don't agree with that choice. I think an AliasPage should be a separate entity and its attributes, i.e. #url, should be consistent with how you access it. But that's just me. >>> And I think that redirect is broken for any >>> site that has multiple ways to access the same page. >> There is no reason for accessing the _same_ page via multiple ways. >> That's just bad design. Compared to a Unix file system, there are >> directory entries and there is data. Two directory entries may point >> to the same data, but still are distinct directory entires. Asking >> either of them for their path will return two different paths. > > Hard Links. Symbolic Links. Used all the time in Unix to have the > same file in multiple places. And, AFAIK, you can't ask "where is > this file" once you've opened it. True, but you _can_ ask a page where it is. Assume I am asking an AliasPage for its path, you say it is alright to return a different path than the one I used to find the page. > My use of it is to have the same CSS file(s) across multiple sites. > But I could see an extension that publishes an address book with URLs > like /addresses/<group>/<person>. If a person is in multiple groups, > should I have to update multiple pages when their contact information > changes? No, I think an AliasPage is a good extensions and I understand your reasons for it. I don't agree with those reasons, but that again is just me. I just don't think the AliasPage should not even be aware of its own existence when accessed. > What if we added authorization so that not everyone can see > every group? How do we handle your redirect now? I don't know what you mean by that. If you are asking whether I think if an AliasPage should delegate authorization to the target page, then the answer is yes. In fact, I would have the AliasPage inherit the authorization rules from the target page and provide the option to overwrite/augment them. >>> And it sucks from a performance point of view as we have to do >>> find_by_url twice >>> for the page twice before displaying it. >> Only if it actually needs to be redirected. Apache does not seem to >> have a problem to stat a directory twice for the same reason. >> Redirects should be fairly infrequent if the web-author is paying >> attention. > > find_by_url is one of the biggest time issues in Radiant, as far as I > can tell. Avoiding it would be useful. I agree, but as mentioned before, duplicates occur rarely and only if the "wrong" URL was used to begin with. Instead of redirecting we could just produce a 404. < And I don't see what > redirecting to the "one true URL" would help. A site-wide setting > for "add a trailing slash" or "remove a trailing slash" (possibly > with don't add slashes if there's an extension on the URL), it would > be faster and solve the original problem without adding additional > cost or complication. Also mentioned before, an extension is not a sufficient criteria to decide whether something should have a trailing slash or not. If it would, what extensions would you choose? Or do you treat everything after the last dot as an extensions, thus limiting your choice of slug? Only allowing up to 4 characters as extension? Cheers, Oliver _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
