Menu
▾
▴
generguide-devel — Discussion for developers of generguide
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(33) |
Jul
(21) |
Aug
(20) |
Sep
(80) |
Oct
(62) |
Nov
(8) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
(1) |
Oct
(6) |
Nov
(7) |
Dec
(12) |
| 2007 |
Jan
(9) |
Feb
(12) |
Mar
(1) |
Apr
(4) |
May
(6) |
Jun
(11) |
Jul
(16) |
Aug
(19) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Artur H. <ko...@pl...> - 2003-10-04 06:18:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 04 of October 2003 00:52, Cameron Shorter wrote: > I've changed all <!--&entity;--> to &entity; in the generguide docs. > I see this as an interum measure until we work out how we are going to > handle variables. This is very good news for me. It means that now entities can be used as attributes values. > Of note, I think this now means that we don't have a free WYSISYM editor > which will process generguide docs. This means we are failing one of the > primary use cases for the generguide project. (I have to confess that I > have not done much research trying out the other free docbook editors). Although I can't suggest any free WYSIWYM XML editor, I can suggest some good alternative for you. There is move, in our company, to change development environment to eclipse which has some nice features. This is of course Java IDE but has also very good support for CVS, and also good, structural XML editor. I didn't try it personaly (still emacs fun) but my cooworkers are very impressed with eclipse as an alternative for JBuilder. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fmYA0/6x1bjSKPkRAnvdAJwIr8c3MIbYi15m5SSzF7Tc//8OeACgjuzn maftB9SAdt/+po+KGQzdg1I= =hRS1 -----END PGP SIGNATURE----- |
|
From: Cameron S. <ca...@sh...> - 2003-10-03 22:53:29
|
I've changed all <!--&entity;--> to &entity; in the generguide docs. I see this as an interum measure until we work out how we are going to handle variables. Of note, I think this now means that we don't have a free WYSISYM editor which will process generguide docs. This means we are failing one of the primary use cases for the generguide project. (I have to confess that I have not done much research trying out the other free docbook editors). -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-10-03 22:01:38
|
Sean, comments inline regarding your suggestions about ENTITIES. Of note, we have 2 requirements for including text: 1. Include a docbook node (eg section). So far we have addressed this by using <xinclude> to other files, and I think we are in agreement that this is a reasonable solution. 2. Include a variable name. Eg, replace &project_name; with "Generguide". This is still not solved to our satisfaction and is the topic of this email. On Thursday 02 Oct 2003 7:41 am, Sean Wheller wrote: > ----- Original Message ----- > From: "Cameron Shorter" <ca...@sh...> > To: <gen...@li...> > Sent: Wednesday, October 01, 2003 12:22 PM > Subject: [generguide-devel] Re: Sample files > > > I was not actually looking for problems with XXE, I was hoping we could > > find > > > solutions. :) > > I know:-) Not trying to be difficult. > > > You have given a example of using ENTITIES to include files. What we > > have been doing with generguide is only including a variable string. Eg: > > "Project > > > Name". Only problem is XXE doesn't process these ENTITIES. Attached is > > one > > > of the files, and the entities.ent > > In Gener you have used Internal General Entities. > I used External General Entities. > For the parser, they are the same, just that one is internal and the other > external. > > XXE will open the document and the Entity will be shown in both cases. But > in both cases you cannot edit directly. No way to fix that without fixing > the XXE entity problem mentioned in my previous post. > > Actually I don't think that all the comments are required in Gener. The > documents will open with the new version of XXE. So why add comments. All > we must avoid is nesting. Agreed. Currently we are using <!--&project_name;--> to get around deficiencies with XXE. I agree we should use something else ASAP. > > So that is my first solution. > > Second solution, that will not suite every situation, is to use the > entityref > attribute when possible and suitable. > This will reduce the number of comments required in a document. But it is > not available on all elements. In DB you can now do the following: > <textobject> > <textdata entityref="filename"/> > </textobject> > > To make such a solution possible, would require modification of the DTD and > then it's not Docbook anymore. As I understand it, the example requires a new filename for each variable. I'd hope that all variables could be kept in one file. I've mentioned to Artur before that I'd prefer to only use standards where possible. However, I'm warming to the idea of extending docbook. > > Third solution is to use ulink when possible. Also consider variations > based on olink) but most people find olink to complicated and never get it > working. I don't know why. > Here is cvs.xml using ulink. BTW Artur did hint to this in the last IRC > meeting. > --SOF-- > <section id="cvs"> > <title>CVS</title> > > <para>Concurrent Versions System (CVS) is a version control system that > allows multiple developers to work on the same files at the same > time.</para> > > <para>Information on how to download and edit this project's source > code > are provided at: <ulink url="&cvs_url;"/>.</para> > > <para>Note, before you can edit files, you will need to be granted write > access from the &src_license_owner;.</para> > > <para>An excellent CVS manual can be found at <ulink > > url="http://cvsbook.red-bean.com/">http://cvsbook.red-bean.com/</ulink>.</p >a ra> > </section> > --EOF-- > Yes. If you use the solution for cvs_url you will not see any text in XXE, > but I think you get the idea. IMO it beats the comments handsdown. Beside > it could always be ... <para> ... are provided at: <ulink > url="&cvs_url;">SourceForge</ulink>.</para> Yes, I like this. > > > Fourth solution is to rethink how Gener uses enities and for what. > > Stay with me on this .... > > I think it better to develop an XSL customization layer that accepts > parameter input > than to use entities. That way we can pass the parameters to the XSL, > either by direct input, or by feeding the customization layer with an xml > file. In some environments it may also enable the use of method calls. > Where a var of the method could pass xml as string. syntax: > class.method(var1, var2, var3, xmlparameters) where xml parameters is a > pointer to a valid and well formed xml string. In code, abstraction of > Gener would then be possible and hence loading to application for editing > under GUI. > > Going off at a tangent again... SO the generguide customization layer would > have: > > <!-- Title of the Document --> > <xsl:param name="title"></xsl:param> > > <!-- Name of Project --> > <xsl:param name="projectname"></xsl:param> > > <!-- Version of Project --> > <xsl:param name="version"></xsl:param> > > ... continue to add and then customize and then /overide DB xsl's. Maybe > even set some common DB parameters. > > This has the nice side effect of making Gener more dynamic (less hard > coded). It also enables option setting Y, N, O, P > > A parameter file could conform to a DTD/XSD. > > parameter.xml > --SOF-- > <?xml version="1.0" encoding="UTF-8"?> > <parameters> > <title>The Definitive Guide</title> > <product>GenerGuide</product> > <version>1.0</version> > </parameters> > --EOF-- > > parmeter.dtd > --SOF-- > <!ELEMENT product (#PCDATA)> > <!ELEMENT parameters (#PCDATA | title | product | version)*> > <!ELEMENT title (#PCDATA)> > <!ELEMENT version (#PCDATA)> > --EOF-- > > parameter.xsd > --SOF-- > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified"> > <xs:element name="product" type="xs:string"/> > <xs:element name="parameters"> > <xs:complexType mixed="true"> > <xs:choice minOccurs="0" maxOccurs="unbounded"> > <xs:element ref="title"/> > <xs:element ref="product"/> > <xs:element ref="version"/> > </xs:choice> > </xs:complexType> > </xs:element> > <xs:element name="title" type="xs:string"/> > <xs:element name="version" type="xs:string"/> > </xs:schema> > > --EOF-- Sean, I see the potial of this suggestion. Of note, I'd imagine parameter.xml should be incorporated in the generconfig.xml. Another variation of this idea I had is to have a param_to_entity.xsl style sheet. Users can edit the param.xml seperately, then convert to ENTITIES before editing/publishing. However, I think your idea of extending docbook is better. If we are going to extend docbook, I'd be keen to discuss the idea with key people working on the docbook standard, and writing docbook editors. Hopefully we will be able to get support from editors, and possibly even get an addition to the docbook standards. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-10-03 21:14:07
|
In response to one of Artur's suggestions, I've moved xinclude.xsl to selectivexinclude.xsl -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Artur H. <ko...@pl...> - 2003-10-03 21:04:50
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> > I prefer to do one script now and maybe later divide it into
> > more parts.
> I prefer two scripts. I see distinct communities growing behind
> generguide:
> 1. Users who are prepared to install java.
> 2. 'nix users who don't like java.
> 3. Windows users who won't install java. (Tech writers)
> 4. 'nix/cygwin users.
> Hence, I think we should consider treating java and shell scripts as
> seperate sub-projects.
I was thinking about simple extension of existing bash script first.
Support for Java tools would be visible only if you set command line
parameter to use Java tools. By default Java tools weren't be used,
visible and no JDK and jars are necessary.
I need bash because of it's scripting language features, command line
parameters parsing, easy way to manage files, setup target and temporary
directories and so on.
I also need Java tools for its features like XSLDocBook extensions and
target PDF format.
So I am not ready yet to create support for all kinds of users.
I agree that it is better to have separated code for Java and non-Java
tools but I wanted to prevent implementation the same part of script in
2 places (command line parameters parsing, seting up target, temp
directories and so on).
Than I propose to implement this as follows:
1. Leave current generpublish.sh as a master script parsing command line
parameters, seting up whole necessary environment and calling proper
tool script.
2. Create 2 tool scripts, one using xmlproc tools, and second used Java tools.
By default xmlproc tools will be used but if '-j' parameter is given Java
tools will be used and target format PDF will be available.
Artur
- --
Artur Hefczyc "Don't change people, just live with them."
Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/feQk0/6x1bjSKPkRAmaSAKDPVhMvZiTZ094vtFCZGWlL62JzjQCeJ+RY
YkAT+8RojFm6CwnKcx3BW6c=
=tNvV
-----END PGP SIGNATURE-----
|
|
From: Cameron S. <ca...@sh...> - 2003-10-03 19:58:05
|
Seems like the generguide email list is down again. (last message I sent didn't get through). -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-10-03 12:09:57
|
On Friday 03 Oct 2003 3:55 pm, Sean Wheller wrote: > > > And probably (I am not sure yet if I will be able) > > > 5. Generguide HOWTO > > > > Yes, I think this has moved onto the critical path > > for the next release. I > > think Sean mentioned that he was interested in this > > too. > > Yes, please send me any ideas and lots of small pieces > so I can integrate them into what I am currently > doing. I look forward to seeing your work. It will help me write additions if I can see what bits are missing. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-10-03 12:09:57
|
I'm happy to announce that I have the generguide builder working! http://www.gisontheweb.com:8080/~cameron/cgi-bin/toform.pl Select the sections, then click on the "Build Documentation" button. This brings us very close to release 0.2 as per http://generguide.sourceforge.net/release.html What I think still needs doing is: 1. Get a common opinion on our use of ENTITIES. Although I don't think we need to have this issue set in concrete now. 2. Put together a users guide. 3. Tidy up the requirements. Sean, I'd be interested to hear your ideas on how we can work together on the documentation. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Sean W. <se...@ya...> - 2003-10-03 05:55:49
|
--- Cameron Shorter <ca...@sh...> wrote: > On Friday 03 Oct 2003 6:14 am, Artur Hefczyc wrote: > > > But lets present new features and ideas: > > 1. Started to add support for Java tools. They are > important for > > at least 2 reasons: > > - (S)DocBook XSLT extensions are only > implemented for Java tools > > - PDF generation (FOP -> PDF) is only > implemented in Java tools > > Great. Agreed. > > > > > 2. Some limited support for catalogs for Java > tools > > ok. > > > > > 3. Let me return to keeping docbook XSLT in CVS > repository issue. > > I don't like this idea, however I agree that > we should provide > > complete environment with all necessary > libraries. > > Our needs are not limited to those XSLT > templates but I see also > > some Java jars as usefull, at least SDocBook > DTD (because we use > > it for our guides), fop library to generate > PDFs and probably some > > more. Keeping all libraries in CVS repository > forces us to use outdated > > versions or constant updating our repository with > new releases. This is why I want advocating customization layers for the DTD's and XSL's. > > > > So I propose to not keep external libraries in > our CVS repository at > > all. But on the other hand we should include them > in release of our > > environment. So joining all necessary external > libraries should be part of > > package build process. Excellent. > > Since they are all available on the net, it > seems to me easy to create > > appropriate script downloading, unpacking and > preconfiguring them. > > This script could be used as an automatic tool > for building generguide > > release or for downloading libraries when > generguide is used directly > > from CVS. > > I agree with your logic. Lets work toward moving > docbook XSLT out of CVS as > you suggest. Yes. > > Below I present what I am going to do in very > short future: > > 1. Complete support for Java tools > Great. > > > 2. Support for generating PDF files (FOP) > Great. > > > 3. Script downloading and installing in generguide > hierarchy > > the last releases of all necessary libraries > > - docbook xsl > > - fop > > - sdocbook dtds (they are necessary for > complete catalogs support) > > 4. Complete support for both cygwin and linux > systems. > Cool. > > > > > And probably (I am not sure yet if I will be able) > > 5. Generguide HOWTO > Yes, I think this has moved onto the critical path > for the next release. I > think Sean mentioned that he was interested in this > too. Yes, please send me any ideas and lots of small pieces so I can integrate them into what I am currently doing. > 3. Windows users who won't install java. (Tech > writers) :0( They don't know what they're missing. > Hence, I think we should consider treating java and > shell scripts as seperate > sub-projects. Layering. Excellent. Sean Wheller __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Cameron S. <ca...@sh...> - 2003-10-02 21:27:12
|
On Friday 03 Oct 2003 6:14 am, Artur Hefczyc wrote: > But lets present new features and ideas: > 1. Started to add support for Java tools. They are important for > at least 2 reasons: > - (S)DocBook XSLT extensions are only implemented for Java tools > - PDF generation (FOP -> PDF) is only implemented in Java tools Great. > > 2. Some limited support for catalogs for Java tools ok. > > 3. Let me return to keeping docbook XSLT in CVS repository issue. > I don't like this idea, however I agree that we should provide > complete environment with all necessary libraries. > Our needs are not limited to those XSLT templates but I see also > some Java jars as usefull, at least SDocBook DTD (because we use > it for our guides), fop library to generate PDFs and probably some > more. Keeping all libraries in CVS repository forces us to use outdated > versions or constant updating our repository with new releases. > > So I propose to not keep external libraries in our CVS repository at > all. But on the other hand we should include them in release of our > environment. So joining all necessary external libraries should be part of > package build process. > Since they are all available on the net, it seems to me easy to create > appropriate script downloading, unpacking and preconfiguring them. > This script could be used as an automatic tool for building generguide > release or for downloading libraries when generguide is used directly > from CVS. I agree with your logic. Lets work toward moving docbook XSLT out of CVS as you suggest. > > I became real user of generguide project. I use it for 2 different kinds > of documentation development. Great. > At work I base on Generguide our internal developers guide with some > modifications - use all features of generguide and for separate document > written in Sdocbook so I use generguide only script and libraries. > > And as a real user I try to change generguide to my needs. I hope > this is correct, if not let me know I will revisit my approach. > > I understand that all important changes should be discussed first but > if I have to do something I have a choice: > 1. to write separate tool for this > or > 2. to extend generguide with lacking feature. Yes, 2) is preferable. > > Below I present what I am going to do in very short future: > 1. Complete support for Java tools Great. > 2. Support for generating PDF files (FOP) Great. > 3. Script downloading and installing in generguide hierarchy > the last releases of all necessary libraries > - docbook xsl > - fop > - sdocbook dtds (they are necessary for complete catalogs support) > 4. Complete support for both cygwin and linux systems. Cool. > > And probably (I am not sure yet if I will be able) > 5. Generguide HOWTO Yes, I think this has moved onto the critical path for the next release. I think Sean mentioned that he was interested in this too. > > Assuming you agree with my changes I have one issue: > Do you prefer to develop Java-tools support in separate > script or include it in existing one? > 1. Separate scripts make them a little bit simpler however forces > us to do some things in two places > 2. One script will become a little bit complex but many actions will > be implemented only in one place. > > I prefer to do one script now and maybe later divide it into > more parts. I prefer two scripts. I see distinct communities growing behind generguide: 1. Users who are prepared to install java. 2. 'nix users who don't like java. 3. Windows users who won't install java. (Tech writers) 4. 'nix/cygwin users. Hence, I think we should consider treating java and shell scripts as seperate sub-projects. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Artur H. <ko...@pl...> - 2003-10-02 20:15:13
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well,
They are not changes indeed, they are rather adds to existing
set of features. I always try to preserve current functionality
and keep it compatible with earlier versions.
So if something works bad on your system let me know.
But lets present new features and ideas:
1. Started to add support for Java tools. They are important for
at least 2 reasons:
- (S)DocBook XSLT extensions are only implemented for Java tools
- PDF generation (FOP -> PDF) is only implemented in Java tools
2. Some limited support for catalogs for Java tools
3. Let me return to keeping docbook XSLT in CVS repository issue.
I don't like this idea, however I agree that we should provide
complete environment with all necessary libraries.
Our needs are not limited to those XSLT templates but I see also
some Java jars as usefull, at least SDocBook DTD (because we use
it for our guides), fop library to generate PDFs and probably some more.
Keeping all libraries in CVS repository forces us to use outdated
versions or constant updating our repository with new releases.
So I propose to not keep external libraries in our CVS repository at all.
But on the other hand we should include them in release of our
environment. So joining all necessary external libraries should be
part of package build process.
Since they are all available on the net, it seems to me easy to create
appropriate script downloading, unpacking and preconfiguring them.
This script could be used as an automatic tool for building generguide
release or for downloading libraries when generguide is used directly
from CVS.
I became real user of generguide project. I use it for 2 different kinds
of documentation development.
At work I base on Generguide our internal developers guide with some
modifications - use all features of generguide and for separate document
written in Sdocbook so I use generguide only script and libraries.
And as a real user I try to change generguide to my needs. I hope
this is correct, if not let me know I will revisit my approach.
I understand that all important changes should be discussed first but
if I have to do something I have a choice:
1. to write separate tool for this
or
2. to extend generguide with lacking feature.
Below I present what I am going to do in very short future:
1. Complete support for Java tools
2. Support for generating PDF files (FOP)
3. Script downloading and installing in generguide hierarchy
the last releases of all necessary libraries
- docbook xsl
- fop
- sdocbook dtds (they are necessary for complete catalogs support)
4. Complete support for both cygwin and linux systems.
And probably (I am not sure yet if I will be able)
5. Generguide HOWTO
Assuming you agree with my changes I have one issue:
Do you prefer to develop Java-tools support in separate
script or include it in existing one?
1. Separate scripts make them a little bit simpler however forces
us to do some things in two places
2. One script will become a little bit complex but many actions will
be implemented only in one place.
I prefer to do one script now and maybe later divide it into
more parts.
Artur
- --
Artur Hefczyc "Don't change people, just live with them."
Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/fIcs0/6x1bjSKPkRAl5HAJ9SVN4xay76Pa8DBBWAFKVQBdBFHgCfXCnN
9IWgX3WxLEQiuAWRCt53yyM=
=FVYo
-----END PGP SIGNATURE-----
|
|
From: Cameron S. <ca...@sh...> - 2003-10-01 11:11:04
|
I was not actually looking for problems with XXE, I was hoping we could find solutions. :) You have given a example of using ENTITIES to include files. What we have been doing with generguide is only including a variable string. Eg: "Project Name". Only problem is XXE doesn't process these ENTITIES. Attached is one of the files, and the entities.ent On Saturday 27 Sep 2003 7:13 pm, you wrote: > Attached samples files should demonstrate the problems with ENTITIES within > XXE. > > Files: > root.xml > file1.xml > file2.xml > file3.xml > > When you open root.xml you will get the message about &yes_nesting; if you > open the file and save it to a new file, say root1.xml. You will see that > file3.xml (nested in file2.xml) will not be an ENTITY listed in root1.xml. > > The only way that XXE supports ENTITIES is if all are direct children of > the root.xml. Even then you cannot edit them directly. > > The root.xml is valid, but XXE is broken. > > This is why I don't like it as an Authoring tool. It makes modular > documentation, based on the ENTITY method impossible to manage. The most > you can hope for from XXE is to be able to view your documents, but then I > can do that in xhtml/html. Editing and saving root.xml, will break the > integrity of my document content as file3.xml is missing. I only use XXE to > view and edit when the document does not contain nested ENTITIES like > file3.xml. > > Hope this helps. > > Sean Wheller -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-09-30 11:25:22
|
I've forwarded this to this generguide list because I think it is worth archiving, and Artur probably has ideas on this as well. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-09-30 11:09:58
|
I've got a demo of the Configuration Builder form at: http://www.gisontheweb.com:8080/~cameron/cgi-bin/toform.pl You can: Select sections that you want included or excluded. Note that the configuration file (at the bottom of the page) is built in real time while selecting the options. After selecting options you can select the rebuild button at the bottom. Sections that have been excluded will be highlighted Red. Next, I need to get this form to trigger calling the generpublish.sh script to build the documentation. Hopefully, this shouldn't be much more than a day or two's work. Credit to Darren Houston who has provided the hosting machine. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-09-29 21:43:35
|
Thanks Darren, you are a champion. I need a cgi-bin. My scripts run perl and xsltproc which I note you already have installed. I don't want to abuse your generosity, so I plan to only use your computer for generguide for the next 3 months or so as a demonstration site until we get something more permanent. So don't worry about setting up any sub-domains or the like unless it makes things easier for you. Thanks again, Cameron. On Tuesday 30 Sep 2003 7:20 am, you wrote: > Hello Cameron. > > I will allow you to run the scripts from my computer. E-mail me any info I > might need to setup what you require. > > Thank you, > > Darren H. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Cameron S. <ca...@sh...> - 2003-09-29 20:42:41
|
Sean that would be great. Do you want your computer to become the main generguide site, or should we look for a larger hosting body to pay for the bandwidth and CPU? In the interum, I will look around for someone who can host a demo for the next 3 months or so. On Monday 29 Sep 2003 10:08 pm, Sean Wheller wrote: > If you don't find a host. I will be able to host in > about three months from now. > > Platform will be SuSE with Apache Web Server. For core > generguide-devel group, I will be able to provide > additional access via SSH. > > Let me know if a host is found in the interim. My > offer stands, unless an alternative contribution is > found in the interim. > > Sean Wheller > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Sean W. <se...@ya...> - 2003-09-29 12:09:48
|
If you don't find a host. I will be able to host in about three months from now. Platform will be SuSE with Apache Web Server. For core generguide-devel group, I will be able to provide additional access via SSH. Let me know if a host is found in the interim. My offer stands, unless an alternative contribution is found in the interim. Sean Wheller __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Cameron S. <ca...@sh...> - 2003-09-29 11:23:03
|
Hi, http://generguide.sourceforge.net is a project which grew out of the Geotools Software Developers Guide, and provides a generic Developers Guide which can be used by any project. We have reached a point where we are able to build a Configuration File from a web form which specifies which sections you want in your Tailored Guide. However, we can't run CGI form builder from Sourceforge. (Sourceforge doesn't seem to support xsltproc from a CGI script). Does anyone have a Linux Web server that I could use to prototype our scripts and provide initial demonstrations? -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Artur H. <ko...@pl...> - 2003-09-29 07:24:07
|
> expandconfig.xsl has been removed from the repository as well. It's
> functionality has been moved into toform.xsl
Ok,
1. but xsl/expandconfig.xsl is called from generpublish.sh script so
this script should be corrected to not use this file.
2. xsl/param.xsl is called from xsl/xinclude.xsl so this one also should
be corrected to not use this file. (At the moment I added to my
version of param.xsl lacking parameter and it works well.)
Artur
--
Artur Hefczyc
Open Source Developer
http://generguide.sourceforge.net/
http://www.geotools.org/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/
|
|
From: Artur H. <ko...@pl...> - 2003-09-28 23:53:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 28 of September 2003 21:52, Cameron Shorter wrote: > I did have a param.xsl, but I removed it and moved the funtionality into > toform.xsl . > Have you done a "cvs update" recently? I suspect you may be using an old > version of xsl/toform.xsl . Yes, I have the most recent file, however param.xsl is still used in xinclude.xsl file. Anyway I created new param.xsl file and moved there or XSL parameters given up to now in xsltproc command line. Look into this file and see what it is for. But there is still problem with xsl/expandconfig.xsl file which does not exist in cvs repository. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/d0lM0/6x1bjSKPkRAvyLAKCycomaXQZVRVt8smRz5nZPQu7M6wCeINi2 OIWiUmVCUNcPNAPKgsEQVG8= =nhUP -----END PGP SIGNATURE----- |
|
From: Cameron S. <ca...@sh...> - 2003-09-28 21:51:12
|
expandconfig.xsl has been removed from the repository as well. It's functionality has been moved into toform.xsl If you are still awake, I'm on IRC now if you want to discuss this. On Monday 29 Sep 2003 4:39 am, Artur Hefczyc wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > There are still missing file in generguide CVS repository: > xsl/expandconfig.xsl > > Please put it to repository to make it easier to test changes I > make to script. > > Artur > - -- > Artur Hefczyc "Don't change people, just live with them." > Open Source Developer: > http://www.geotools.org/ > http://generguide.sourceforge.net/ > http://wttools.sourceforge.net/ > http://maven-plugins.sourceforge.net/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/dyro0/6x1bjSKPkRAlsAAJ0dMqsTbq1fQ5LHfporu0GGBQCExQCgw7o9 > xzI0lhLCc+572J8rnieD1FI= > =biPT > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > generguide-devel mailing list > gen...@li... > https://lists.sourceforge.net/lists/listinfo/generguide-devel -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Artur H. <ko...@pl...> - 2003-09-28 21:43:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are still missing file in generguide CVS repository: xsl/expandconfig.xsl Please put it to repository to make it easier to test changes I make to script. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dyro0/6x1bjSKPkRAlsAAJ0dMqsTbq1fQ5LHfporu0GGBQCExQCgw7o9 xzI0lhLCc+572J8rnieD1FI= =biPT -----END PGP SIGNATURE----- |
|
From: Artur H. <ko...@pl...> - 2003-09-28 20:37:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am sorry for flooding with email's, however I am just working on this and don't want you to waste time on problems just resolved. I did small experiment, I included "generconfig" variable declaration in my 'param.xsl' file and it seems that everything not works not (apart from still missing xsl/expandconfig.xsl file) So maybe my param.xsl file could be joined with yours. Artur - - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/d0Ym0/6x1bjSKPkRAly8AKCio5YNvbr3U+yJZ4LVho2PC32OvwCaA5Da BzvBMUNxRWrMUuFebeW8d7o= =Nv0P -----END PGP SIGNATURE----- |
|
From: Cameron S. <ca...@sh...> - 2003-09-28 20:18:27
|
I did have a param.xsl, but I removed it and moved the funtionality into toform.xsl . Have you done a "cvs update" recently? I suspect you may be using an old version of xsl/toform.xsl . On Monday 29 Sep 2003 5:08 am, Artur Hefczyc wrote: > It seems to me that there is also another missing file: > xsl/param.xsl > However I didn't notice it before because I created file > with the same name but for different purpose. -- Cameron Shorter http://cameron.shorter.net Open Source Developer http://generguide.sourceforge.net http://mapbuilder.sourceforge.net http://geotools.org Senior Software Engineer http://www.adi-limited.com |
|
From: Artur H. <ko...@pl...> - 2003-09-28 19:10:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It seems to me that there is also another missing file: xsl/param.xsl However I didn't notice it before because I created file with the same name but for different purpose. param.xsl is the standard file for parametrizing DocBook XSL processing. I mean instead of giving parameters in command line: --param section.autolabel 1 They are all go to param.xsl file. It makes sense in particular for generguide project because it make it easier to parameterize project based on generguide framework. So have you any param.xsl file which should be placed in xsl/ directory (I will than change main to different name) or your file is not necessary anymore and I can put main there with param.xsl name. param.xsl is called from xinclude.xsl file. Artur - -- Artur Hefczyc "Don't change people, just live with them." Open Source Developer: http://www.geotools.org/ http://generguide.sourceforge.net/ http://wttools.sourceforge.net/ http://maven-plugins.sourceforge.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dzHK0/6x1bjSKPkRAjpcAJ4xiYDZXuz4k6fWNPE/W6aVqyPbigCfdGyw rHYmB8SAXom+GQ+l4N2o/1k= =zSaD -----END PGP SIGNATURE----- |
54 messages has been excluded from this view by a project administrator.
