On Sat, Aug 21, 2010 at 1:33 PM, Wes Gamble <we...@att.net> wrote:
> On 8/20/10 5:04 PM, Wes Gamble wrote:
> On 8/20/10 3:04 PM, Wes Gamble wrote:
> All,
> I have a page X, which has several children pages underneath it (say, 10).
> Is there any relatively easy way to derive the index of a given child of X
> in the list of children of X?  So, for example, for the 3rd child, I need to
> be able to get a 3 somehow in order to construct links.
> I'm displaying children using <r:pagination> and I'm generating direct links
> to the children.  I'd like these direct links to reflect the pagination
> within the context of the parent.
> So, for example, I want a link to the 3rd page of X that looks just like the
> link I get from paginating X, which is: /x/?page=3
> I tried just forcing the slugs to be these types of links, but get a bad
> format error when I try to save the page.
> This doesn't seem like it would be that hard to add a tag that derives a
> child's location within it's set of siblings underneath a parent, if I had
> to.
> Many thanks,
> Wes
> I've created a custom tag named "child_position" for this, and I'm very
> close to getting it working.  Here's the tag definition - this is, of
> course, executed within the context of a <r:children:each> tag:
> tag "child_position" do |tag|
>    if parent = tag.locals.page.parent
>       parent.children.index(tag.locals.page)
>    end
> end
> but nothing gets output.  I've verified that the parent object is a page,
> that it has children, and that tag.locals.page is a page.
> What am I doing wrong?
> Thanks,
> Wes
> My bad - this works fine.  There is some caching going on in my development
> platform, either from Firefox (notorious for it, I know) and/or Radiant.  I
> refreshed my page this morning and I see that this is working.
> Awesome.  Integrating new Radiant tags seems really straightforward.  I'll
> fork the base and send a pull request to include <r:child_position/> as a
> core tag.
> W

I'm glad it's working for you. Before you send a pull request for a
new feature like that, you should get some feedback from this list
about whether or not it would be a valuable addition to the core.

Right off the bat, I'd argue that child_positon is not a good name for
the tag. I would assume from the name that it has to do with the
"position" column added by something like the reorder extension.

Inside our standard tags we loop through the list with an index

I think a better approach would be to add something like
"children:each:index". But I'm not currently convinced this needs to
be in the core.
I'd love to hear other opinions on this.


Jim Gay
Saturn Flyer LLC

Reply via email to