Ooops -- sorry for mentioning the 'D' word... :-) I completely agree with the desire to keep Radiant as simple as possible, and I'm not lobbying anyone to change the way it works. But, if the issue of SEO comes up, I have to agree that the current namespace is not the best for SEO. Is it worth changing? Probably not. Should we all pretend that the hierarchical naming is better? No, we should recognize that it's slightly disadvantageous, but not a huge issue.
> So, if what you want is a site with all the pages in the root, why not > create all the pages in the root? From a practical standpoint, this is > the best Much of Radiant is based upon inheritance of child pages from the parent pages, so sites that use inheritance extensively would not be able to put all the pages in the root. Plus, the folders are great in organizing the content. Once again, it's not a big deal -- just a minor disadvantage. And, as you mentioned, ramping up Radiant's complexity to support every feature would be a disadvantage as well. Jay On 6/12/07, Chris Parrish <[EMAIL PROTECTED]> wrote: > jf wrote: > > I think the original person's point was that a flat namespace allows > > you to design the URL structure that fits your scenario best. So, if > > you want a page to appear to be part of a folder, then you can assign > > it an appropriate slug. If you want child pages to not carry the name > > of a folder in the URL, then you have that option as well. Drupal is > > a good example of a CMS that allows this flexibility. > > >From a practical standpoint... > > If you look at Radiant's style and purpose, the simplicity of use > becomes polluted as we add features like "put this file under this > parent... but don't make it act like it has a parent." Sure to confuse > basic users. > > Then there's maintenance. As I look at my tree how do I know which of > those leaves are imposters? Do I have to open them one-by-one or do I > have some alternate tree (or is it 'lawn') view. > > Finally, there's namespace issues. For instance, in the following: > root > |- A > | |- B > | | |- D > | | |- E > | | |- F > | |- C > | | |- D > | | |- E > | | |- F > |- E > > Which page does http://root/e render? The above is perfectly valid (and > common for some sites). Sure you can add validation rules to prevent > saving a potential conflictingly-named file (similar to rules that exist > for sibling files in a tree) but now you're complicating Radiant's code > for a fringe case. > > So, if what you want is a site with all the pages in the root, why not > create all the pages in the root? From a practical standpoint, this is > the best. You get what you want, and still make it easy for another > person to pick up your project and know exactly what's going on. The UI > does its job of showing them what to expect, how it works, and what to > do to create more of the same. > > > Oh, *whispers* and be careful throwing around names like Drupal. It's > been made very clear that Radiant is not intended to be anything like > Druppppaaaacckkrrrgghhh... *death gargle as writer is dispatched by a > certain (unnamed) creator of Radiant for even putting that CMS in the > same sentence as Radiant* > ;) > > - Chris > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
