Re: [platform-help-dev] embedded help for web applications for InfoCente

[birsan@xxxxxxxxxx]

> Hmmm.  Would that be an approved hack?  Somehow, it would seem like less
of
> an abuse of the context infopops if the description were optional when
the
> context id mapped to a single topic, as in:
>    <!ELEMENT context ((description, topic*)|topic) >

I think we have mistakenly made the description mandatory. It should be
optional, as in

<!ELEMENT context (description?, topic*) >

You can call it a hack, but I think it is really context-sensitive help
that you're doing, the trigger mechanism being the only difference from a
standard F1 invocation.

> Anyway, let me step through it carefully:

> *  The help author would maintain the mapping (with or without the empty
> description) between the context ID and topic path in context.xml

Yes

> *  The application requests the context ID from our extension web
> application.

Yes

> *  Our extension web application sets the plugin scope (in whatever way
> that's done), executes ContentUtil.loadLinks("contextID"), gets the
single
> topic node, and includes its path to provide the HTML content to the
> browser.

One slight change: I would expect that you call a help API that returns you
the XML fragment corresponding to you context. You would then decide what
to do with it. In particular, you would probably stream out the content of
the first link (create the URL object for that topic and get its content).

> The only issue I see right now is that it would be good to get the
browser
> to recognize the identify of the page (for caching if nothing else)
whether
> requested by context ID or by path.  Maybe there's an HTTP header for
> that...

Perhaps the browser associates the content of that topic with the URL
(including its query parameters) that you use to load the topic, so caching
happens by default.


-Dorian