librelist archives

home // archives //

« back to archive

Pointing to category listings

Pointing to category listings

From:
James Abbott
Date:
2011-03-24 @ 16:05 
Hi -

Is it possible to create links (in menu.txt for example) that are links to
categories, and not Markdown files? So that if I have a category "/foo"
under /content/pages, then linking to "mysite/foo" would generate a list of
all articles contained under /foo?

(I mean is it possible out-of-the box, not via monkeypatching).

It seems like Nesta expects the end points of URLs to be only files. So this
URL:

http://nestacms.com/docs

actually points to a file with the path of "/content/pages/docs", isn't that
right?

Cheers,
James

Re: [nesta] Pointing to category listings

From:
Graham Ashton
Date:
2011-03-28 @ 08:08 
On 24 Mar 2011, at 16:05, James Abbott wrote:

> Is it possible to create links (in menu.txt for example) that are links 
to categories, and not Markdown files?

"Categories" in Nesta are "category pages", so implicitly require a 
markdown/textile/haml file.

> So that if I have a category "/foo" under /content/pages, then linking 
to "mysite/foo" would generate a list of all articles contained under 
/foo? 

Unless I've misunderstood the question, this is how it actually works. 
Perhaps I've misunderstood the question?

> It seems like Nesta expects the end points of URLs to be only files. So 
this URL:
> 
> http://nestacms.com/docs
> 
> actually points to a file with the path of "/content/pages/docs", isn't 
that right?

It can either be served from a file called:

  content/pages/docs.{mdown,textile,haml}

or from a file called:

  content/pages/docs/index.{mdown,textile,haml}

Graham

Re: [nesta] Pointing to category listings

From:
Hersh Bhasin
Date:
2011-03-29 @ 15:52 
It is strange that ben-the-bodyguard page  at 
http://jamesabbottdd.heroku.com/awesomeness/ben-the-bodyguard
is not showing the "Published Under" link, which it should if the catagory
is specified. 
 
Does this appear at the top of the ben-the-bodyguard page?
Categories: awesomeness
 
Maybe a misspelling in the category metadata ?
 
Thanks
Hersh

--- On Tue, 3/29/11, Graham Ashton <graham@effectif.com> wrote:


From: Graham Ashton <graham@effectif.com>
Subject: Re: [nesta] Pointing to category listings
To: nesta@librelist.com
Date: Tuesday, March 29, 2011, 9:30 AM


On 29 Mar 2011, at 14:22, James Abbott wrote:

> The child article has the right value in the "categories" metadata. I 
still don't see a listing of the child pages:
> 
> http://jamesabbottdd.heroku.com/awesomeness

Something must be wrong somewhere. I think your metadata should look like 
this (on the pages that should be listed on /awesomeness):

  Categories: awesomeness

If that's what you've got, and it isn't working, can you get on the IRC 
channel? I"ll be on for another hour or so...

Re: [nesta] Pointing to category listings

From:
Graham Ashton
Date:
2011-03-29 @ 16:02 
On 29 Mar 2011, at 16:52, Hersh Bhasin wrote:

> Does this appear at the top of the ben-the-bodyguard page?
> Categories: awesomeness

James sent me his content directory earlier.

There was a blank line between the Date and Categories meta data, so Nesta
was ignoring the Categories line (a blank line signifies the end of the 
metadata).

Re: [nesta] Pointing to category listings

From:
James Abbott
Date:
2011-03-30 @ 11:49 
Yes. I had understood the "no blank lines in metadata fields" to refer to
this:

Categories:

awesomeness

rather than contiguous lines of metadata. The index page is working now -
props to Graham.

On Tue, Mar 29, 2011 at 6:02 PM, Graham Ashton <graham@effectif.com> wrote:

> On 29 Mar 2011, at 16:52, Hersh Bhasin wrote:
>
> > Does this appear at the top of the ben-the-bodyguard page?
> > Categories: awesomeness
>
> James sent me his content directory earlier.
>
> There was a blank line between the Date and Categories meta data, so Nesta
> was ignoring the Categories line (a blank line signifies the end of the
> metadata).
>

Re: [nesta] Pointing to category listings

From:
James Abbott
Date:
2011-03-29 @ 10:52 
Hi Graham,

thanks for getting back to me with this.

> So that if I have a category "/foo" under /content/pages, then linking to
> "mysite/foo" would generate a list of all articles contained under /foo?
>
> Unless I've misunderstood the question, this is how it actually works.
> Perhaps I've misunderstood the question?
>

OK, here's an example: I have a category named "awesomeness" and under that,
a single blog entry (
http://jamesabbottdd.heroku.com/awesomeness/ben-the-bodyguard).

But, here's what happens when the category URL is accessed:
http://jamesabbottdd.heroku.com/awesomeness

Also, in my menu.txt I have:

services
> awesomeness/ben-the-bodyguard
> awesomeness
>

The first two paths point to files, so are working fine. But nothing is
generated from the last one - it's as if Nesta doesn't acknowledge that this
is a path as well, albeit to a directory.

I've also tried this in the sidebar:
- display_menu(Nesta::Menu.for_path('/awesomeness'), :class => "menu",
:levels => 3)

Which resulted in an error.

I had thought that I could create a text file - a "category page" - with the
same name as the category name, and there list the category contents (as you
have done here: http://nestacms.com/docs/). But then I'd have update each
category page manually every time I write a new article under it.

So I guess what I'm looking for is a programmatic way to get a list of
categories in which each entry would itself be a list of contained files (or
subcategories).

Cheers,
James


On Mon, Mar 28, 2011 at 10:08 AM, Graham Ashton <graham@effectif.com> wrote:

> On 24 Mar 2011, at 16:05, James Abbott wrote:
>
> > Is it possible to create links (in menu.txt for example) that are links
> to categories, and not Markdown files?
>
> "Categories" in Nesta are "category pages", so implicitly require a
> markdown/textile/haml file.
>
> > So that if I have a category "/foo" under /content/pages, then linking to
> "mysite/foo" would generate a list of all articles contained under /foo?
>
> Unless I've misunderstood the question, this is how it actually works.
> Perhaps I've misunderstood the question?
>
> > It seems like Nesta expects the end points of URLs to be only files. So
> this URL:
> >
> > http://nestacms.com/docs
> >
> > actually points to a file with the path of "/content/pages/docs", isn't
> that right?
>
> It can either be served from a file called:
>
>  content/pages/docs.{mdown,textile,haml}
>
> or from a file called:
>
>  content/pages/docs/index.{mdown,textile,haml}
>
> Graham
>

Re: [nesta] Pointing to category listings

From:
Graham Ashton
Date:
2011-03-29 @ 11:16 
On 29 Mar 2011, at 11:52, James Abbott wrote:

> The first two paths point to files, so are working fine. But nothing is 
generated from the last one - it's as if Nesta doesn't acknowledge that 
this is a path as well, albeit to a directory.

Oh, I see. You're hoping it'll show you the pages in a category, when 
there isn't a page for the category. Wynn asked for something similar.

I understand the desire, but that's not how Nesta works, and there's a 
(good) reason for it.

Every list of links deserves (at least) a well chosen heading and a 
paragraph of introductory copy. Page headings that have been generated 
from tags, such as "Tag: awesomeness" or just "Awesomeness" don't belong 
on good web sites, IMHO.

Putting some thought into how to present your category to the reader is 
good for your site's visitors. It's also good for you, as it increases the
chances that somebody will read your content, and helps search engines 
index your content appropriately. More info on this approach can be found 
by following the links in the third paragraph on the credits page:

http://nestacms.com/credits

> I had thought that I could create a text file - a "category page" - with
the same name as the category name, and there list the category contents 
(as you have done here: http://nestacms.com/docs/). But then I'd have 
update each category page manually every time I write a new article under 
it.

I haven't listed the category contents manually on /docs; that page is 
doing something a little more advanced (with the menu). In fact it's not a
category page at all (there are no pages with "Categories: docs" written 
in their metadata).

Here's the Markdown for a real category page (/docs/deployment):


https://github.com/gma/nestacms.com/raw/master/content/pages/docs/deployment/index.mdown

Note that the two articles in that category are not linked to from that 
page; those links are added automatically, by Nesta.

Does that make more sense?

Re: [nesta] Pointing to category listings

From:
James Abbott
Date:
2011-03-29 @ 12:11 
>
> Note that the two articles in that category are not linked to from that
> page; those links are added automatically, by Nesta.
>
> Does that make more sense?
>

Not really because I haven't seen and understood the code that does this, so
I can't say I understand it.

Every list of links deserves (at least) a well chosen heading and a
> paragraph of introductory copy. Page headings that have been generated from
> tags, such as "Tag: awesomeness" or just "Awesomeness" don't belong on good
> web sites, IMHO.


It's just a case of providing the page author with a sensible default. Your
CMS design is remarkable in a few ways that it follows good, time-tested
Unix conventions. For example, that text files drive functionality and that
URLs follow directory structures.

However, when it comes to the app responding to a directory URL with a
clean, good default, it's as if you step back and say: "Oh, this is too
important a matter to work out-of-the box. Authors should really put time
and thought into making category pages reader and SE-friendly".

While it is hard to disagree with the above thought, it is also true (at
least in my case) that it is currently unnecessarily difficult to quickly
and surely create a .txt file that would reflect the site's true information
architecture. By that I mean: if you give it a directory URL, you get a
directory listing back - reflecting the way your content is organized at the
back-end.

So I guess what I'm saying here is that it would be really good to either
have the "directory listing" functionality or a snippet of code that was
generic enough to work by copy&pasting. Then, after one was sure that one
can create menus to anything in Nesta, one could start building these
listings out with semantically good headings, meaningful copy, etc.

Just my 10 cents!

/ James




On Tue, Mar 29, 2011 at 1:16 PM, Graham Ashton <graham@effectif.com> wrote:

> On 29 Mar 2011, at 11:52, James Abbott wrote:
>
> > The first two paths point to files, so are working fine. But nothing is
> generated from the last one - it's as if Nesta doesn't acknowledge that this
> is a path as well, albeit to a directory.
>
> Oh, I see. You're hoping it'll show you the pages in a category, when there
> isn't a page for the category. Wynn asked for something similar.
>
> I understand the desire, but that's not how Nesta works, and there's a
> (good) reason for it.
>
> Every list of links deserves (at least) a well chosen heading and a
> paragraph of introductory copy. Page headings that have been generated from
> tags, such as "Tag: awesomeness" or just "Awesomeness" don't belong on good
> web sites, IMHO.
>
> Putting some thought into how to present your category to the reader is
> good for your site's visitors. It's also good for you, as it increases the
> chances that somebody will read your content, and helps search engines index
> your content appropriately. More info on this approach can be found by
> following the links in the third paragraph on the credits page:
>
> http://nestacms.com/credits
>
> > I had thought that I could create a text file - a "category page" - with
> the same name as the category name, and there list the category contents (as
> you have done here: http://nestacms.com/docs/). But then I'd have update
> each category page manually every time I write a new article under it.
>
> I haven't listed the category contents manually on /docs; that page is
> doing something a little more advanced (with the menu). In fact it's not a
> category page at all (there are no pages with "Categories: docs" written in
> their metadata).
>
> Here's the Markdown for a real category page (/docs/deployment):
>
>
> 
https://github.com/gma/nestacms.com/raw/master/content/pages/docs/deployment/index.mdown
>
> Note that the two articles in that category are not linked to from that
> page; those links are added automatically, by Nesta.
>
> Does that make more sense?
>

Re: [nesta] Pointing to category listings

From:
Graham Ashton
Date:
2011-03-29 @ 13:21 
On 29 Mar 2011, at 13:11, James Abbott wrote:

> It's just a case of providing the page author with a sensible default.

I like sensible defaults, I just don't think we're after the same ones.

I agree with everything Glenn said. It's thinking about information 
architecture that has lead to me not actually wanting to do it.

Also, every page on your site has a corresponding file on disk. I like 
that; it's a nice strong convention.

> Your CMS design is remarkable in a few ways that it follows good, 
time-tested Unix conventions.

Thanks.

> it is also true (at least in my case) that it is currently unnecessarily
difficult to quickly and surely create a .txt file that would reflect the 
site's true information architecture.

Try using some of those Unix conventions! ;-)

$ cd content/pages
$ for dir in $(find . -type d -mindepth 1)
> do
>   [ -e ${dir}.mdown -o -e $dir/index.mdown ] && continue
>   echo "# $(echo $dir | perl -pe 's/\.\/(\w)/\U$1/')" > \
>       $dir/index.mdown
> done

I do like bash.

Re: [nesta] Pointing to category listings

From:
Glenn Gillen
Date:
2011-03-29 @ 12:48 
> However, when it comes to the app responding to a directory URL with a 
clean, good default, it's as if you step back and say: "Oh, this is too 
important a matter to work out-of-the box. Authors should really put time 
and thought into making category pages reader and SE-friendly". 
> 
> While it is hard to disagree with the above thought

I think that comment is telling. Proper information architecture on a site
really is important. Given it is hard to disagree with that thought, I 
find it hard to agree that the emphasis should swing the other way.

> it is also true (at least in my case) that it is currently unnecessarily
difficult to quickly and surely create a .txt file that would reflect the 
site's true information architecture. By that I mean: if you give it a 
directory URL, you get a directory listing back - reflecting the way your 
content is organized at the back-end.

By unnecessarily difficult you mean putting an "index.*" file in the root 
of the directory with a heading in it? So long as the child content has 
the appropriate value in the "categories" metadata you'll get a listing of
all the relevant pages.

> So I guess what I'm saying here is that it would be really good to 
either have the "directory listing" functionality or a snippet of code 
that was generic enough to work by copy&pasting. Then, after one was sure 
that one can create menus to anything in Nesta, one could start building 
these listings out with semantically good headings, meaningful copy, etc.

For your visitors, is this directory listing really a good user experience? 

Such default behaviour typically results in a bunch of sites where where 
people either never get around to re-addressing the default behaviour, and
you're left with meaningless "tag" pages. If there's one thing I've learnt
over the years it's that the "Then... after... one could start building 
with semantically good headings, meaningful copy, etc." is a pipe dream. 
It's either a consideration from the very beginning, or it never becomes a
consideration as there are always other things that seem more important. 
New content, new features, new clients.

A general approach do inferring semantic content is anything but a solved 
problem. And I don't think the burden of having to create an index page, 
insert a heading, and a brief explanatory paragraph is so onerous that it 
should be removed in favour of degrading the user experience for your 
visitors.

Just my £0.10

Glenn

Re: [nesta] Pointing to category listings

From:
James Abbott
Date:
2011-03-29 @ 13:22 
> By unnecessarily difficult you mean putting an "index.*" file in the root
> of the directory with a heading in it? So long as the child content has the
> appropriate value in the "categories" metadata you'll get a listing of all
> the relevant pages.
>

I now have an index.mdown file in root of my directory, with a heading and
an explanatory paragraph. The child article has the right value in the
"categories" metadata. I still don't see a listing of the child pages:

http://jamesabbottdd.heroku.com/awesomeness

For your visitors, is this directory listing really a good user experience?
>

The listing is a good experience for me, the webmaster. It is then up to me
to create a good experience for the end users using good IA and copy. It may
be a pipe dream. I'll let the customer decide.

/ James

On Tue, Mar 29, 2011 at 2:48 PM, Glenn Gillen <glenn@rubypond.com> wrote:

> > However, when it comes to the app responding to a directory URL with a
> clean, good default, it's as if you step back and say: "Oh, this is too
> important a matter to work out-of-the box. Authors should really put time
> and thought into making category pages reader and SE-friendly".
> >
> > While it is hard to disagree with the above thought
>
> I think that comment is telling. Proper information architecture on a site
> really is important. Given it is hard to disagree with that thought, I find
> it hard to agree that the emphasis should swing the other way.
>
> > it is also true (at least in my case) that it is currently unnecessarily
> difficult to quickly and surely create a .txt file that would reflect the
> site's true information architecture. By that I mean: if you give it a
> directory URL, you get a directory listing back - reflecting the way your
> content is organized at the back-end.
>
> By unnecessarily difficult you mean putting an "index.*" file in the root
> of the directory with a heading in it? So long as the child content has the
> appropriate value in the "categories" metadata you'll get a listing of all
> the relevant pages.
>
> > So I guess what I'm saying here is that it would be really good to either
> have the "directory listing" functionality or a snippet of code that was
> generic enough to work by copy&pasting. Then, after one was sure that one
> can create menus to anything in Nesta, one could start building these
> listings out with semantically good headings, meaningful copy, etc.
>
> For your visitors, is this directory listing really a good user experience?
>
> Such default behaviour typically results in a bunch of sites where where
> people either never get around to re-addressing the default behaviour, and
> you're left with meaningless "tag" pages. If there's one thing I've learnt
> over the years it's that the "Then... after... one could start building with
> semantically good headings, meaningful copy, etc." is a pipe dream. It's
> either a consideration from the very beginning, or it never becomes a
> consideration as there are always other things that seem more important. New
> content, new features, new clients.
>
> A general approach do inferring semantic content is anything but a solved
> problem. And I don't think the burden of having to create an index page,
> insert a heading, and a brief explanatory paragraph is so onerous that it
> should be removed in favour of degrading the user experience for your
> visitors.
>
> Just my £0.10
>
> Glenn
>
>
>

Re: [nesta] Pointing to category listings

From:
Graham Ashton
Date:
2011-03-29 @ 13:30 
On 29 Mar 2011, at 14:22, James Abbott wrote:

> The child article has the right value in the "categories" metadata. I 
still don't see a listing of the child pages:
> 
> http://jamesabbottdd.heroku.com/awesomeness

Something must be wrong somewhere. I think your metadata should look like 
this (on the pages that should be listed on /awesomeness):

  Categories: awesomeness

If that's what you've got, and it isn't working, can you get on the IRC 
channel? I"ll be on for another hour or so...

Archives based on code by Armin Ronacher //