I think Brendan and I have discussed this issue already. Basically the first cut of FU works only for dmNavigation objects. This makes sense as they are the only thing that knows where they sit in the scheme of things using a single lookup.

I suspect that direct calls for dmHTML, because it always is associated with dmNavigation, could be made to always have appropriate FU's (except when in a multi page feature aspect).

Other content types (eg news, events, custom types) need some kind of location. We were thinking perhaps, /go/typename/objecttitle but I'm not sure this has been fully implemented.

Brendan may be able to add more on this.

-- geoff
http://www.daemon.com.au/

Tom Cornilliac wrote:
I just noticed that FU only creates mappings for type dmNavigation. This
creates a bit of a problem when using the handpicked rule. Lets say I setup
a handpicked ruled that includes a selection of dmHTML objects. In my
displayTeaser template I make a call to <skin:buildlink> to format my FU
links. Uh Oh...No mappings for dmHTML types. What I end up with is a mix of
FU links and not so FU links on the same pages. Kinda defeats the purpose a
bit.

This is obviously not a big deal, but one I think we should address. What
are the possible solutions?

Here's my thinking so far:
Fu.createAll() is using Tree.getDescendants() and Tree.getAncestors() for
tree data. The problem with using Tree.getDescendants() is that it only gets
objects of the same type as the supplied object (currently
application.navid.home). Initially I thought supplying a clever filter would
do the trick but the more I think about it the more it seems like a cheap
hack. I'm thinking maybe we should modify Tree.getDescendants to include a
type filter. By default it would continue to use the type of the supplied
object but with an optional argument for an array of types to pull.

Thoughts on this?

~Tom




---
You are currently subscribed to farcry-dev as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

Reply via email to