forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: skinconf.xml , single configuration point?
Date Fri, 22 Nov 2002 01:17:35 GMT
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> > Nicola Ken Barozzi wrote:
<snip/> 
> > Module.xml also lists credits:
> > 
> > <credits>
> >   <credit>
> >     This software includes software developed by the Krysalis Project
> >     (http://www.krysalis.org/).
> >   </credit>
> >   <credit>
> >     This product includes software developed by CollabNet (http://www.Collab.Net/).
> >   </credit>
> > </credits>
> > 
> > Skinconf lists roughly the same information, but *in a format useful for
> > skins*:
> > 
> > <credits>
> >     <credit>
> >       <name>Built with Cocoon</name>
> >       <url>http://xml.apache.org/cocoon/</url>
> >       <image>images/built-with-cocoon.gif</image>
> >       <width>88</width>
> >       <height>31</height>
> >     </credit>
> >     <credit>
> >       <name>Krysalis Centipede</name>
> >       <url>http://www.krysalis.org/centipede/</url>
> >       <image>images/centipede-logo-small.gif</image>
> >       <width>138</width>
> >       <height>31</height>
> >     </credit>
> > </credits>
> 
> url should be added to module.xml.

Needs to be in both, unless you have some clever way 
of associating elements with the same name "credit" 
from two separate files. 

Anyway, we recently had a proposal to change those 
<credit> elements in skinconf.xml to be a generic 
<logo> element, which makes sense. 

> Width and height should not be there anyway, and not really needed.

They are most definitely needed. All images should have 
height and width. Surely you have seen a browser wait for 
ever, because it cannot render the table, because it is 
waiting for the image download to calculate the size, 
because the image has enormous volume or is missing ... 
Press the stop button - page displays. They are needed. 

Now if Cocoon had an image generator that could detect 
the image size at build time, then we would be happy. 

> As for the image, it can be in skinconf with a reference to the proper 
> module.xml credit, or be in module.xml itself.
> 
> > So again, unless module.xml is going to be polluted with skin-specific
> > stuff like <image>, <width> and <height>, this info can't be isolated
in
> > module.xml.
I agree. 

> Module.xml DTD is not fixed.
> I have just added, to make automatic announcements, the fullname="" 
> attribute for example.

What DTD? I cannot find it in Forrest. If there was, then we 
would be using it for validation. 

> The fact that some project metadata is not present yet doesn't mean it 
> shouldn't be there.
> 
> Gump makes cool cross-project dependency pages. IMHO it would be cool if 
> they were skinned by Forrest and have the additional project info added.
> 
> >>have a single file that keeps all forrest stuff.
> >>
> >>Example:
> >>
> >> module.xml ( project metadata
> >>             +link to properties
> >>             +link to skinconf)
> >>
> >> **properties.xml  (Ant build properties, non Forrest)
> >> **forrestconf.xml (Ant build properties, Forrest)
> >> **skinconf.xml
> >>
> >>All these three can be in the same file, or all separated, or mixed.

Separate files for each concern sounds good. In XML format 
is good too, because then we can at least partially validate 
the contents. Yes, the names and locations of these separate
files should be defined in a top-level configuration.

> >>For the default layout I'd probably separate them all for build 
> >>simplicity, and this basically recreates the current situation with 
> >>forrest.properties -> forrestconf.xml, but with the differences that the 
> >>locations are all configurable
> > 
> > Location of what, forrestconf.xml?
> 
> Of forrestconf and skinconf.
> 
> >>, no data overlap between files
> > 
> > when almost none existed..
> > 
> >>and the files can be merged.
> > 
> > ..to what gain?
> 
> Have a single properties file.
> One place to look at, one place to manage.

The single file will mix concerns, and will 
become unwieldy and complex. 

> >>Well, this is basically it, I'm too tired now.
> > 
> > +0 to anything that doesn't break backwards-compat.
> 
> Ok, point taken.
> 
> Actually, the proposed mechanism can be made not to break backwards 
> compatibility, and even with the new method, it can be configured to 
> work exactly as the old one.
> 
> I'll fix up the implementation and show you.

Hang on. What "implementation" are you going to "fix"? 
Not Forrest i hope. This configuration issue is not 
yet resolved. 

--David 


Mime
View raw message