Hi *,

On Sun, Jan 23, 2005 at 01:19:59PM -0800, Louis Suarez-Potts wrote:
> >On Thu, Jan 20, 2005 at 11:41:25AM -0800, Louis Suarez-Potts wrote:
> >>>It can be done. See my other post and prove of concept:
> >>>http://de.openoffice.org/testdir/zuwendungen.html
> >> 
> >> I see. I just asked the CollabNet people if the homepage obeys
> >> different laws.
> >
> >I doubt that - It uses exactly the same structure as the rest. So if
> >you can modify the CSS (or include other CSS to overwrite the
> >defaults) - this approach will work. This is only a CSS trick that
> >overrides the default definitions. Nothing that the server or SC can
> >interfere with..
> 
> The homepage is indeed treated differently; in fact, we are supposed to
> be using "DomainHome.html.html", not index.html; and the left navbar
> elements are specifically different for the homepage than for other
> project pages. The WWW project is unique.  

What the contents of the page is doesn't matter as long as the things
that are laid out use the same structure.

Both the main site as the project websites are layout as follows:

<header with SC stuff and things merged from the file in CVS>
<body>
<div with banner>
<div with tabs>
<table>
<table row width 20> | <table row width 80%>
<div "navcolumn"     | <div with body, as defined in CVS>
</table>
<div with footer>
</bod>
</html>

The table row with width 20% is hidden using css.
What the content of the left table-row is doesn't matter.

No matter what the page is called either. The only thing needed is to
use stylesheets. This is possible as the CVS source for these pages
demonstrate.

> But that does not mean that we cannot get around it or are required to
> use the default structure.  We use now, for instance,
> www/www/index.html, not the DomainHome.html.html because that latter
> page cannot be staticized, whereas the index.html page can be.  

But this has nothing to do with the contents of these pages. Both
contain the same.things. Nothing special about either page.
This must be a limitation of SourceCast itself.

But again: Using the CSS-trick has no influence on the ability to
staticize a page or not.

(If you could not staticize pages with custom stylesheets, you weren't
able to staticize german-lang pages).

> [snip]
> >> Maybe. I've asked CN about this.  But I would like to make the
> >> homepage less filled with lines, boxes, etc., as Jacqueline pointed
> >> out.  
> >
> >"But"? My testpage doesn't include any more boxes or lines. (You can
> >style the tabs and the footer as well) Getting rid of the default
> >navbar gives you the freedom to design the page as you want it to be.
> 
> Christian, we are agreed on what I think you and I want.  

I just was wandering about your "But" that did not make sense at all to
me.

> >The only drawback is that you have to add your custom navbar to every
> >page that should have it. But there exists tricks to fetch the
> >contents from another file already. See
> >http://marketing.openoffice.org/art/ the right box fetches its
> >contents from another site unsing JavaScript/PHP. John McCreesh posted
> >another possibility some time ago:
> >http://website.openoffice.org/tryouts/jpmcc/iframe.html That one uses
> >iframe. THe only content of the file is <iframe
> >src="http://www.google.com"; width="640px" height="480px"
> >scrolling="auto" frameborder="0"> [You have no frames!] </iframe>
> 
> yes, I rather like that, too.
> >
> >Youls be cool if you could figure out how SC will treat iframes when
> >it comes to statication of the pages.
> >
> Exactly. That, and I don't know how it will work with a really heavy
> load.  Hence, my preference is for something that does not require
> fetching from another server;

Of course, these were only meant as examples.

> from another directory, it should be
> possible, but again, as that is what every page composition does on SC.

No. That is not what SourceCast does.
SourceCast assembles the contents from contents of other pages.
SC delivers the complete pages, whereas the above things still include
links to other pages.
It is the client's browser that fetches the contents from the server.

It could be a problem when the files are fetch from OOo (and not from
another server) and sourcecast processes files other that HTML as well.

Hmm, maybe this is what you're talking about - just getting the point I
think..

But couldn't this be avoided by using "nonav" links?

Question: Are "nonav" links processed via the VM? If not, this could be
the solution to all our problems :-)

Could linking the images using nonav-links solve the performance
problems with the images? (You once asked to move them to a special
directory)

> To be clear: I like simplicity and the idea that we ought not to be
> bound by the left navbar, which is default but not strictly speaking
> necessary.  We would have to ask CollabNet for a one-off to suppress it
> for the homepage and ensure that such a suppression is staticizable and
> robust, but I think that can be done.  

Well if german-lang sites are robust this can be done even without CN
doing that modification (but I'd appreciate it if the trick wouldn't be
necessary :-)

ciao
Christian
-- 
NP: Paradise Lost - Jaded

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to