Re: [RT] Accepting and managing Skin Packages
On Thu, 2005-06-02 at 15:49 +1000, David Crossley wrote: Ross Gardler wrote: snip 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. IMO the only thing that we can and should accept is the CSS of Claudia. Skins (old fashion - the ones we have right now) are horror for maintainment (and there are only few that really maintain them). More so if they change common skin stylesheets. Per definition the result of a skin is a html skeleton that contains css markup and features. Features of skins are contracts. A skin provider can decide which contracts to offer (Claudia stated that they riped parts out of the skin). Now using this beautiful skin of her would mean we have to add this parts again and create a new old fashion skin. That leads to an endless circle of work on old fashion skins. IMO we should focus to implement views and not adding more (endless) work with old fashion skins. In views Claudia would provide a default.fv, the default.css and a couple of new contracts (if needed, which can either override the common ones by providing new implementations of them or providing new contracts), which all are easily maintainable. I am -1 for dedicating any energy on old fashion skins that are in my eyes a dead end. It makes more sense to finish views and address the skin package facility for views. snip 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 address many skin needs, yet we are finding time to revisit the skins situation. Yeah, you hit the nail on the head. IMO we should *not* encourage the use of skin packages but rather the development and usage of views. I started views firstly only to address skin needs. That means we are splitting our resources apart where we should bundle them by talking about and encouraging the outdated old fashion skins. ...and sure you only can encourage something that you have reviewed. Just my 2 cents. -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [RT] Accepting and managing Skin Packages
On Thu, 2005-06-02 at 10:08 +0100, Ross Gardler wrote: snip/ I should have made the subject attracting skins/views developers through skin-packages Thorsten, does this make any sense or am I going down a dead end here? IMO part 1 no, part 2 yes. View development is different from skin development this is why I think we will hardly attract new view devs through skin-packages. We only will have more work but hardly any benefit out of it. That is my *personal* opinion. salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: [RT] Accepting and managing Skin Packages
Thorsten Scherler wrote: IMO the only thing that we can and should accept is the CSS of Claudia. Skins (old fashion - the ones we have right now) are horror for maintainment (and there are only few that really maintain them). More so if they change common skin stylesheets. I'd like to talk about 'making available' rather than 'accept' here to make it clear that Forrest Project is not responsible or has to maintain these skins. But having said that, I suggest that we leave that decision up to the people wanting to look at and use that skin? If at some point they find that this skin does not follow Forrest's improvements anymore, they can still opt out of using it. Per definition the result of a skin is a html skeleton that contains css markup and features. Features of skins are contracts. A skin provider can decide which contracts to offer (Claudia stated that they riped parts out of the skin). Now using this beautiful skin of her would mean we have to add this parts again and create a new old fashion skin. That leads to an endless circle of work on old fashion skins. I don't see why we have to do any of that. Just add a short disclaimer the way Claudia did and let people make up their own mind about it. IMO we should focus to implement views and not adding more (endless) work with old fashion skins. In views Claudia would provide a default.fv, the default.css and a couple of new contracts (if needed, which can either override the common ones by providing new implementations of them or providing new contracts), which all are easily maintainable. I am -1 for dedicating any energy on old fashion skins that are in my eyes a dead end. Great! If that is so, then Claudia and other people wanting to use that skin will probably go for it as soon as views is stable and available. Pls. try to look at it from a users point of view. People who want/need a nice design now cannot not use views (alpha) at such an early stage for a production site. And if they work on tweaking pelt to look that way it will probably take a lot more time than using or improving Claudia's skin. So can we please not stand in the way of these people? -- Ferdinand Soethe
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
David Crossley wrote: 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 Actually, in my opinion there is no conflict or discussion. Certainly I do not consider that there is any financial value in my small contribution to this concept that Ferdinand is trying to assign the rights to. I am thoroughly confused by the discussion and can only assume that it is a potential issue with the German publishers. What Ferdinand is proposing to donate to Forrest is just the outline of a book. About half of this book is of no interest to a documentation effort within Forrest and I doubt we, as a community would develop those chapters, we would rip them out as not relevant (e.g. history of WYSIWYG, why WYSIWYG is no good for many jobs, alternatives to WYSIWYG, XML basics, XSLT basics that kind of thing). If we strip out all these chapters what is left is an outline for a few chapters documenting how to work with Forrest. I stress *outline* there is nothing, in my opinion, of any intellectual value in this document, only a structure for a set of documentation files for Forrest. In other words, something that, if we were to look back through our archives, would have existed *before* the chapter outlines were written. In my opinion what should happen is that the relevant chapter outline should be ripped out of the proposal and put into SVN as XHTML documents that we can point to via an URL to SVN. With our recent influx of offers for help on beginner documentation this would provide a starting framework for work to begin. However, Ferdinand, I am not a lawyer, if you are concerned about your German publishers response to this then you should discuss it with them. Once you have a clear response from them then ask the relevant questions in the ASF Legal Discussion mailing list as David suggests. Ross
Re: How to avoid hard-coding site-visible message strings in skin files
Pedro I. Sanchez wrote: 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: i18n lang=en token name=lastPublished value=Last Published/ token name=copyright value=Copyright/ /i18n i18n lang=?? token name=lastPublished value=???/ token name=copyright value=???/ /i18n This would work for me as long as I can also specify the language manually with something like i18n lan=en / I'm not sure how the existing i18n thing works, but there is a way to specify what language you want the menus in, so I guess you would use the same mechanism. 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: skinlabels name=pelt keyword name=lastPublished value=???/ keyword name=copyright value=???/ /skinlabels I don't see the value in this. I would imagine that regardless of what skin you are using you would want the same values to appear in the output site. One thing we must be sure of is that any solution implemented now can be integrated into Thorstens work on views. In fact, it would be better to see these changes go directly into views. Thorsten, what would the equivalent to the above be in views? Ross
Re: [RT] Accepting and managing Skin Packages
Thorsten Scherler wrote: On Thu, 2005-06-02 at 10:08 +0100, Ross Gardler wrote: snip/ I should have made the subject attracting skins/views developers through skin-packages Thorsten, does this make any sense or am I going down a dead end here? IMO part 1 no, part 2 yes. View development is different from skin development this is why I think we will hardly attract new view devs through skin-packages. We only will have more work but hardly any benefit out of it. That is my *personal* opinion. OK. I'll cease and dissist your *personal* opinion is all that counts on views right now since we don't know them well enough yet. Ross
Re: [RT] Accepting and managing Skin Packages (was Re: Forrest Example Sites)
Note: Perhaps I also have a slightly different view on this in the sense that I'm not aiming at building and maintaining a collection of skins but would rather like to have a quick and easy way to see and learn about other people's skins. And although I'm not opposed to working with them on improving their skin, I'd like to make that first step very easy. My comments below reflect this intention. Ross Gardler wrote: I think Forrest should accept your skin package in one form or another, +1 I'd like to ask Claudia to upload her skin into the issue tracker (or make it available on their website) so that interested people can - look at it - understand it - work with her to improve it - use it for their own projects While this is happening there is plenty of time to deal with any concerns and work out the general solution. 1. Forrest accepts the skin and keeps it in SVN I agree for all the reasons you mentioned. 2. We make all non-core skins available via a skins sub project within Forrest 0 Because I don't think that the benefits will balance the administrative overhead involved. And - see below - I think we should minimize the effort required by anyone wanting to donate their skins. 3. The skin author makes it available via a ZIP download using the skin-package system I don't think that this is such a bad solution - it is easy for the donator (they don't have to learn about our versioning systems or get a committer account) which might encourage more people to make their skin designs available to others. - the donator maintains full control over changes and releases. If people don't like that, they can always create a skin of their own from the downloaded package. - it is very clear that Forrest is not maintaining that package. 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. I can see your concern. On the other hand I think that it would make people work more closely with the donator of the skin because they would be the ones who have to understand and implement changes. (Which does not mean that these discussion have to or should happen Off-List!) 4. The skin author donates the skin to an external Open Source project and uses that projects CVS/SVN etc. -1 This I think would make the issue far too complicated and will discourage people from donating skins for sure. Whatever we do, we should encourage the use of skin packages and we Or at least encourage people to make them available to learn from them. David wrote: Concentrate our energy on developing one very useful skin. True. This is the impression I had from the recent discussions on this. 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. I'm all with you on this in principle. Though when I think about details, three more considerations come to my mind: - trying to adapt pelt to address all needs might make use and maintenance a very complex issue (if we are not talking about moving or hiding certain elements). We might reach a point where different simple skins might be easier to maintain (also because it can be done by people on an entry level understanding). - Skins like Claudia's will likely be maintained as long as her company uses Forrest. So spending a lot of resources on integrating these functionalities with pelt might be nice from an architectural point of view, as far as resources are concerned it might not make so much sense since the resources saved on maintaining their skin will probably not go towards Forrest. So I'd rather accept a donation of a well done and well maintained skin. - Even if Pelt integrates all functionalities, there is still the issue of styling. If styling is completely configurable we'd need a new repository of styles because a lot of work goes into making the skin look good with colors, fonts, sizes etc. And not all styles fit all purposes. We have tried to encourage this option, but few people are interested. or able! For my skin design is still something I hesitate to tackle. Discussing other peoples solutions on list might help me and others learn more about it ... 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. -1 Until 'views' is available it would really help to make other peoples skins available. As doing so would open Forrest to a whole lot of people who do not have developer skills but might be able to convince their management to fund development if they can demo a great looking site like Claudia's. It might not be the
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
Ross Gardler wrote: I am thoroughly confused by the discussion and can only assume that it is a potential issue with the German publishers. Correct. What Ferdinand is proposing to donate to Forrest is just the outline of a book. About half of this book is of no interest to a documentation effort within Forrest and I doubt we, as a community would develop those chapters, we would rip them out as not relevant (e.g. history of WYSIWYG, why WYSIWYG is no good for many jobs, alternatives to WYSIWYG, XML basics, XSLT basics that kind of thing). If we strip out all these chapters what is left is an outline for a few chapters documenting how to work with Forrest. I stress *outline* there is nothing, in my opinion, of any intellectual value in this document, only a structure for a set of documentation files for Forrest. In other words, something that, if we were to look back through our archives, would have existed *before* the chapter outlines were written. So it might be easiest to just take a fresh start and assemble the outline from scratch rather than spending more time on this discussion or research. In my opinion what should happen is that the relevant chapter outline should be ripped out of the proposal and put into SVN as XHTML documents that we can point to via an URL to SVN. With our recent influx of offers for help on beginner documentation this would provide a starting framework for work to begin. Fine by me. My second proposal was to take that finished outline and create menuitems on the Forrest Website for it (under a new Manual tab). which means add something like this to site forrestmanual href= tab=Forrest Manual installForrest href=/ compileForrest href=/ ... ForrestPlugins href= PluginConcept href= InputPlugins href= ... /ForrestPlugins ... /forrestmanual The hrefs would be pointing to either - finished pages or - pages that have just the abstract of that chapter (written during outline-design) and explain that this chapter still needs someone to write it and instructions on how to do that. The goal is to give potential contributors some guidance on what is missing what that chapter is all about and how their contribution would fit into the finished manual. -- Ferdinand Soethe
Re: does checksums-uri in cli.conf work?
Ross Gardler wrote: Probably faster to try turning it on than for someone to type a reply (I don't know the answer by the way). My question was more about hidden side effects that I wouldn't find through trial and error. But since nobody seems to know I'll just try. -- Ferdinand Soethe
Re: Lenya and forrest integration
Andreas Hartmann wrote: 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. I believe you are going about this the wrong way. Why tie Forrest into Lenya or vice-versa? You will make maintenance difficult since your will have to keep the integration in synch on both sides. What do I suggest incited? Well, your second proposal actually: 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. Have Forrest request an unskinned version of the document to be published from Lenya, and only use Forrest as a *publication* engine, do not try and integrate it into the editing infrastructure. Stick with what you have from the editing perspective. It is possible to embed editors into Forrest pages, but why bother? The editor does not want to see the end result, they want the cleanest simplest editing environment. This environment should be optimised for their needs. Lenya does a great job of this already. How do you get from a page in Forrest to the edit screen in Lenya. Do it the simple way, provide an edit link on the page that takes you back to the Lenya editing environment. The advantages of doing things this way is that you can publish content from multiple, distributed Lenya repositories as well as from multiple other types of repositories, Daisy integration is underway and we may have someone working on Slide integration soon. The way to achieve this is through locationmaps. See http://marc.theaimsgroup.com/?l=forrest-devm=111770641922349w=2 for an outline of how this works. With respect to the disadvantages you highlight. You don't have WYSIWYG but you do get WYSIWYM (M = mean), which in my opinion is far more important. Your other disadvantage is you miss some features. what are they, if they are common CMS features then we should find a way of getting them into a common repository plugin. Ross [1] http://lenya.apache.org/1_4/reference/publication-templating/index.html -- Andreas
Students: work on Apache Forrest and earn US$4500
The Apache Software Foundation is a proud partner of Google Summer of Code initiative (http://code.google.com/summerofcode.html). The Summer of Code is a program designed to introduce students to the world of Open Source Software Development and provide them with a $4500 award for completing an Open Source project before the end of Summer. The Apache Forrest project currently has one project proposal as part of the Summer of Code, more may be added later. For details see http://wiki.apache.org/general/SummerOfCode2005#forrest-voice The deadline for application is June 14th so if you are interested you need act quickly. Competition is very high for these projects, but then so are the rewards. The Apache Forrest Team
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
Ferdinand Soethe wrote: Ross Gardler wrote: ... In my opinion what should happen is that the relevant chapter outline should be ripped out of the proposal and put into SVN as XHTML documents that we can point to via an URL to SVN. With our recent influx of offers for help on beginner documentation this would provide a starting framework for work to begin. Fine by me. My second proposal was to take that finished outline and create menuitems on the Forrest Website for it (under a new Manual tab). ... - finished pages or - pages that have just the abstract of that chapter (written during outline-design) and explain that this chapter still needs someone to write it and instructions on how to do that. This is a good idea, but I recommend we wait on this second proposal until we have the 0.8 docs in place. This will happen immediately after the 0.7 release. I propose this because there will be very little content, and therefore very little value for the 0.7 release. The goal is to give potential contributors some guidance on what is missing what that chapter is all about and how their contribution would fit into the finished manual. We can do that in the meantime by pointing them to the viewSVN page (that's why I propose using XHTML since they will see a rendered page there). Ross
Re: documentation additions and issue tracking (Was: App vs Data) [moved from user list]
Ross Gardler wrote: This is a good idea, but I recommend we wait on this second proposal until we have the 0.8 docs in place. This will happen immediately after the 0.7 release. I propose this because there will be very little content, and therefore very little value for the 0.7 release. Sure. I don't think we'll have a finished outline until then anyway. -- Ferdinand Soethe
Summer of Code proposals
As all committers will now know Apache is a mentoring organisation in Googles Summer of Code initiative. I have already submitted (and received interest in) a proposal to build voice plugins for Forrest. However, there is plenty of scope for other proposals. The idea is that the student be mentored by a committer on the project. The mentor is supposed to help the student learn the ways of Open Source development and to ensure there is someone to guide them in the development process. However, they are not on their own, all design discussion is to be held in the normal community way, so the student should gain the support of the community as a whole. As I see it, the mentor is someone who guarantees to read and respond to the students communications, whilst other committers play their normal role of only piping up if they have an interest. I am willing to consider being a co-mentor on any projects submitted by the Apache Forrest project. So if anyone has any ideas and priorities - views perhaps. I have the time to spend on key projects within Forrest, so if there is anyone with not quite enough time to commit to being a mentor I will assist (I stress assist, I do not want to be lumbered with full mentorship, I already have one project and one co-mentored project). The first stage is to attract students to the project by adding a brief outline to http://wiki.apache.org/general/SummerOfCode2005 The second stage is to work with any interested students to create a full project proposal. Note competition is high for the Google sponsored projects, but the output of making a submission is a clear project proposal which will be a useful design document for Forrest. Ross
Re: [JIRA] Created: (FOR-505) Allow the retrieval of raw html files
Ferdinand Soethe wrote: Ross Gardler wrote: Anyway, +1 for implementing it instead of the skinHTMLSources=true workaround. Pardon my ignorance but is this A third possibility that is a marrying of the two is elements in site.xml to make it much more like the Ant fileset idea, like this: !-- everything in old_site directory -- rawContent dir=/old_site/**/ !-- everything in 0.6_docs, except the forums -- rawContent dir=/0.6_docs/** exclude name=forums/**/ /rawContent !-- everything in 0.6_docs, except all files in forums except the index.html file -- rawContent dir=/0.6_docs/** exclude name=forums/**/ exclude name=forums/**/index.html/ /rawContent This leaves site.xml easily readable, allows such content to be provided in an external file if there is no way of generating it from another type of site descriptor file and allows us to describe pages not linked to in site.xml. what we are going to implement now? Yes, if the concept can be brought to a working design. Of course that is the hard part. And if so, what would it look like if I had raw content in more than one branch? For example could I have rawContent dir=/old_site_1/**/ rawContent dir=/old_site_2/**/ Just add an element for each of the matches that represent raw content, each with its own include and exclude patterns. And would I still have an additional separate entry in the sitemap to have /old_site_1/index.htm on the menu or would this have to be within the rawContent element. Do you mean would I still have an additional separate entry in the *skins.xml*? If so, yes, there would be no need to change any other functionlaity in Forrest. What would happen is that when we receive a request for /old_site_1/** the sitemap would first look in the config to see if it is raw content. If it is it would read the content and serve it. If it isn't processing would proceed as normal. When I find the time I'll write up a proposal about how to implement this. Ross
Re: [RT] Accepting and managing Skin Packages (was Re: Forrest Example Sites)
Hi! I drop in for Claudia here, since I did most of the skin modification stuff for the website myself. But yes, Claudia is reading this as well. First of all: The modification of common skin elements is definitly reversable as already pointed out by several people here. It was done the way it is to have a smaller patchset, were changes are more obvious to spot in our CVS diffs (For the inquiring mind: We changed the default cellspacing for 'ForrestTable' and added images to the tab-menu items). Secondly: IMHO this is not a new skin but more of a showcase what can be achieved by modifying an existing skin like in this case, pelt. Pelt (as of 0.6) doesn't gave enough configuration leeway to reach the visual effects we wanted to, so we practically branched from there and molded it to our needs. As Claudia already pointed out, most work done on pelt was rather destructive (disabling/removing features we didn't need/like/got in the way) than constructive. So in conclusion: I don't see our work as a new 'skin'. It is too narrow and specialised for that to be in it's current state. Then again it might serve as a showcase on *what* visuals can be achieved and especially *how* they may be achieved. Regards, Torsten Ferdinand Soethe wrote: Note: Perhaps I also have a slightly different view on this in the sense that I'm not aiming at building and maintaining a collection of skins but would rather like to have a quick and easy way to see and learn about other people's skins. And although I'm not opposed to working with them on improving their skin, I'd like to make that first step very easy. My comments below reflect this intention. Ross Gardler wrote: I think Forrest should accept your skin package in one form or another, +1 I'd like to ask Claudia to upload her skin into the issue tracker (or make it available on their website) so that interested people can - look at it - understand it - work with her to improve it - use it for their own projects While this is happening there is plenty of time to deal with any concerns and work out the general solution. 1. Forrest accepts the skin and keeps it in SVN I agree for all the reasons you mentioned. 2. We make all non-core skins available via a skins sub project within Forrest 0 Because I don't think that the benefits will balance the administrative overhead involved. And - see below - I think we should minimize the effort required by anyone wanting to donate their skins. 3. The skin author makes it available via a ZIP download using the skin-package system I don't think that this is such a bad solution - it is easy for the donator (they don't have to learn about our versioning systems or get a committer account) which might encourage more people to make their skin designs available to others. - the donator maintains full control over changes and releases. If people don't like that, they can always create a skin of their own from the downloaded package. - it is very clear that Forrest is not maintaining that package. 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. I can see your concern. On the other hand I think that it would make people work more closely with the donator of the skin because they would be the ones who have to understand and implement changes. (Which does not mean that these discussion have to or should happen Off-List!) 4. The skin author donates the skin to an external Open Source project and uses that projects CVS/SVN etc. -1 This I think would make the issue far too complicated and will discourage people from donating skins for sure. Whatever we do, we should encourage the use of skin packages and we Or at least encourage people to make them available to learn from them. David wrote: Concentrate our energy on developing one very useful skin. True. This is the impression I had from the recent discussions on this. 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. I'm all with you on this in principle. Though when I think about details, three more considerations come to my mind: - trying to adapt pelt to address all needs might make use and maintenance a very complex issue (if we are not talking about moving or hiding certain elements). We might reach a point where different simple skins might be easier to maintain (also because it can be done by people on an entry level understanding). - Skins like Claudia's will likely be maintained as long as her company uses Forrest. So spending a lot of resources on integrating these functionalities with pelt might be nice from an architectural
Re: [JIRA] Created: (FOR-505) Allow the retrieval of raw html files
Ross Gardler wrote: And would I still have an additional separate entry in the sitemap to have /old_site_1/index.htm on the menu or would this have to be within the rawContent element. Do you mean would I still have an additional separate entry in the *skins.xml*? Sorry, I was writing bullshit. Of course I meant And would I still have an additional separate entry in the site.xml to have /old_site_1/index.htm on the menu or would this have to be within the rawContent element. But your reply has already made this clear this: I do need to reference a file to show it one a menu since rawcontent will only provide the processing hints. Thanks -- Ferdinand Soethe
Re: [JIRA] Created: (FOR-505) Allow the retrieval of raw html files
Ferdinand Soethe wrote: Ross Gardler wrote: And would I still have an additional separate entry in the sitemap to have /old_site_1/index.htm on the menu or would this have to be within the rawContent element. Do you mean would I still have an additional separate entry in the *skins.xml*? Sorry, I was writing bullshit. Of course I meant LOL - so was I, at least we understood what we intended to say! Ross
Re: Fussy feelings about 0.7
David Crossley wrote: Thorsten Scherler wrote: Ross Gardler wrote: Thorsten Scherler wrote: Hello all, as more mails I read (mainly from Ross and David) as more I get a fussy feelings in my stomach about the 0.7. Sure we want to get the 0.7 out the door but it seems there are some *big* bugs that need solutions. On the other hand this solutions will be changed again in 0.8. Care to highlight them, I'm not aware of any, with the exception of the raw html issue, for which I already proposed, what I think is a suitable fix. I had the raw html issue in mind but like you stated you already proposed a fix. That is certainly a problem. Ross' proposed solution sounds good. See discussion at: http://marc.theaimsgroup.com/?t=11169681410 The issue is documented at http://issues.cocoondev.org/browse/FOR-505 It is not yet scheduled for fixing for 0.7 release. IMO we should think again about the release and how we want to do it. WDYT? I think if there are any remaining issues you want to see fixed you should fix them ;-) I will try to help in the next days. Is there a to do list or do I use the bug tracker directly? We are not in a code freeze yet. Ross wrote 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 and in another thread When I find the time I'll write up a proposal about how to implement this. So I guess the outcome of the 'fuzzy' debate is that this issue is a blocker and we will delay the 0.7 release once again? If so, how much time do we have in case we decide to get rid of the xdocs-folder? In any case I will stop working on the documentation issue until this is solved. -- Ferdinand Soethe
Re: Fussy feelings about 0.7
Ferdinand Soethe wrote: So I guess the outcome of the 'fuzzy' debate is that this issue is a blocker and we will delay the 0.7 release once again? If so, how much time do we have in case we decide to get rid of the xdocs-folder? We will *not* be getting rid of the xdocs folder in 0.7. This is a major change and will take too much time, unless you can show us otherwise. The issue of raw HTML files is a blocker because it breaks backward compatability. Ross
[JIRA] Closed: (FOR-189) Ad charting capability to Forrest
Message: The following issue has been closed. Resolver: Ross Gardler Date: Thu, 2 Jun 2005 8:47 AM See the Chart output plugin - View the issue: http://issues.cocoondev.org//browse/FOR-189 Here is an overview of the issue: - Key: FOR-189 Summary: Ad charting capability to Forrest Type: New Feature Status: Closed Priority: Major Resolution: FIXED Project: Forrest Components: Core operations Assignee: Ross Gardler Reporter: Nicola Ken Barozzi Created: Thu, 10 Jun 2004 5:26 PM Updated: Thu, 2 Jun 2005 8:47 AM Description: JCharts has an xml input format, so it should be easy to add this feature to Forrest. - 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
Duplicate copyright date
I'm using 0.7 svn and when creating a new site I am getting a duplicate copyright date ( Copyright © 2005 2005 The Acme Software Foundation.) prior to making any edits to anything. The year is only in the skinconf.xml file once so it looks like it is getting duplicated somewhere in processing. Pedro mentioned this in his earlier thread on user, Some Feedback on Using Forrest (http://www.mail-archive.com/user@forrest.apache.org/msg00619.html). He had made lots of mods so the issue got lost. Am I missing something or should I open a bug on it? - Addi
Re: How to avoid hard-coding site-visible message strings in skin files
On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote: Pedro I. Sanchez wrote: 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: i18n lang=en token name=lastPublished value=Last Published/ token name=copyright value=Copyright/ /i18n i18n lang=?? token name=lastPublished value=???/ token name=copyright value=???/ /i18n This would work for me as long as I can also specify the language manually with something like i18n lan=en / I'm not sure how the existing i18n thing works, but there is a way to specify what language you want the menus in, so I guess you would use the same mechanism. 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: skinlabels name=pelt keyword name=lastPublished value=???/ keyword name=copyright value=???/ /skinlabels I don't see the value in this. I would imagine that regardless of what skin you are using you would want the same values to appear in the output site. Skins will have different set of labels. copyright might be in all of them but lastPublished probably not. Hence the need to differentiate by skin name. One thing we must be sure of is that any solution implemented now can be integrated into Thorstens work on views. In fact, it would be better to see these changes go directly into views. Thorsten, what would the equivalent to the above be in views? Ross
Re: How to avoid hard-coding site-visible message strings in skin files
Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote: ... skinlabels name=pelt keyword name=lastPublished value=???/ keyword name=copyright value=???/ /skinlabels I don't see the value in this. I would imagine that regardless of what skin you are using you would want the same values to appear in the output site. Skins will have different set of labels. copyright might be in all of them but lastPublished probably not. Hence the need to differentiate by skin name. True. But what is the advantage of doing it this way over the other proposal (define by language). I see a disadvantage, that is it requires lots of duplication if we want multiple languages, whereas splitting by language only results in the odd unused element for occasional skins/views. Am I missing something about the use case here? Ross
Re: Duplicate copyright date
Looks like a bug in pelt. When you don't have a copyright-link it prints it out both explicitly before the choose and again inside the otherwise. A quick fix is to just comment out line 289. I think this should be an issue though. --tim On 6/2/05, Addi [EMAIL PROTECTED] wrote: I'm using 0.7 svn and when creating a new site I am getting a duplicate copyright date ( Copyright (c) 2005 2005 The Acme Software Foundation.) prior to making any edits to anything. The year is only in the skinconf.xml file once so it looks like it is getting duplicated somewhere in processing. Pedro mentioned this in his earlier thread on user, Some Feedback on Using Forrest (http://www.mail-archive.com/user@forrest.apache.org/msg00619.html). He had made lots of mods so the issue got lost. Am I missing something or should I open a bug on it? - Addi
Re: Duplicate copyright date
For the proper fix, I'm not sure what *should* happen if there is a copyright-link. Right now the copyright year is not included when copyright-link exists, should it? Seems to make sense that the only difference would be if copyright-link exists then vendor would be a hyperlink instead of text? --tim On 6/2/05, Tim Williams [EMAIL PROTECTED] wrote: Looks like a bug in pelt. When you don't have a copyright-link it prints it out both explicitly before the choose and again inside the otherwise. A quick fix is to just comment out line 289. I think this should be an issue though. --tim On 6/2/05, Addi [EMAIL PROTECTED] wrote: I'm using 0.7 svn and when creating a new site I am getting a duplicate copyright date ( Copyright (c) 2005 2005 The Acme Software Foundation.) prior to making any edits to anything. The year is only in the skinconf.xml file once so it looks like it is getting duplicated somewhere in processing. Pedro mentioned this in his earlier thread on user, Some Feedback on Using Forrest (http://www.mail-archive.com/user@forrest.apache.org/msg00619.html). He had made lots of mods so the issue got lost. Am I missing something or should I open a bug on it? - Addi
Re: How to avoid hard-coding site-visible message strings in skin files
On Thu, 2005-06-02 at 10:34 +0100, Ross Gardler wrote: Pedro I. Sanchez wrote: 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: i18n lang=en token name=lastPublished value=Last Published/ token name=copyright value=Copyright/ /i18n i18n lang=?? token name=lastPublished value=???/ token name=copyright value=???/ /i18n This would work for me as long as I can also specify the language manually with something like i18n lan=en / I'm not sure how the existing i18n thing works, but there is a way to specify what language you want the menus in, so I guess you would use the same mechanism. 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: skinlabels name=pelt keyword name=lastPublished value=???/ keyword name=copyright value=???/ /skinlabels I don't see the value in this. I would imagine that regardless of what skin you are using you would want the same values to appear in the output site. One thing we must be sure of is that any solution implemented now can be integrated into Thorstens work on views. In fact, it would be better to see these changes go directly into views. Thorsten, what would the equivalent to the above be in views? I started the work in view on it and it seems to work till the final stage. :( ...but I guess it is a bug that I hope to find quite fast. ;-) I tested with one contract and need to finish the rest. Actually I did not do it like you or Pedro suggested but the cocoon way with a simple i18n transformer in the contracts. That means we have a map:transformer name=xinclude src=org.apache.cocoon.transformation.XIncludeTransformer/ map:transformer name=i18n src=org.apache.cocoon.transformation.I18nTransformer catalogues default=contracts catalogue id=other name=OtherMessages location=messages/ catalogue id=contracts name=ContractsMessages location=messages/ /catalogues cache-at-startuptrue/cache-at-startup /map:transformer in the output.xmap of the viewHelper.xhmtl and nothing in the skinconf.xml. IMO that would be as well the way to implement it for the old fashion skins but I do not know how this affect the cli. salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: How to avoid hard-coding site-visible message strings in skin files
Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 15:27 +0100, Ross Gardler wrote: Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote: ... skinlabels name=pelt keyword name=lastPublished value=???/ keyword name=copyright value=???/ /skinlabels I don't see the value in this. I would imagine that regardless of what skin you are using you would want the same values to appear in the output site. Skins will have different set of labels. copyright might be in all of them but lastPublished probably not. Hence the need to differentiate by skin name. True. But what is the advantage of doing it this way over the other proposal (define by language). I see a disadvantage, that is it requires lots of duplication if we want multiple languages, whereas splitting by language only results in the odd unused element for occasional skins/views. You say right, If we want multiple languages. But in the current setting of supporting a single language, even if it is not English, then the skin-based approach could make sense. And as I said before, uni-lingual web sites are by far more common than multi-lingual ones. But I have no problem with the i18n-based approach as long as I can manually specify the target language. I'm just trying to avoid having to rely on the i18n framework to get a solution going. OK, I understand now. I don't have the insight into the development effort that this implies since I am new to Forrest. But certainly, if this would mean a duplication of work then it is a bad suggestion. No, I was thrown off by the fact that you were defining tokens for each skin, this made me think that there would need to be a duplication of tokens for skins. In fact there would be no need for this, your solution is identical to mine in concept if we remove my i18n attribute (uni-lingual site) and your skin attribute. In this case, if a skin doesn't understand a token it simply ignores it, so no duplication. However, consider Thorstens overlapping mail regarding the i18n transformer, could that do what you need with as little effort? I had a cursory glance and felt it probably could. Don't be thrown off with the talk of multi-lingual sites, it looks like it will do the kind of token replacement we have talked about, but will also bring with it the further use case of full i18n. Better yet, it already implements most of the logic and work on language catalogues now would be reusable in views since that is how they will work. Ross
Re: How to avoid hard-coding site-visible message strings in skin files
Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 19:04 +0200, Thorsten Scherler wrote: Thorsten, what would the equivalent to the above be in views? I started the work in view on it and it seems to work till the final stage. :( ...but I guess it is a bug that I hope to find quite fast. ;-) I tested with one contract and need to finish the rest. Actually I did not do it like you or Pedro suggested but the cocoon way with a simple i18n transformer in the contracts. That means we have a map:transformer name=xinclude src=org.apache.cocoon.transformation.XIncludeTransformer/ map:transformer name=i18n src=org.apache.cocoon.transformation.I18nTransformer catalogues default=contracts catalogue id=other name=OtherMessages location=messages/ catalogue id=contracts name=ContractsMessages location=messages/ /catalogues cache-at-startuptrue/cache-at-startup /map:transformer in the output.xmap of the viewHelper.xhmtl and nothing in the skinconf.xml. IMO that would be as well the way to implement it for the old fashion skins but I do not know how this affect the cli. salu2 Yaick! What does this all mean for me the poor end user? How do I modify the labels? :| Hmmm... my mail in response to this has gone missing. There are some pretty good docs at http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transformer.html Ross
Re: Slide Integration
Tim Williams wrote:
On 6/2/05, Ross Gardler [EMAIL PROTECTED] wrote:
Tim Williams wrote:
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
OK, I'm experimenting with this kind of integration right now. Not with
Slide but with Daisy. Take a look at the Daisy plugin in whiteboard.
Currently, the location of the repository is encoded in request
parameters. This is *not* good.
The problem with this approach is that a) it is difficult to write the
hrefs b) it is impossible to build a static site because the request
parameter '?' is converted to an '_' in the filename ('?' is not legal
in a filename)
The solution to this problem is the locationmap work. This allows you to
map request patterns to a location. For example:
match pattern=docs/**
location href=http://127.0.0.1:8080/slide/xdocs/{1}/
/match
So does input.xmap go from being a sitemap to a locationmap or does it
just add a few elements to the sitemap doctype? I guess I'm still not
understanding where the locationmap matchers actually go in terms of
the plugin.
The locationmap is not a sitemap in the same sense as a cocoon sitemap.
It uses the same syntax because it reuses much of the code.
For more information see http://issues.cocoondev.org/browse/FOR-200
From that URL you will find a link to the original discussion about
locationmaps that includes a description of the original commit and an
example of how to use it - see
http://marc.theaimsgroup.com/?t=10663878544
Things have not progressed any from that original contribution except...
I'm currently experimenting with the locationmap code, I have it working
to an extent. But have not yet managed to get it to work at the
generation stage (through lack of time rather than a problem with the
code, I think). I will attach a patch against the current SVN tree to
the above issue that will enable the location map if you would like to
experiment with it. It would be great to have someone working with me on
this, you with Slide, me with Daisy (and Thorsten is looking at Lenya
integration).
I'd like to see the location map patch. That sounds like the way to
go.
I should find the time tomorrow to put the patch together with a simplyu
little demo.
What does generation stage mean though, does what I'm talking
about fall into that particular stage?
I'll try and explain what I mean:
The original description of functionality (at
http://marc.theaimsgroup.com/?t=10663878544 ) only described link
translation. Meaning that a page with an lm: psuedo protocol href was
converted by the locationmap input-module to be a link to a specified
location. This is similar to the site: or ext: psuedo protocols in
Forrest. This works fine in the transformation stage. In other words, if
you have content with:
a href=lm:myslidedocs/file.html.../a
and a locationmap of:
match pattern=myslidedocs/**
locator src=http://127.0.0.1:8080/slide/xdocs/{1}/
/match
the resulting content will be translated to:
a href=http://127.0.0.1:8080/slide/xdocs/file.html/
This isn't quite what I want (and I think what you want). The problem is
that the link is translated in the source, so the URL the client sees is
the trnalsated URL. This prevents Forrest from processing the request as
the client requests directly from the repository source.
I'd prefer to have:
a href=myslidesdocs/file.html.../a
and a locationmap with:
match patern=myslidedocs/**.xml../a
locator src=http://127.0.0.1:8080/slide/xdocs/{1}.xml/
/match
(NOTE the .xml extension as opposed to .html)
In this case Forrest will request myslidesdoc/file.html, this will
result in an internal request for myslidesdoc/file.xml through
existing Forrest processing. The locationmap then maps this request to
http://127.0.0.1:8080/slide/xdocs/file.xml; which then gets processed
by forrest and returned to the client as myslidesdocs/file.html.
In other words, the href myslidesdocs/file.html remains that same URL
in the client but actually is generated internally to Forrest from
http://127.0.0.1:8080/slide/xdocs/{1}.xml;
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
Re: Duplicate copyright date
Addi wrote: Thanks for finding that for me. I agree that the only difference should be the vendor hyperlinked or not and the year always there. I found where you are and I commented out line 301 to do it this way instead. I hadn't ever ventured into these files so it took me a while to figure out where line 289 was LOL :) For others who dont know the files so well: forrest\main\webapp\skins\pelt\xslt\html\site2xhtml.xsl It sounds like you folk have found a workaround, if not a fix. Can you please raise an issue, if it is a workaround then describe it, if you can provide a fix then please attach a patch. If we leave it in the mailing list it will probably get lost. Please ensure relevant credits are in the issue so that when a fix is applied we can attribute it to the right people. Thanks, Ross
[JIRA] Updated: (FOR-515) Duplicate year in Pelt copyright text
The following issue has been updated: Updater: Addison Berry (mailto:[EMAIL PROTECTED]) Date: Thu, 2 Jun 2005 6:10 PM Comment: Attached a patch that removes the duplicate year that is within the otherwise clause. This makes the year always appear as non-link text, one time regardless if there is a copyright-link or not. Changes: Attachment changed to site2xhtml.xsl.diff - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-515?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-515 Here is an overview of the issue: - Key: FOR-515 Summary: Duplicate year in Pelt copyright text Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Addison Berry Created: Thu, 2 Jun 2005 6:06 PM Updated: Thu, 2 Jun 2005 6:10 PM Description: The copyright year is duplicated in pelt. It appears twice in the site2xhtml.xsl file. - 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-515) Duplicate year in Pelt copyright text
The following comment has been added to this issue: Author: Addison Berry Created: Thu, 2 Jun 2005 6:14 PM Body: Note that Tim Williams found the bug in the file originally. - View this comment: http://issues.cocoondev.org//browse/FOR-515?page=comments#action_12471 - View the issue: http://issues.cocoondev.org//browse/FOR-515 Here is an overview of the issue: - Key: FOR-515 Summary: Duplicate year in Pelt copyright text Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Versions: 0.7-dev Assignee: Reporter: Addison Berry Created: Thu, 2 Jun 2005 6:06 PM Updated: Thu, 2 Jun 2005 6:14 PM Description: The copyright year is duplicated in pelt. It appears twice in the site2xhtml.xsl file. - 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] Updated: (FOR-515) Duplicate year in Pelt copyright text
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Thu, 2 Jun 2005 6:51 PM Changes: Fix Version changed to 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-515?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-515 Here is an overview of the issue: - Key: FOR-515 Summary: Duplicate year in Pelt copyright text Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Skins (general issues) Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Reporter: Addison Berry Created: Thu, 2 Jun 2005 6:06 PM Updated: Thu, 2 Jun 2005 6:51 PM Description: The copyright year is duplicated in pelt. It appears twice in the site2xhtml.xsl file. - 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: does checksums-uri in cli.conf work?
Ferdinand Soethe wrote: Ross Gardler wrote: Probably faster to try turning it on than for someone to type a reply (I don't know the answer by the way). My question was more about hidden side effects that I wouldn't find through trial and error. But since nobody seems to know I'll just try. Cocoon-related questions would get better answers on cocoon-users. One way to see if there are any side-effects, would be to create two separate sites with 'forrest seed' and do 'forrest' in each. then compare the differences: cd forrest-test diff -rq seed-1/build/site seed-2/build/site ... will report any files with differences. It would be great if you can get this facility working. --David
