Hi Ned,
I'd go about it like this:
1.a) Have your index page as the menu with simple anchors pointing to
your docs.
1.b) Have the documents as plain html files which view OK without GWT
(i.e. with css in there).
This will give you your non-JS/Search engine setup.
3) Have your GWT app use a HorizontalSplitPanel to allow resizing
between the menu (LH side) and the content (RH side).
4) Have your GWT app pick up all the anchors in the index page and
convert them to clickable labels in the LH panel then wipe out that div (or
have it hidden, the SEs and non-JS people will still see them) .
5) When you click a label, fetch the html page via RPC or RequestBuilder
and on return populate the content panel (RH side), removing whatever is
currently there.
6) Implement history and use Hyperlinks to set the menu to load other
pages.
2) Use a media="print" style sheet to hide the menu panel when printing.
Ian
2008/8/30 Ned Nowotny <[EMAIL PROTECTED]>
>
> I have an application today that includes a basic help document reader
> within it:
>
> http://www.quantmethods.com/Demo/Help/
>
> This is implemented entirely with static HTML and a "frameset"
> document. However, I want to get rid of the "frameset" partly to
> embrace the somewhat overstated need for good web standards hygiene,
> but mostly to simplify printing of the help pages for my users by
> using CSS to suppress the menu when printing. (Of course, the user
> can typically right-click in the help document frame and accomplish
> the same thing, but most of my users will not be familiar with any of
> the mechanisms for printing just the help document.)
>
> I also want my help document maintainers to continue to use the HTML
> editor of their choice (within some limits) to edit the documents and
> I want the menu and pages to be accessible to search engine indexing.
> To do this, I need the menu and the help pages to remain static HTML.
> With JavaScript disabled or unavailable, the reader should first view
> the menu document and then follow the links as necessary to each help
> document. They can then use the back button or equivalent mechanism
> to return to the menu. With JavaScript enabled, they should get a two
> panel reader similar to the current "frameset" implementation.
>
> One additional complication is that new development now involves two
> applications with overlapping functionality. This means two help
> menus with a number of common entries as well as a few unique entries
> in both.
>
> Now, this all seems pretty straight-forward and Ian Bambury (http://
> examples.roughian.com/) has implemented something very close to what I
> need, but not quite. So, I would appreciate suggestions on how to do
> the following or something that will accomplish the same goals:
>
> 1. Maintain the menu and help documents as static HTML.
> 2. Use CSS to style the pages and to suppress printing of the
> menu.
> 3. Enable resizing of the menu panel (or just hide it).
> 4. Use the help menu documents as the "index" or "start" page for
> the reader.
> 5. Handle help menu events to load the appropriate help document.
> 6. Enable links within help documents to load other help
> documents.
>
> Something like the Google "docreader" would provide the kind of user
> interface I would like to have.
>
> I realize this seems very simple, but I have been spinning my wheels
> on it for a while now and would appreciate help in getting some
> traction.
>
> >
>
--
Ian
http://examples.roughian.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
