On Mon, Sep 27, 2010 at 08:47:35AM -0400, Soulliere, Robert wrote: > Thanks Jeremy, This is an excellent approach. > > Jason, could the workflow go something like this: > > 1) DIG determines a static location for the context-sensitive help files for > a specific version of Evergreen. E.g. docs.evergreen-ils.org/2.0/help/ > > 2) DIG generates the html help files using Jeremy's style sheets. > > 3) Developers could link to the appropriate help files as they are writing > the code or add links to the existing code. > > Would that work? >
While pointing at docs.evergreen-ils.org will be useful during development, we'll probably want to point to a local copy of the help in the actual implementation, right? This would allow for local modifications & avoid possible exploits if Somebody Evil(TM) were to gain access to docs.evergreen-ils.org and inject their own executable content into the help. To avoid having to modify every staff client help file, right now we're talking about ~125 XUL files and ~125 TT2 files. Is there any possibility of defining all of the mappings in a single file - would including an array of 250 elements in something like g.data.help_map[] be too much bloat? (Implicit assumption: this help mechanism works for TT2 pages). Further, could we then give one or more members of the DIG SVN access to update that file? SVN enables you to limit the scope of commits to a single directory or file, and I don't seen much point in adding a layer of developer involvement if this self-contained. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
