Bug 369427

Comment 1 Susan McCourt 2012-01-23 12:42:07 EST

(In reply to comment #0)

> - our html pages currently assume a dojo BorderContainer as the layout manager
> for the page.  This also means a fixed header and footer are assumed.  If we
> want to allow the most flexibility, we need to separate the layout so that
> someone reskinning Orion could make different choices (for example, a fluid
> header that is not pinned to the bottom?)

Libing and Anton did some work in bug 369425 to create the border container dynamically.  We should do something similar for the banner/header layout.  For example, something in globalCommands could make the decision about what layout is appropriate for the banner/header HTML fragments.  As an example:  if progress is in the footer, you likely want a fixed footer.  But if someone moved the progress elsewhere, you might not want a border container (or at least not the footer in the top region).

To truly get total reskinning we'd need the "reskinning plugin" to be able to describe the locations of the various header/footer elements that are currently in a fragment.

Comment 2 libing wang 2012-01-23 13:06:13 EST

(In reply to comment #1)

> Libing and Anton did some work in bug 369425 to create the border container
> dynamically.  We should do something similar for the banner/header layout.  For
> example, something in globalCommands could make the decision about what layout
> is appropriate for the banner/header HTML fragments.  

Before I talked to Anton today, the compare widget had to assumes a dojo BorderContainer  as the parent. 
Now by the fix of bug 369425, the assumption is no longer needed. 
I put a snippet in bug 369425. We can make it better and a util to use generically.

Comment 3 Susan McCourt 2012-01-23 13:25:49 EST

(In reply to comment #0)
> - our html pages currently assume a dojo BorderContainer as the layout manager
> for the page.  This also means a fixed header and footer are assumed.  If we
> want to allow the most flexibility, we need to separate the layout so that
> someone reskinning Orion could make different choices (for example, a fluid
> header that is not pinned to the bottom?)

sigh.  I am saying header when I mean footer, and bottom when I mean top.  Sorry to anyone trying to follow this.  What I am trying to say:

We currently assume a fixed header and footer and thus use BorderContainer in the html to achieve this.  The work that Libing/Anton did takes this assumption out of the HTML and injects it into the html later.

BUT...to get true flexibility, we want to move such decision-making into a place that could be overridden by other CSS.  Imagine someone who wants a fixed header and fluid footer.  They wouldn't want the Bordercontainer to assign the footer to the bottom part of the container (and may not want a border container at all).

>To truly get total reskinning we'd need the "reskinning plugin" to be able to
>describe the locations of the various header/footer elements that are currently
>in a fragment.

and to use CSS to control the layout.

Comment 4 Susan McCourt 2012-05-24 13:18:19 EDT

(In reply to comment #3)

> BUT...to get true flexibility, we want to move such decision-making into a
> place that could be overridden by other CSS.  Imagine someone who wants a fixed
> header and fluid footer.  They wouldn't want the Bordercontainer to assign the
> footer to the bottom part of the container (and may not want a border container
> at all).

I wrote bug 380565 for this, this is really turning into a broad tracking bug for all that we would need to do.

Comment 5 John Arthorne 2015-05-05 14:49:29 EDT

Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see:

https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html