forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <>
Subject RE: [jira] Commented: (FOR-639) define terminology for the various aspects of Dispatcher
Date Fri, 14 Apr 2006 12:41:24 GMT

> -----Original Message-----
> From: David Crossley []
> Sent: Friday, 14 April 2006 8:45 AM
> To:
> Subject: Re: [jira] Commented: (FOR-639) define terminology for the
> various aspects of Dispatcher
> Gav.... wrote:
> > > From: David Crossley (JIRA) []
> > >
> > > There were validation problems with glossary.xml file. These issues
> were
> > > noted as Todo items in the glossary plugin's status.xml file. I made a
> > > quick workaround to the glosarry DTD (see svn r393691) to enable
> multiple
> > > "see" and "definition" elements. Don't know if the xml needs better
> > > structure, e.g. <definitions><definition><definition>
> >
> > Up to you, I don't see that it matters, now that <definition> can be
> > declared multiple times as a child of item, that is fine. I guess there
> is
> > going to be more often than not, more than one definition of an item.
> >
> > For clarity, and to match what you have done with notes, we can add a
> parent
> > <definitions> .
> Not up to me. If someone wants changes then they
> can provide a patch. I was just stating that i
> was taking the easy way out.

Ok, but you called it a 'workaround' meaning to me at least that you thought
it a temporary fix and you maybe were not altogether happy with it. I'll add
the parent <definitions> then.

> I could not commit your patch until i had fixed the
> validation errors. It broke site-author generation.

Sorry about that, I swear I thought I validated it before-hand.

> We need to improve the glossary sample in the plugin
> so that it triggers all possible validation errors.

Ok, will take a look.

> > > Regarding the patch for  glossary-to-document.xsl ... Wouldn't it be
> > > better to use CSS rather than td@width? Anyway we should address that
> as a
> > > separate general issue.
> >
> > Yes I can do that, where would the glossary.css file o, in the
> /stylesheets/
> > directory ?
> Please look to the FAQ for common questions.
> => Find in page: css
> I have not tried it with plugins.

Me neither, and no other plugin has a .css file except those
That refer to skins and those that refer to themes. This being
A plugin I wasn't sure about making it version specific hence
The question. (I have another question regarding this I'll get
To in a minute)
> Remember that we don't know all the answers.
> We just explore first, then ask questions.

I did and I did. I did not want to stick it in the wrong place
And then create extra work for a committer to have to move it
Again. One day I'll send a patch that doesn't need touching.

At the end of the day then, one should do what they think is
Right and if others don't agree then they can alter it. I'll
Go with this, but really don't want to have to give others extra
Work, my patches are supposed to save this. It's a balance I'll
Have to practice. Less chatter and more getting on with it is
How I read between the lines above, thats cool.

Getting back to CSS and plugins then, why is it that a lot (but not
All) of plugins have a complete set of skins + css or themes + css ?
Surely the plugin would/should adhere to the styling and layout of the 
Site it belongs to, then add specific css as/if needed?

In the case of all these plugins having copies of common and pelt skins,
Or common and pelt themes, what happens when these are updated or patched
As part of main\webapp or site-author or seed-sample etc etc. I guess they
Become out of sync, and all these plugins need updating to the patched
versions or it all becomes a mess.

Sorry if I missing the obvious as to why all these plugins contain all these
copies of themes and skins.



> -David
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.1/311 - Release Date: 13/04/2006

View raw message