forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject RE: [jira] Commented: (FOR-639) define terminology for the various aspects of Dispatcher
Date Sat, 15 Apr 2006 01:46:51 GMT


> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Saturday, 15 April 2006 8:45 AM
> To: dev@forrest.apache.org
> Subject: Re: [jira] Commented: (FOR-639) define terminology for the
> various aspects of Dispatcher
> 
> Gav.... wrote:
> >
> >
> > > -----Original Message-----
> > > From: David Crossley [mailto:crossley@apache.org]
> > > Sent: Friday, 14 April 2006 8:45 AM
> > > To: dev@forrest.apache.org
> > > Subject: Re: [jira] Commented: (FOR-639) define terminology for the
> > > various aspects of Dispatcher
> > >
> > > Gav.... wrote:
> > > > > From: David Crossley (JIRA) [mailto:jira@apache.org]
> > > > >
> > > > > 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.

Actually, I thought I had done the changes required. Your
Saying that there is quite some work involved has me 
Thinking I may have underestimated the job and missed something
Out. I did :-

1. Added definitions to the glossary-v10.mod with definition being
Its only but compulsory sub-element.

2. Added a template, template match and apply templates to the appropriate
places in glossary-to-document.xsl
3. Altered glossary.xml to add parent <definitions>.
4. Did an 'Ant Test' (which in turn does a site build) and it all passes.
5. Forrest Run, and it all works fine.

Did I miss anything out?


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

Does 'forrest site' do more than 'ant test', I have not really been
Doing forrest site with plugins, just the ant test as I thought that
Was more thorough.

> 
> > > 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.
> > > http://forrest.apache.org/faq.html
> > > => 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.

Some plugins work with 0.7 and earlier and I thought others
Only worked with 0.8-dev. I have only ever installed and
Used 0.8-dev, I don't use the 0.7 version.

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

So, can we make the plugin compatibile with both skins
And themes? What does the main forrest site use, I see
A skin and a theme enabled in default.forrest.properties.

 There is discussion
> somewhere. Perhaps the link from the bottom of
> Dispatcher Quickstart will help.

I'll take a look, thanks.

Gav...

> 
> > 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.
> 
> -David
> 
> > Sorry if I missing the obvious as to why all these plugins contain all
> these
> > copies of themes and skins.
> >
> > Thanks
> 
> 
> --
> 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



Mime
View raw message