On Jun 14, 2007, at 1:58 PM, Oliver Baltzer wrote: > 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.
The AliasPage extension falls into the category of "quick and dirty hack." It works. Nowhere will I claim that it's implementation is perfect. There are improvements that could be made (proxying the desired page and it's children in the way you describe, for example). > 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. It works so far and I don't see a compelling reason why it's not alright. The url attribute should be a canonical way to access the page but I don't see why it has to be the _only_ way, as you suggest. >> 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? What if we added authorization so that not everyone can see >> every group? How do we handle your redirect now? At this point, I am discussing a hypothetical extension, not the AliasPage in particular. This is a simple address book extension, where the tree appears as: /addresses/ (AddressBookPage) /person /person2 /person3 and each person page has two parts: main and groups. The groups part is a list of what groups that person belongs to. The AddressBookPage then gives the following URLs: /addresses/ /addresses/group1/ /addresses/group1/person/ /addresses/group1/person2/ /addresses/group2/ /addresses/group2/person2/ /addresses/group2/person3/ Should we forbid person2 from being accessed from two different URLs? Why? Perhaps there is additional logic in the display that shows slightly different parts based on the group. Or there is an authorization extension that only shows you certain groups. What should person2.url return? Why should we redirect group2/person2 to group1/person2 (or vice versa)? >> 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. I try to produce human-readable (and therefore typeable) URLs. I'd argue that the URL would be mis-typed (regarding trailing slashes) on a regular basis. And producing a 404 is wrong when we should be able to easily correct it. > 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? I don't care. I'm all for adding a trailing slash to each and every page. Or removing it from them all. Or making it based on the page's class or layout. (Although I'm less for that due to the lookups required, but not against.) Actually, thinking about it now I think that the presence or absence of the trailing slash is a matter for the layout, not the page type. After all, a Page can be a HTML or CSS file based on it's layout. It would simply be a boolean field on the layout. But I'm still whole-heartedly against redirecting everything to Page#url. It only seems to add limits without adding functionality. And that's my problem with it. I'm not arguing about it to keep my extension from breaking. I'm arguing against it because I think it's wrong for Radiant to do conceptually. ~~ Brian _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
