Dont confuse this, marking with <systemHelp> does not
mean you mark a method that returns a string and it
magically appears in the system help.
This pragma is used to mark "help types" that should be
included in the SystemHelp. Classes marked with this
pragma are converted to to a help topic (#asHelpTopic)
and using subtopics for SystemHelp.
This allows to easily "register" own help types like the
WikiStyleHelp. So this pragma is for people WHO WISH TO
EXTEND the help system itself (for new syntaxes, new help
contents sources, ... without patching it).
This pragma is NOT FOR END USERS who want to write help contents.
There is no difference since issue #3511 is integrated since
CustomHelp is the only provider of <systemHelp> so for.
Anything thats changed is the way SystemHelp (which is used
as default in HelpBrowser) queries for its roots.
If you load the WikiStyleHelp you have another provider
of system help.
Your scenario is different:
===========================
- you want to write help contents that should load
in 1.1. and 1.2 and display at least in 1.2
If it is OK for you to have a special help package
with the dependency on the help framework:
=> use a CustomHelp subclass since this is supported in
1.1. and 1.2 (loads and displays in both)
If this (dependency) is a "no-go" then describe it using
the <wikiStyle> pragma
=> it is loadable in both, but not displayed in both
=> it will only appear in 1.2 if we either integrate
"WikiStyleHelp" into core or dev image or you load
the wiki style help extension it with your soup config
Thats why I would like to see Alains idea pushed into 1.2.
(either as part of Help system in 1.2-core or as an help
extension package in 1.2-dev).
Bye
T.
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren:
http://portal.gmx.net/de/go/demail
Locked
