Adding attributes to generated TOC links

[JRtechw]

Flare 2019, HTML5 skinless output

We've moved to a paginated nav framework, after our knowledge bases expanded to a point where Top Nav was no longer feasible. Pagination uses a bit of JS to slide div blocks of content in and out, as the user navigates through paginated tabs of topic blurbs.

Not an out of the box solution of course, but it works great, leveraging Flare's TOCs to set up the paginated tabs. However, breadcrumbs don't carry over well. TOC endpoints that point to single articles are fine. But folder-level TOC entries require JS to get the correct tabset loaded, and need a 'handle' to achieve this.

Has anyone found a way to add an attribute or a query string to the link specified in TOC entry > Properties? That is, this field:

FlareTOCLink.GIF

For some bizarre reason, Flare treats a query string in any URL in this field as equivalent to a bookmark, and does two things:

1. Reports the query string as a 'Failed to find bookmark' warning in the build log.
2. Strips the query component from the href when it builds the bookmark <a>.

The query string is harmless, so I've no idea why it would be stripped out when the bookmark link is built.

The best way of adding a handle would be to add a 'data-' attribute. However, if you try adding a URL to this field like so:

Code: Select all

/Content/KB_Home.htm data-target="GetStarted"

The builder will just treat the whole thing as the URL, which is fair enough.

Long shot, but has anyone ever tried inserting an attribute or appending anything to a TOC link like that? If I just wanted to trigger generic behaviour when a TOC element is clicked I can just use a selector, but I want to trigger behaviour based on the value of the TOC entry.

Workaround

A possible workaround would be to have a dummy file filled with dummy anchors to point to, so that Flare happily retains any # or ? component of the URL, but what a palaver. Still, worth a shot.

Thanks.

[Psider]

I think I remember someone successfully edited the fltoc file in a text editor to add...um...something. Perhaps you could try adding a data-target property in that file and see if it survives generation?

[JRtechw]

Hm, I just assumed that any manual edits would be treated the same as if attempted through the GUI, but I'll have a play and see if I can fudge something.

[NorthEast]

Any reason why you can't use #GetStarted, rather than a query?

I think I remember someone successfully edited the fltoc file in a text editor to add...um...something. Perhaps you could try adding a data-target property in that file and see if it survives generation?

You might be thinking of the Style Class setting (which is in the screenshot).
The class you set there will persist to the output - e.g. in a menu, that class is applied to the parent <li> tag that contains the menu link <a> tag.

JRtechw - if you're not using a skin menu or menu proxy, then I'm assuming you're somehow using the TOC data in the output js files? That class is also persisted there too.

[JRtechw]

Using *.htm#xxxx looks like the only way to add 'stuff' at the end of the TOC link in that field, yeah.

The trouble is, you need to point to an actual existing bookmark, otherwise the builder will report a 'bookmark not found' error and happily strip the hash out of the URL when it generates the breadcrumb. You can turn the warning for this off in build settings, but (as far as I can tell) you can't turn this behaviour off when building.

Hence the need for the dummy file full of bookmarks, with show in search results turned off.

We use a little post-build script to create the paginated tabsets from the TOC, so maybe I can just extend this to preserve hash or query info as well.

Then again, one of the benefits of pagination is greatly increased lateral navigability, so maybe I can just live with it.

[In case anyone is wondering what the hell 'pagination' might be, Survey Monkey's help is probably the best example: https://help.surveymonkey.com/categories/Design_Manage