forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [jira] Commented: (FOR-639) define terminology for the various aspects of Dispatcher
Date Sat, 15 Apr 2006 00:44:44 GMT
Gav.... wrote:
> > -----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.

Sorry for confusion. I should not have said workaround.
I really meant a quick fix without thinking about it.

My comment about xml structure, was that it sometimes
makes for easier XSLT.

In this case, only change it if you really feel
the need. There is quite some work involved.
It works as-is. The stylesheet handles it.

> > 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.

Happens to all of us. Doing 'forrest site' is
always a good idea.

> > 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.

Not sure what is meant by "version specific".
Such resources should be automatically used if
they are placed in the correct location. See below.

If not, we have a bug.

> (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.

I was hoping to encourage all listeners to look
to the FAQ first. Then try what it says, then if
it doesn't work, explore a bit and ask a question.
Yes less talk is good. Yes its a fine line.

> 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?

Ah, i wonder if i detect a misunderstanding.
For the "Skins" side of things there is just a 
directory structure for additional skin-specific
resources e.g. javascript and css and images.

Depending on the skin name, Cocoon will find the
relevant resources automatically. See the sitemap
matches for resources in main/webapp

For Dispatcher i don't know how extra plugin-specific
and theme-based resources are handled. There is discussion
somewhere. Perhaps the link from the bottom of
Dispatcher Quickstart will help.

> 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.

That is a general problem that i am seeing too.
At the moment we stumble along and try to keep
things synchronised.


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

View raw message