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