Difference between revisions of "Defining New Protocol"
Line 6: | Line 6: | ||
==Steps to Create a New Help Provider == | ==Steps to Create a New Help Provider == | ||
− | === | + | ===Inherit ES_EIS_ENTRY_HELP_PROVIDER=== |
+ | * Create your own help provider which inherits from <e>{ES_EIS_ENTRY_HELP_PROVIDER}</e>. | ||
+ | * Implement `document_protocol' and `document_description'. | ||
+ | Existing sample: | ||
+ | <e> | ||
+ | document_protocol: !STRING_32 | ||
+ | -- Document protocol used by a URI to navigate to the help accessible from the provider. | ||
+ | once | ||
+ | create Result.make_empty | ||
+ | Result.append ("PDF") | ||
+ | end | ||
+ | document_description: !STRING_32 | ||
+ | -- Document short description | ||
+ | once | ||
+ | create Result.make_empty | ||
+ | Result.append ("PDF") | ||
+ | end | ||
+ | </e> | ||
+ | * Redefine `show_help'. `show_help' does all works to analyze the EIS entry node and perform required behaviors accordingly. | ||
+ | ** One can object test against `a_section', and get the instance of <e>{HELP_SECTION_EIS_ENTRY}</e> from which <e>{EIS_ENTRY}</e> is available. In <e>{EIS_ENTRY}</e>, basic attributes such as name, tags, source and so on are available, as well as extended elements that are stored in `others' which maybe needed by the new protocol. | ||
+ | ** In this circumstance, `a_context_id' is always the name of current EIS entry. | ||
+ | ** `format_uris' is available to expand a `source' to support variables described at [[Eiffel Information System#Variables|HERE]]. | ||
+ | ** `launch_uri' is available to launch a URI in a web browser. | ||
+ | ** One needs to implement specific launcher if he wants the source to be opened in specific tools. | ||
===Adding a New Kind of Help Provider=== | ===Adding a New Kind of Help Provider=== |
Revision as of 21:10, 22 July 2008
Contents
General
This article demonstrate the way to extend Eiffel Information System (EIS) within EiffelStudio to support more protocols. To support a new protocol in EiffelStudio, the only thing to do is to provide a new Help Provider.
Steps to Create a New Help Provider
Inherit ES_EIS_ENTRY_HELP_PROVIDER
- Create your own help provider which inherits from
{ES_EIS_ENTRY_HELP_PROVIDER}
. - Implement `document_protocol' and `document_description'.
Existing sample:
document_protocol: !STRING_32 -- Document protocol used by a URI to navigate to the help accessible from the provider. once create Result.make_empty Result.append ("PDF") end document_description: !STRING_32 -- Document short description once create Result.make_empty Result.append ("PDF") end
- Redefine `show_help'. `show_help' does all works to analyze the EIS entry node and perform required behaviors accordingly.
- One can object test against `a_section', and get the instance of
{HELP_SECTION_EIS_ENTRY}
from which{EIS_ENTRY}
is available. In{EIS_ENTRY}
, basic attributes such as name, tags, source and so on are available, as well as extended elements that are stored in `others' which maybe needed by the new protocol. - In this circumstance, `a_context_id' is always the name of current EIS entry.
- `format_uris' is available to expand a `source' to support variables described at HERE.
- `launch_uri' is available to launch a URI in a web browser.
- One needs to implement specific launcher if he wants the source to be opened in specific tools.
- One can object test against `a_section', and get the instance of
Adding a New Kind of Help Provider
All known kinds of help providers should be written in class {HELP_PROVIDER_KINDS}
.
An instance of {UUID}
and a string of that uuid are needed in the class.
Existing example:
... frozen pdf: !UUID -- PDF help system once create Result.make_from_string (pdf_uuid_string) end ... pdf_uuid_string: !STRING_8 = "BA35A9BB-5B69-4BD3-88B3-FB8DAE5CA08E" ...
Registering Help Provider
Doing this to make the system really take the new protocol into account.
Added a line at {ES_SERVICE_INITIALIZER}.register_help_provider
This is an existing example:
a_service.register_provider (l_kinds.pdf, {PDF_HELP_PROVIDER})