Re: [RT] Accepting and managing Skin Packages
Ross Gardler wrote: > I would love to see your skin made available (I too like it a great > deal). However, we need to discuss exactly how to accept this donation > over on the dev list (this mail is copied to the dev list and replies > will be sent there). Could we please keep such discussions on the dev list. The replies to the user list do not automatically come here. Why have you called this thread a Random Thought? It sounds like a proposal. Be aware that people often ignore RT threads until they have time to investigate, whereas proposals need the attention of committers. > In the past Forrest has not wanted to accept new skins because we do not > have the resources to maintain them. Consequently, we added a > skin-packaging system that allowed people to develop skins and make them > available via an automatic download mechanism. There were two reasons for not accepting new skins: Need interested committers/developers to maintain them. Concentrate our energy on developing one very useful skin. > The hope was that we would be able to encourage people, such as > yourself, to make their skins available via a zip download from their > sites. The benefit would be more eyes on the skin and thus improvements > would be sent back to you. > > Unfortunately, we have not exploited this feature. Now is the time for > us to do so, and your skin can be the first example of that feature > (would you believe it was added in 0.5 and we still don't use it - shame > on us) Steady on. No-one has bothered to contribute a skin via the download mechanism. So there is no shame on us. > I think Forrest should accept your skin package in one form or another, > the question is how, I see our options as: > > 1. Forrest accepts the skin and keeps it in SVN > > I am -0 on this. We need to would then be forced to maintain the skin > and ensure that it is "correct" in the sense of everything is done the > right way. I would prefer we only maintain the one skin in our core and > utilise the skin packaging system in order to add more skins. Actually there is another option that comes before all of these. We enhance Pelt skin to be able to address these needs, hopefully with patches from the community. We have tried to encourage this option, but few people are interested. I think it is the best option (apart from the views plugin). We work as a community to develop one really good skin that can address most needs and enables people to configure it. > 2. We make all non-core skins available via a skins sub project within > Forrest > > In this instance we would create a new project for contributed skins. > Anyone donating a skin will automatically get commit access to this > sub-project (but not to Forrest itself). > > I am +1 for this if it is possible within the Apache Infrastructure. It > ensures that there will be at least one person with commit access with a > vested interest in maintaining the skin and in applying any contributed > patches. > > Does the way our SVN is set up allow this? This option does not absolve us from needing to oversee all the commits and collaborate to keep the skin maintained. It is my opinion that the Forrest project is not yet ready to cope with the extra work of overseeing people who are not interested in the Forrest project itself. As far as i know, the ASF is still geared towards having full committers. This concept of partial committer i have not heard of before, other than some discussions here at Forrest when we were establishing our project guidelines to be sure to enable that possibility in the future. > 3. The skin author makes it available via a ZIP download using the > skin-package system > > I am +0 for this. I would prefer to see a solution that makes the skin > available through a version control mechanism to simplify patches. If > only a skin-package zip is provided it will make it difficult for people > to contribute to the skin. > > 4. The skin author donates the skin to an external Open Source project > and uses that projects CVS/SVN etc. > > This is kind of a half way house between option 2 and option 3. In the > past we tried to set-up a Sourceforge project for this, but it was > rejected as the project would not generate program code. I will offer > the Burrokeet project on SF since this uses Forrest at its core so the > housing of Forrest skins is appropriate within that project. I do not > have any problems adding skin contributors to that project to ensure > they have commit access. Of course, there may be other projects that are > appropriate. > > > --- > > Whatever we do, we should encourage the use of skin packages and we > should extend the system to list "official" skins in the same way the > plugin system does, see > http://forrest.apache.org/0.7/docs/plugins/index.html > > Comments, ideas? I am very concerned that we told Thorsten that we had no time to review the "views" plugin proposal, which i gather will a
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
Ferdinand Soethe wrote: > David Crossley wrote: > > > If you tell the list what your general aim is then > > we can see what any legal issues might be. We can also > > seek help from the Apache "legal-discuss" mailing list. > > It is actually quite simple to describe: > > I want to donate the concept for the English language version of our > book to Apache while keeping all the rights for the German version to > avoid any conflicts or problems with my publishers. > > The (potential) problem is that in the publishing world you can > license the right to publish different language versions separately > (e.g. to different publishers) but I'm not sure if that works with the > Apache license. I am not going to attempt to interpret the Contributor License Agreement (CLA) for this case, as i still don't know the facts nor what it is that you would actually be contributing. Also IANAL so it would be misleading for me to say anything. I suggest that the best way forward is for you and Ross to present a clear case to the ASF Legal Discussion mailing list. http://www.apache.org/foundation/mailinglists.html#foundation-legal Until that is clarified, we cannot proceed with a proposal for the Apache Forrest project to take such a direction. --David
How to avoid hard-coding site-visible message strings in skin files
Hello, A few days ago I added issue FOR-506 on this topic. This is my original message: "Text strings like "Copyright", "Published", and "Search" are hardcoded into skin files like site2xhtml.xsl. When creating web sites in languages other than English the web developer is forced to create local versions of these skin files with the appropriated translations. Instead, the DTD for the skinconf.xml should be improved to allow these translations to be specified in this file. This would make Forrest much easier to use." Ross suggested the following as an example of a possible solution: This would work for me as long as I can also specify the language manually with something like And this, because at this moment I am more interested in a uni-lingual (non-English) web site rather than in a multi-lingual one. I believe the former is by far the most common case. Another possibility could be something like this, totally independent of a "lang" setting and just driven by the skin: For a multi-lingual site I would like to have something that dynamically changes the skin and content of the site. But that is a more elaborated solution that is probably being addressed by the i18n team (?). I'm not sure if a solution that simply gets the "hard-coded" labels out of the way has to necessarily be part of the i18n "framework". Anyway, with your help and guidance I'd like to put some effort implementing a solution of some kind. Comments? -- Pedro
Re: does checksums-uri in cli.conf work?
Ferdinand Soethe wrote: In the default cli.conf I found this setting commented out. Are there reasons not to use that? It would probably allow synchronizing sites to a server with Eclipses' ftp-addon very efficiently. Probably faster to try turning it on than for someone to type a reply (I don't know the answer by the way). Ross
Re: [JIRA] Created: (FOR-505) Allow the retrieval of raw html files
David Crossley wrote: Ross Gardler wrote: [ snip ] We could add a new skinconf property to define the behaviour for *.html files in xdocs we can tell people affected by this issue to make their embedded content ihtml and their raw content html. i.e. true The result is, setting skinHTML to false will give the same behaviour as 0.6 We could make this the default in order to minimise the upgrade behaviour. If we implement this workaround, then i reckon that the default should be "true". It would be easier to explain the "false" case and it would be a smaller number of people affected. However, it forces them to change their filename extensions. That would be difficult for the main use-case, which is to include a set of existing *.html docs as part of the site. The thread "RT: RAW content" that is linked from issue FOR-505 ended with an interesting idea about using site.xml to specify exclude/include patterns. http://marc.theaimsgroup.com/?l=forrest-dev&m=110172196321097 It seems to be independent from the "locationmap" ideas discussed earlier in that thread. Would that be better to implement now, rather than the skinHTMLSources=true workaround? Wow, that is the most focused rambling thread I have read for a long time, all that discussion to come around to such an elegant solution. Kudos to everyone involved (and thank goodness for mail archives, I had completely forgotten the whole thing). A tip for the wary read the first few and the last email, skip everything in between it goes round many houses to get to the last mail. Anyway, +1 for implementing it instead of the skinHTMLSources=true workaround. I'm game for having a go at it, but I'm not sure when I will be able to so others should feel free to jump in. Ross
Re: Raw processing: Correction in upgrading_07.html
Ferdinand Soethe wrote: is it correct to assume that this statement If you need to link to html files but want them to be un-processed, then place them in the src/documentation/content/ directories and add an entry to conf/cli.xconf to exclude them from processing. An FAQ describes the use of Cocoon's cli.xconf is a typo and should say If you need to link to html files but want them to be un-processed, then place them in the src/documentation/content/xdocs directories and ^ add an entry to conf/cli.xconf to exclude them from processing. An FAQ describes the use of Cocoon's cli.xconf At least that seems to be in line with the results from my tests and the recent discussion on this list. But I thought I'd check before I change ... The handling of raw HTML content is going to change before the 0.7 release as discussed in http://issues.cocoondev.org//browse/FOR-505?page=comments#action_12427 I'd hold off until that is resolved. Ross
[JIRA] Updated: (FOR-505) Allow the retrieval of raw html files
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Wed, 1 Jun 2005 2:56 PM Changes: Fix Version changed to 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-505?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-505 Here is an overview of the issue: - Key: FOR-505 Summary: Allow the retrieval of raw html files Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Reporter: Ross Gardler Created: Tue, 24 May 2005 3:53 PM Updated: Wed, 1 Jun 2005 2:56 PM Description: With the merging of the raw content directory and the xdocs directory it is no longer possible to retrieve the raw, unprocessed version of an HTML file. The raw HTML files were removed from the fresh-site in revision 178279. When we have added support for raw HTML files back into the system we should revive these files as a demo. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
does checksums-uri in cli.conf work?
In the default cli.conf I found this setting commented out. Are there reasons not to use that? It would probably allow synchronizing sites to a server with Eclipses' ftp-addon very efficiently. -- Ferdinand Soethe
Raw processing: Correction in upgrading_07.html
is it correct to assume that this statement > If you need to link to html files but want them to be un-processed, > then place them in the src/documentation/content/ directories and > add an entry to conf/cli.xconf to exclude them from processing. An > FAQ describes the use of Cocoon's cli.xconf is a typo and should say > If you need to link to html files but want them to be un-processed, > then place them in the src/documentation/content/xdocs directories and ^ > add an entry to conf/cli.xconf to exclude them from processing. An > FAQ describes the use of Cocoon's cli.xconf At least that seems to be in line with the results from my tests and the recent discussion on this list. But I thought I'd check before I change ... -- Ferdinand Soethe
Re: Slide Integration
Sent to dev as suggested. On 5/18/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > Has anyone already documented how to use Slide as a backend to > > Forrest? If not maybe some high-level pointers of where to start? > > Nobody has documented this, or to my knowledge tried it. > > You'd probably find more help on the dev list, where we will be glad to > help you. Please send your question there with a description of a use > case describing exactly how you would like the integration to work (may > seem like an obvious thing, but it gives us a common language to > communicate ides with). > > Ross I guess I could give long and short term goals/use-cases. In the short term, I'd like to simply be able to point "project.xdocs-dir" in forrest.properties to a slide repository like: project.xdocs-dir=http://127.0.0.1:8080/slide/xdocs In this way, I could use Epic or Spy to author documents using the versioning (among other) features of Slide and publish them using Forrest. In the long term, I'd like to do the same as above, but have some sort of workflow state metadata understood by both the authoring environment (Epic/Spy) and publishing engine (Forrest). I'm thinking some fairly simple states like: New, Author, Edit, Publish and then Forrest would be able to inspect that metadata and only publish those documents with the "Publish" state. The long term part still has much to be figured out such as the impacts on navigation for document creations/deletions but I hope all ultimately workable. For now, if I could get some tips for where to start on the short term of pointing xdocs at a webdav location. Thanks, --tim
[RT] Accepting and managing Skin Packages (was Re: Forrest Example Sites)
Claudia Könnecke wrote: Ferdinand Soethe wrote: I really like your skin design. The clear typographically structuring of the menus, the use of color and the placement of logos and background image would make it very useful for commercial and private sites. Would you consider donating it to our skin pool? Or short of that share the code so that others can copy bits and pieces of it? Hi Ferdinand! First of all thanks for the praise - we feel flattered :) We see no problem in sharing our skin-code, but beware - we had to bend some rules in certain areas (e.g. changing stuff in skins/common/xslt) to achieve what we wanted. There possibly are ways to prevent these changes (especially in the 0.7 codebase - which we haven't looked at yet). There is no need to change the common files, simply override the templates you need to change in your own skin. We can show you how to do this when working on your skin package donation. We started the website in December 2004 where documentation was rather sparse and spent a lot of time learning things the hard way so possibly not all of our solutions are 'by the book'. The Open Source way is to take code and polish it, so no worries there. So if this hasn't scared you yet, please contact us on how we may give back to the community. I would love to see your skin made available (I too like it a great deal). However, we need to discuss exactly how to accept this donation over on the dev list (this mail is copied to the dev list and replies will be sent there). In the past Forrest has not wanted to accept new skins because we do not have the resources to maintain them. Consequently, we added a skin-packaging system that allowed people to develop skins and make them available via an automatic download mechanism. The hope was that we would be able to encourage people, such as yourself, to make their skins available via a zip download from their sites. The benefit would be more eyes on the skin and thus improvements would be sent back to you. Unfortunately, we have not exploited this feature. Now is the time for us to do so, and your skin can be the first example of that feature (would you believe it was added in 0.5 and we still don't use it - shame on us) I think Forrest should accept your skin package in one form or another, the question is how, I see our options as: 1. Forrest accepts the skin and keeps it in SVN I am -0 on this. We need to would then be forced to maintain the skin and ensure that it is "correct" in the sense of everything is done the right way. I would prefer we only maintain the one skin in our core and utilise the skin packaging system in order to add more skins. 2. We make all non-core skins available via a skins sub project within Forrest In this instance we would create a new project for contributed skins. Anyone donating a skin will automatically get commit access to this sub-project (but not to Forrest itself). I am +1 for this if it is possible within the Apache Infrastructure. It ensures that there will be at least one person with commit access with a vested interest in maintaining the skin and in applying any contributed patches. Does the way our SVN is set up allow this? 3. The skin author makes it available via a ZIP download using the skin-package system I am +0 for this. I would prefer to see a solution that makes the skin available through a version control mechanism to simplify patches. If only a skin-package zip is provided it will make it difficult for people to contribute to the skin. 4. The skin author donates the skin to an external Open Source project and uses that projects CVS/SVN etc. This is kind of a half way house between option 2 and option 3. In the past we tried to set-up a Sourceforge project for this, but it was rejected as the project would not generate program code. I will offer the Burrokeet project on SF since this uses Forrest at its core so the housing of Forrest skins is appropriate within that project. I do not have any problems adding skin contributors to that project to ensure they have commit access. Of course, there may be other projects that are appropriate. --- Whatever we do, we should encourage the use of skin packages and we should extend the system to list "official" skins in the same way the plugin system does, see http://forrest.apache.org/0.7/docs/plugins/index.html Comments, ideas? Ross
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
David Crossley wrote: > If you tell the list what your general aim is then > we can see what any legal issues might be. We can also > seek help from the Apache "legal-discuss" mailing list. It is actually quite simple to describe: I want to donate the concept for the English language version of our book to Apache while keeping all the rights for the German version to avoid any conflicts or problems with my publishers. The (potential) problem is that in the publishing world you can license the right to publish different language versions separately (e.g. to different publishers) but I'm not sure if that works with the Apache license. -- Ferdinand Soethe
please choose sensible subject titles
Would people please take care when choosing titles for email threads. We need to be able to find and refer to discussions at a later date. --David
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
Ferdinand Soethe wrote: > > I just took another look at the legalese and realized that I have not > idea what the implication in such a case would be. So I'll try and > modify the concept enough for us to work with it w/o any copyright > problems. If you tell the list what your general aim is then we can see what any legal issues might be. We can also seek help from the Apache "legal-discuss" mailing list. Basically you would be contributing something under your Contributor License Agreement (CLA) http://www.apache.org/licenses/#clas and it would be distributed under the Apache License 2.0 http://www.apache.org/licenses/ --David
Re: Lenya and forrest integration
Ross Gardler wrote: Gregor J. Rothfuss wrote: Thorsten Scherler wrote: ... What do both projects think which one should become the main app (lenya or forrest)? that's a funny question :) afaik forrest has no workflow, user management etc, so if you need those, the answer would be pretty clear. I think the question is "should Lenya become a Forrest plugin or vice-versa". This is an important question because whichever is the "main app" would have the ability to override functionality of the other. For my case I chose for the CMS to run separately from the publication engine (Forrest) and only integrate at the publication level. This makes the CMS a plugin for Forrest. The advantage of this way around is that it allows multiple CMS systems to provide content for multiple Forrest based sites. On the other hand, if Forrest is embedded into Lenya as a presentation engine I suspect you would only be able to use a single instance of Lenya as a source for content. Whether this is a disadvantage or not depends on the use case, for my own it is a problem. If you need WYSIWYG browsing and editing in Lenya, I guess you'll have to use Forrest (or parts of it) as a presentation engine. Actually it was a design goal of Lenya to support (virtually) arbitrary Cocoon-based sites as presentation engines, but of course this by far not possible. My first idea would be to create a Forrest publication template [1] which would support at least a subset of Forrest's rendering possibilities and allow to add and edit documents (document-vXX, faq-vXX etc.). The question is how to get Forrest to work as a Lenya publication, not as a webapp on its own. Yesterday I did some experiments, but ran into problems because the file system paths are not compatible. I'll do some more investigation when I find the time. Another way would be a publication template with a custom rendering engine able to present Forrest documents in a basic, stripped-down way, together with a simple navigation tree. That would probably be sufficient to maintain a documentation website. The drawback would be that you don't have WYSIWYG and miss some features, the advantage is the low implementation entry barrier. [1] http://lenya.apache.org/1_4/reference/publication-templating/index.html -- Andreas
[JIRA] Commented: (FOR-514) Do not limit status.xml contexts in project info plugin
The following comment has been added to this issue: Author: Cyriaque Dupoirieux Created: Wed, 1 Jun 2005 8:45 AM Body: Good Ross, I can work on it with your idea : And I will send a patch. By the way, I could not - in my previous comment - send a patch because the issue were closed... (that's why I send a code sample in the text...) - View this comment: http://issues.cocoondev.org//browse/FOR-514?page=comments#action_12462 - View the issue: http://issues.cocoondev.org//browse/FOR-514 Here is an overview of the issue: - Key: FOR-514 Summary: Do not limit status.xml contexts in project info plugin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Plugin: projectInfo Assignee: Reporter: Ross Gardler Created: Wed, 1 Jun 2005 6:02 AM Updated: Wed, 1 Jun 2005 8:45 AM Description: (This comment brought over from FOR-487) This improvement of changes page is nice. I have my own version based on xsl:key definition in order to be able to simply manage as many contexts as you can define (My Dtd is not limited to "build|docs|code|admin|design". The advantage - on my opinion - is that my own contexts are very various and not developpement oriented nor language dependant. here a short example - using releaseNote... : http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html The following code replace the 5 blocks : Version () + + + + + + + + + + + Hope you'll like the idea... Regards, Cyriaque, - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
I just took another look at the legalese and realized that I have not idea what the implication in such a case would be. So I'll try and modify the concept enough for us to work with it w/o any copyright problems. -- Ferdinand Soethe
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
David Crossley wrote: > Actually Ferdinand, this discussion should be happening on the dev list. Fine by me. Here it is. > Ferdinand Soethe wrote: >> As you might know Ross and I have put considerable time into working >> on a chapter structure for a book on Single Source Publishing with >> Forrest. Since we didn't follow through with the project (there will >> only be a German book) we are prepared to donate this structure (more >> precisely: the rights to this concept for an English publication) as a >> basis for the Forrest documentation project. > Not sure what your mean by "rights to this concept". See the Apache License > 2.0 The rights to the concept for a book are similar to the rights to the book itself. And so I have to make clear that I/we are donating the rights to this concept in the English language version to Apache while I cannot do the same for the German version which is to become a published book (and rather similar). If that is a problem we can probably not do this without talking to the publisher. > We can sure study it, but we need comments to come back to this mailing list. > We can't have design discussions shut away in separate documents. Well, I didn't see structuring of help as a design issue but I guess it is. I was just thinking that it might be a pain to work on such a large and structured document in ASCII-Text. -- Ferdinand Soethe
Re: Meetup at ApacheCon? --> Room nearby!
David Crossley wrote: > Yes. Will you start the "events" web page? I could knock one up quickly > if you would rather. Yes, pls go ahead if you can do it quickly. Id rather get the documentation issue solved asap. -- Ferdinand Soethe
Re: Meetup at ApacheCon? --> Room nearby!
Ferdinand Soethe wrote: > > I'd be happy to stick with this as Tuesday will be the night before > Ross and I have our Forrest presentation and I'd like to have some > time for last minute preparations. > > And since nobody else voiced any objections until now, I guess we can > call this a final schedule and make it public, can we? Yes. Will you start the "events" web page? I could knock one up quickly if you would rather. --David
[JIRA] Commented: (FOR-514) Do not limit status.xml contexts in project info plugin
The following comment has been added to this issue: Author: Ross Gardler Created: Wed, 1 Jun 2005 6:07 AM Body: In one sense you change is a big improvement on my original code. However, it prevents the ability to add a meningful title to each section since the title becomes the value of the context attribute. Perhaps we can provide an (optional) lookup table in the status.xml file that will give a title, for example: ... If no entry is found for //actionContexts/[EMAIL PROTECTED]"CONTEXT"] then we would use the @id value in titles otherwise we would use //actionContexts/[EMAIL PROTECTED]"CONTEXT"]/@description In later versions this would allow for internationalisation of the status contexts. WDYT? [NB try to submite changes as patched, it makes it much easier for us to apply and therefore increases the chance of it being applied in a timely fashion. If you don't know how ask us on the dev list.] - View this comment: http://issues.cocoondev.org//browse/FOR-514?page=comments#action_12460 - View the issue: http://issues.cocoondev.org//browse/FOR-514 Here is an overview of the issue: - Key: FOR-514 Summary: Do not limit status.xml contexts in project info plugin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Plugin: projectInfo Assignee: Reporter: Ross Gardler Created: Wed, 1 Jun 2005 6:02 AM Updated: Wed, 1 Jun 2005 6:07 AM Description: (This comment brought over from FOR-487) This improvement of changes page is nice. I have my own version based on xsl:key definition in order to be able to simply manage as many contexts as you can define (My Dtd is not limited to "build|docs|code|admin|design". The advantage - on my opinion - is that my own contexts are very various and not developpement oriented nor language dependant. here a short example - using releaseNote... : http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html The following code replace the 5 blocks : Version () + + + + + + + + + + + Hope you'll like the idea... Regards, Cyriaque, - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Commented: (FOR-487) generate announcement text from the status.xml
The following comment has been added to this issue: Author: Ross Gardler Created: Wed, 1 Jun 2005 6:02 AM Body: I've moved this to a new issue as this one has been closed, see FOR-514. - View this comment: http://issues.cocoondev.org//browse/FOR-487?page=comments#action_12459 - View the issue: http://issues.cocoondev.org//browse/FOR-487 Here is an overview of the issue: - Key: FOR-487 Summary: generate announcement text from the status.xml Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Project: Forrest Components: Plugins (general issues) Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Ross Gardler Reporter: David Crossley Created: Wed, 27 Apr 2005 11:23 PM Updated: Wed, 1 Jun 2005 6:02 AM Description: By adding some attributes to the "actions" in status.xml we would be able to use certain entries for the announcement text. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Created: (FOR-514) Do not limit status.xml contexts in project info plugin
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-514 Here is an overview of the issue: - Key: FOR-514 Summary: Do not limit status.xml contexts in project info plugin Type: Improvement Status: Unassigned Priority: Minor Project: Forrest Components: Plugin: projectInfo Assignee: Reporter: Ross Gardler Created: Wed, 1 Jun 2005 6:02 AM Updated: Wed, 1 Jun 2005 6:02 AM Description: (This comment brought over from FOR-487) This improvement of changes page is nice. I have my own version based on xsl:key definition in order to be able to simply manage as many contexts as you can define (My Dtd is not limited to "build|docs|code|admin|design". The advantage - on my opinion - is that my own contexts are very various and not developpement oriented nor language dependant. here a short example - using releaseNote... : http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html The following code replace the 5 blocks : Version () + + + + + + + + + + + Hope you'll like the idea... Regards, Cyriaque, - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Commented: (FOR-487) generate announcement text from the status.xml
The following comment has been added to this issue: Author: Cyriaque Dupoirieux Created: Wed, 1 Jun 2005 5:34 AM Body: This improvement of changes page is nice. I have my own version based on xsl:key definition in order to be able to simply manage as many contexts as you can define (My Dtd is not limited to "build|docs|code|admin|design". The advantage - on my opinion - is that my own contexts are very various and not developpement oriented nor language dependant. here a short example - using releaseNote... : http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html The following code replace the 5 blocks : Version () + + + + + + + + + + + Hope you'll like the idea... Regards, Cyriaque, - View this comment: http://issues.cocoondev.org//browse/FOR-487?page=comments#action_12458 - View the issue: http://issues.cocoondev.org//browse/FOR-487 Here is an overview of the issue: - Key: FOR-487 Summary: generate announcement text from the status.xml Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Project: Forrest Components: Plugins (general issues) Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Ross Gardler Reporter: David Crossley Created: Wed, 27 Apr 2005 11:23 PM Updated: Wed, 1 Jun 2005 5:34 AM Description: By adding some attributes to the "actions" in status.xml we would be able to use certain entries for the announcement text. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Meetup at ApacheCon? --> Room nearby!
Ferdinand Soethe wrote: And since nobody else voiced any objections until now, I guess we can call this a final schedule and make it public, can we? +1 Ross
Re: Meetup at ApacheCon? --> Room nearby!
I'd be happy to stick with this as Tuesday will be the night before Ross and I have our Forrest presentation and I'd like to have some time for last minute preparations. And since nobody else voiced any objections until now, I guess we can call this a final schedule and make it public, can we? Regards, Ferdinand Soethe David Crossley wrote: > Here is the current schedule: > > Tuesday 19 July > Event: Apache Committers Hackathon > Time: all day > Location: ApacheCon > Event: Meeting of usability professionals (Johannes) > Time: 19:00 until 20:30 > Location: HfT > > Wednesday 20 July > Event: ApacheCon Session WE16 (Ross and Ferdinand) > Time: 14:30 until 15:30 > Location: ApacheCon > Event: Apache Forrest get together > Time: 20:00 until whenever > Location: HfT > > Thursday 21 July > Event: Apache Forrest project workshop > Time: 20:00 until whenever > Location: HfT > -- Ferdinand Soethe
Re: Meetup at ApacheCon? --> Room nearby!
Johannes Schaefer wrote: > David Crossley schrieb: > >Is your event open to other other German-speaking people > >or do you want to limit it to your group? I ask because > >we might create an "Events" page at the Forrest website. > > It *is* open. It's just an informal meeting of interested > people. German speakers can find more information here > http://www.gui-design.de/ak/ > although the July meeting isn't there, yet (And I discovered > that it actually starts at 18:30 ;-) > > >Does your meeting usually finish and then people leave? > > No. Usually we sit together afterwards to have some beer. Of course, that is the answer that i expected. > >So it seems that we are back to the original plan. > >Here is the current schedule: > > If there's agreement on this schedule, I'll check back with > Peter Schaub. Wait until Ferdinand is back tomorrow and until the others verify that this is what we want. Thanks again for organising the room. --David
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
David Crossley wrote: > If we give people too much rope, then they can hang > themselves. ... and we'll get caught in their noose trying to maintain the code base ... -- Ferdinand Soethe
Re: Meetup at ApacheCon? --> Room nearby!
David Crossley schrieb: Johannes Schaefer wrote: I will have a presentation about Forrest in German that day (Tue, 19th July), also at the HfT, also starting at 19h. Ferdinand wanted to go there, too. This will last for about 1-1.5 hours. I'll check back about the room (I asked for the conference days 20-22, which was OK by Peter). I am very sorry Johannes, that completely slipped my mind. Is your event open to other other German-speaking people or do you want to limit it to your group? I ask because we might create an "Events" page at the Forrest website. It *is* open. It's just an informal meeting of interested people. German speakers can find more information here http://www.gui-design.de/ak/ although the July meeting isn't there, yet (And I discovered that it actually starts at 18:30 ;-) Does your meeting usually finish and then people leave? No. Usually we sit together afterwards to have some beer. If so, then perhaps our project workshop could start after that. Anyway, we don't want to put any pressure on you or your meeting. So that option is removed below. On one hand, it would be better for our project workshop to be held earlier in the week, preferably before the Get Together, so that we have our story straight regarding Views and XHTML2 core. (The committers can do some of that at the Hackathon during the day on Tuesday.) On the other hand, later is better because we can have a wider audience and also take into account the use-cases expressed at the earlier sessions. Another reason for doing it later is that the sessions then progress from easier topics to more complex. I now think that we should dispense with the option of an ApacheCon Birds of a Feather (BoF) session. I was trying to ensure that we don't divert attention away from ApacheCon. So it seems that we are back to the original plan. Here is the current schedule: If there's agreement on this schedule, I'll check back with Peter Schaub. Thanks to David for putting this together so nicely! Johannes Tuesday 19 July Event: Apache Committers Hackathon Time: all day Location: ApacheCon Event: Meeting of usability professionals (Johannes) In German: details see below. Time: 18:30 until 20:00 !! Time changed Location: HfT Wednesday 20 July Event: ApacheCon Session WE16 (Ross and Ferdinand) Time: 14:30 until 15:30 Location: ApacheCon Event: Apache Forrest get together Time: 20:00 until whenever Location: HfT Thursday 21 July Event: Apache Forrest project workshop Time: 20:00 until whenever Location: HfT DRAFT Titel: Technische Dokumentation mit Apache Forrest Abstract: Styleguides und andere Technische Dokumente stellen uns vor immer mehr Herausforderungen: - Mehrere Personen arbeiten an demselben Dokument: Usability-Experten, Designer, technische Autoren, Entwickler, ... - Die Leser erwarten ein Dokument im Intranet: immer aktuell, leicht verfügbar, hübsch "gestyled" und "usable". - Es ist eine (identische) Druckversion/PDF nötig, die in Datenbanken abgelegt wird. Mit Apache Forrest (forrest.apache.org) steht ein freies Publikationswerkzeug zur Verfügung, das einen hierbei unterstützt. Basierend auf Standards wie XML und HTML, kann mit Forrest aus verschiedenen Quelldokumenten (z.B. XML, DocBook, OpenOffice) eine einheitliche Ausgabe (z.B. in HTML und PDF) erzeugt werden. Im Vortrag stelle ich Apache Forrest vor und berichte über unsere Erfahrungen beim Schreiben von Styleguides. - Was ist Forrest und wie funktioniert es? Vor-/Nachteile. - Wie schreibt man die Inhalte? - Wie kann ich bestehende Dokumente übernehmen? - Wie kann man das Erscheinungsbild dem Kunden anpassen? - Wie kann man komplexe Dokumente strukturieren? -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
