[Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs

[Harald Meland]

[Barry A. Warsaw]

> >>>>> "HM" == Harald Meland <Harald.Meland@usit.uio.no> writes:
> 
>     HM> Like, in a separate frame, maybe?  That's what I've been
>     HM> thinking, anyway...
> 
>     HM> However, the frame-full UI should be optional.  For a
>     HM> frame-less UI, I agree with Ken.
> 
> Harald, I hope you're not advocating using HTML <frame>s!  I
> absolutely detest those things :).  I think we can get all the
> benefits of frames without the headaches by using an arrangement
> similar to www.python.org and www.jpython.org (and not-coincidentally
> www.python.org/~bwarsaw :)

I suspect that I'm not understanding the issues involved clearly
enough to be advocation one or the other construct.  However, mere
suspicion of lack of understanding have never stopped me from putting
my foot in my mouth before :)

Here are some of possible uses I have been thinking about for HTML
<frame>s in Mailman:

 * Implementing a admin-interface sidebar with links to the various
   admin pages

 * Viewing list option documentation in the same browser window as the
   admin interface

 * Keeping buttons like "submit changes" fixed in one window position
   while scrolling through all the settings in another frame (although
   this might very well be undoable due to the SUBMIT input being in
   another document than where the POST form is...)

The sidebar stuff could be done with an arrangement like Barry
suggests, even though then the entire page would have to be
re-rendered when a new page is loaded, and the sidebar would scroll
along with the rest of the page.

Adding an option documentation row to the full-page table would only
work properly if the entire page fits inside one windowful -- and
would probably be messy even then.  On the other hand, maybe the
current approach of always showing option documentation in a separate
window is the way to go.

Having fixed-position buttons is not really that important, I think :)
-- 
Harald