Add route and ascent count to ancestor array on all pages + crag index

[brendanheywood]

So I can add the same hover title to items in the crumb trail.

[brendanheywood]

It probably makes the most sense to also add the crag index data into the ancestors data array as their is a big cross over already.

eg so if I am in Crack boulder and my ancestors are:

World > Aus > NSW > New England > Gara Gorge > Western Areas > Crack Boulders

So the nearest crag is Gara Gorge. If there is a crag which contains crags like Araps, the smallest closest crag should be used, like Somerday Valley instead of Grampians.

Under this area node should be a nested recursive structure of children with just the bare bones data:

id, name, subType, routes, ascents,

Maybe the node that has all this extra data should have a flag so it's clear which crag in the heirarchy to use, eg hasIndex => 1

[scd]

What about getting crag index information as an ajax call. There is certainly scope for having bare bones index information via ajax. I think we would get use of this in many areas.

[brendanheywood]

Yes that would be fine except if an area is deeply nested it would be much more efficient to grab it all in the one call. If an area had say 5 children for each node and 3 teirs deep then that is 125 ajax calls and I have to wait for the first ones to return to know what ones to call again, and progressively build up the menu as I get the data.

I definitely would like a bare bones summary ajax call for some other use cases but this one should just be done up front.

Later I'd like dynamic on demand menus for each crumb trail nodes which will be perfectly suited to the small ajax call.

Do you have a better place for the data to appear in the api instead of the ancestors? It could just be item called cragIndex => {...} if you want

[scd]

I'll get onto this, maybe monday, because it seems as though this is something you are working on now.

I could provide the ajax call with a parameter for getting the full nesting.

There are a couple of performance issues to consider. What happens at Grampians if we have not got the crag identification structure quite right and say their is an non-Crag designation directly under Grampians (for example somebody adds a generic area to Grampians). In that case the system will try and get 10000 nested nodes. Do we really want to be passing 10,000 nodes through the api?

[brendanheywood]

It's not super urgent, I'm just kinda cleaning up loose ends as I find them. What I'd like instead is make a time on monday or whenever and jump into wave and chat through the outstanding PDF issues and get me up to speed to a point where I can finish it off ready for the initial release.

[scd]

I'm around monday, send me an email to remind me to go onto google wave.

Also before I start with a solution for this issue we need to work out what to do when the heirachy is large - say more than 500 nodes. I think it would not be practical to be sending large heirachies through every api call. I'm ok with doing it through ajax calls, because we only send when we need it.

[brendanheywood]

Ok so we can just a limit which I reckon should be the same limit as the crag guides.

suggested url:

/area/12345/summaryJson - gives all immediate children

{ id: ... name: route count + ascent count }

/area/12345/summaryJson?descendants =true - gives all recursive children up to a limit of X

{ ... same as above children: [ {
.... } ] }

When I render a route or area page, I will walk up the ancestor list until I either get to a node that has more than X children and then choose the last ancestor in the walk, OR I find a crag node. In order to this I'll need the ascent count + route count added to that array which is what this issue was originally about.

Then I'll make a jsonp call to get the largest but most practical index to turn into a menu.

Also you accidentally closed the issue

[scd]

Woops that's the big comment and close button.

On 4/06/2011 9:26 AM, brendanheywood wrote:

Ok so we can just a limit which I reckon should be the same limit as the crag guides.

suggested url:

/area/12345/summaryJson - gives all immediate children

{ id: ... name: route count + ascent count }

/area/12345/summaryJson? - gives all recursive children up to a limit of X

{ ... same as above children: [ { .... } ] }

When I render a route or area page, I will walk up the ancestor list until I either get to a node that has more than X children and then choose the last ancestor in the walk, OR I find a crag node. In order to this I'll need the ascent count + route count added to that array which is what this issue was originally about.

Then I'll make a jsonp call to get the largest but most practical index to turn into a menu.

Also you accidentally closed the issue

http://thecrag.com/

[brendanheywood]

Oh and also I need to know X - I guess that will be a static perl var somewhere?

[brendanheywood]

Sorted with api long ago.