[JIRA] Commented: (FOR-284) link rewriting broken when linking to xml source views which contain site: links
The following comment has been added to this issue: Author: David Crossley Created: Sat, 16 Apr 2005 1:41 AM Body: This issue was well-described in Issue FOR-156 which was closed with a workaround. This workaround was partially disabled (see above). So now the problem appeared again, but the links were being excluded via cli.xconf so we didn't see any broken site: links. I can see a way to restore the original workaround and not have its side-effects. - View this comment: http://issues.cocoondev.org//browse/FOR-284?page=comments#action_12243 - View the issue: http://issues.cocoondev.org//browse/FOR-284 Here is an overview of the issue: - Key: FOR-284 Summary: link rewriting broken when linking to xml source views which contain site: links Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Launch 'forrest' Fix Fors: 0.8 Versions: 0.6 Assignee: Reporter: Nicola Ken Barozzi Created: Wed, 8 Sep 2004 1:48 AM Updated: Sat, 16 Apr 2005 1:41 AM Description: When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs - 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-284) link rewriting broken when linking to xml source views which contain site: links
The following issue has been updated: Updater: David Crossley (mailto:[EMAIL PROTECTED]) Date: Sat, 16 Apr 2005 12:43 AM Changes: Comment was deleted. - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-284?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-284 Here is an overview of the issue: - Key: FOR-284 Summary: link rewriting broken when linking to xml source views which contain site: links Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Launch 'forrest' Fix Fors: 0.8 Versions: 0.6 Assignee: Reporter: Nicola Ken Barozzi Created: Wed, 8 Sep 2004 1:48 AM Updated: Sat, 16 Apr 2005 12:43 AM Description: When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs - 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-284) link rewriting broken when linking to xml source views which contain site: links
The following comment has been added to this issue: Author: David Crossley Created: Sat, 16 Apr 2005 12:40 AM Body: This issue was well-described in Issue FOR-156. - View this comment: http://issues.cocoondev.org//browse/FOR-284?page=comments#action_12240 - View the issue: http://issues.cocoondev.org//browse/FOR-284 Here is an overview of the issue: - Key: FOR-284 Summary: link rewriting broken when linking to xml source views which contain site: links Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Launch 'forrest' Fix Fors: 0.8 Versions: 0.6 Assignee: Reporter: Nicola Ken Barozzi Created: Wed, 8 Sep 2004 1:48 AM Updated: Sat, 16 Apr 2005 12:40 AM Description: When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs - 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: using view/viewHelper
> I made some changes to add custom css to the view. > > Life's good so far. Now, from what I see, it seems that the nugget for generating "tabs" is currently not doing much (atleast it doesn't generate any content for me. did I miss anything?) Is this intentional or you just haven't gotten around to it yet Thorsten?) Of course, I think we can have a good debate on whats the best way to generate XHTML content for the tabs to make it "most amenable" to CSS skinning. Personally, I would just output each tab in its own div element, with class attributes denoting the selected tab. One can then use CSS to structure/color them appropriately. -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
[JIRA] Updated: (FOR-284) link rewriting broken when linking to xml source views which contain site: links
The following issue has been updated: Updater: David Crossley (mailto:[EMAIL PROTECTED]) Date: Fri, 15 Apr 2005 11:17 PM Comment: Changed the issue title and description to better reflect the real problem. Changes: summary changed from 'error:' prepending problems to link rewriting broken when linking to xml source views which contain site: links description changed from 'error:' prepending, for site: and ext: links that were not found, causes problems. For example, if in xdocs/samples I have ext:dtd-docs, Cocoon will search for samples/ext:dtd-docs, which of course does not exist. @see declare-broken-site-links.xsl in teh core templates for more info. to When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-284?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-284 Here is an overview of the issue: - Key: FOR-284 Summary: link rewriting broken when linking to xml source views which contain site: links Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Launch 'forrest' Fix Fors: 0.8 Versions: 0.6 Assignee: Reporter: Nicola Ken Barozzi Created: Wed, 8 Sep 2004 1:48 AM Updated: Fri, 15 Apr 2005 11:17 PM Description: When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs - 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: using view/viewHelper
replying to my own mail -- sheesh! Sorry, I think I've figured it out :) Will ping again if I have some problems. Ciao On 4/15/05, Diwaker Gupta <[EMAIL PROTECTED]> wrote: > > I made some changes to add custom css to the view. > > > > > > Sorry for being obtuse, but where exactly does this go? As in, in > which file? Somehow, I feel as if the CSS separation is not as neat as > the contracts separation. Ideally, I should be able to define my own > CSS and forrest should pick it up from "expected locations" just as it > picks up the view files. > > > -- > Diwaker Gupta > http://resolute.ucsd.edu/diwaker > -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
Re: using view/viewHelper
> I made some changes to add custom css to the view. > > Sorry for being obtuse, but where exactly does this go? As in, in which file? Somehow, I feel as if the CSS separation is not as neat as the contracts separation. Ideally, I should be able to define my own CSS and forrest should pick it up from "expected locations" just as it picks up the view files. -- Diwaker Gupta http://resolute.ucsd.edu/diwaker
[JIRA] Commented: (FOR-321) mysterious failure of ext:dtd-docs or site:dtd-docs link specifically
The following comment has been added to this issue: Author: David Crossley Created: Fri, 15 Apr 2005 10:56 PM Body: It is not actually fixed. It was just being disguised by something else. Not bothering to re-open this Issue because FOR-284 describes it better. Regarding the comment above, the brokenlinks.xml does now include the referrer uri. - View this comment: http://issues.cocoondev.org//browse/FOR-321?page=comments#action_12238 - View the issue: http://issues.cocoondev.org//browse/FOR-321 Here is an overview of the issue: - Key: FOR-321 Summary: mysterious failure of ext:dtd-docs or site:dtd-docs link specifically Type: Bug Status: Closed Priority: Major Resolution: FIXED Project: Forrest Components: Core operations Fix Fors: 0.7-dev Versions: 0.6 Assignee: Reporter: David Crossley Created: Sat, 9 Oct 2004 6:53 AM Updated: Fri, 15 Apr 2005 10:56 PM Description: The 'forrest seed site' fails and reports a broken link for "ext:dtd-docs". Similarly building Forrest core docs an error with "site:dtd-docs". Why this link in particular while other links are okay? - 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: using view/viewHelper
On Fri, 2005-04-15 at 16:33 -0700, Diwaker Gupta wrote:
> Hi everyone,
>
> I'm playing around with view/viewHelper -- pretty cool! Its easy to
> define new views by placing them in ${content-dir}/conf/. I can either
> use default.fv or define per-page views. All rocks.
>
:)
> However, I wasn't very sure where to put the relevant CSS stuff? The
> plugin itself contains some CSS as part of the contracts. I looked at
> input.xmap in the view plugin, but couldn't find a definite answer.
>
Actually you are looking for
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.viewHelper/resources.xmap?view=markup
I made some changes to add custom css to the view.
This tag has to be direct son from forrest:view!
In the above link you will find:
That means e.g.
would expect (with default values)
src/documentation/skins
|-- css
`-- prosimii-screen-alt.css
HTH
salu2
> TIA
> Diwaker
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Howto V 2.0 transform
Mark Eggers wrote: > David Crossley wrote: > > > > I'll try svn diff for my next submission (making faqs v2.0 consistent > > > with document v2.0 and howto v2.0 I think). > > > > Hmm, i am not clear what you mean by that. > > I noticed that there are only head definitions for howto and document > DTDs. When authoring other documents, you can't put some of the > information in. After looking at the other DTDs, I don't know if it > would be valuable to add the head elements in or not. > > > That is correct. These stylesheets need to be able > > to cope with both formats. Your changes did. > > Actually, I think in my copy I broke v 1.x How To compatibility. At > least with my sample document the questions and answers were not > translated correctly. That's why I left the original stylesheet. Todays trunk works for me. In SVN we have howto/howto-howto.xml which uses ... this doc was DTD v1.3 but now i upgraded it to to be DTD v2.0 ... and both versions work in my local test. If you still see problems, then please add a test document to a Jira Issue. > > The basic thing to bear in mind is that all formats > > (i.e. v*.* of faq, changes, document) get transformed > > into the internal format. At the momemnt this is document-v1 > > I see that. I've been trying to get the meta element from v 2.0 DTDs to > make it into the final rendition. Right now if you add a meta tag to a > v 2.0 how to or document xml file you will get non-validating html from > the pelt skin. Even if you don't include a meta tag, you get an empty > element in the output and the html no longer validates. > > Hopefully I can get that figured out. That would be a great relief. It has been on my todo list for the imminent 0.7 release. The empty element would mean we need to change our compliance.html page. --David
[JIRA] Commented: (FOR-480) The Cocoon cli.xconf generates its extra documents into main/site/
The following comment has been added to this issue: Author: David Crossley Created: Fri, 15 Apr 2005 8:40 PM Body: The cli.xconf file has a configuration element "dest-dir" and the element "uri" has an attribute "dest". Both of them cause the extra documents to be relative to the webapp context rather that the propject home. - View this comment: http://issues.cocoondev.org//browse/FOR-480?page=comments#action_12237 - View the issue: http://issues.cocoondev.org//browse/FOR-480 Here is an overview of the issue: - Key: FOR-480 Summary: The Cocoon cli.xconf generates its extra documents into main/site/ Type: Bug Status: Unassigned Priority: Minor Project: Forrest Fix Fors: 0.7-dev Versions: 0.6 0.7-dev Assignee: Reporter: David Crossley Created: Fri, 15 Apr 2005 8:17 PM Updated: Fri, 15 Apr 2005 8:40 PM Description: Extra URIs (additional to those in site.xml) can be processed by declaring them in a project-based conf/cli.xconf However, the final documents are not being generated into build/site/ but instead are going into main/site/ - 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-480) The Cocoon cli.xconf generates its extra documents into main/site/
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-480 Here is an overview of the issue: - Key: FOR-480 Summary: The Cocoon cli.xconf generates its extra documents into main/site/ Type: Bug Status: Unassigned Priority: Minor Project: Forrest Fix Fors: 0.7-dev Versions: 0.6 0.7-dev Assignee: Reporter: David Crossley Created: Fri, 15 Apr 2005 8:17 PM Updated: Fri, 15 Apr 2005 8:17 PM Description: Extra URIs (additional to those in site.xml) can be processed by declaring them in a project-based conf/cli.xconf However, the final documents are not being generated into build/site/ but instead are going into main/site/ - 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: Howto V 2.0 transform
On Sat, 2005-04-16 at 09:53 +1000, David Crossley wrote: > > I'll try svn diff for my next submission (making faqs v2.0 consistent > > with document v2.0 and howto v2.0 I think). > > Hmm, i am not clear what you mean by that. I noticed that there are only head definitions for howto and document DTDs. When authoring other documents, you can't put some of the information in. After looking at the other DTDs, I don't know if it would be valuable to add the head elements in or not. > That is correct. These stylesheets need to be able > to cope with both formats. Your changes did. Actually, I think in my copy I broke v 1.x How To compatibility. At least with my sample document the questions and answers were not translated correctly. That's why I left the original stylesheet. > The basic thing to bear in mind is that all formats > (i.e. v*.* of faq, changes, document) get transformed > into the internal format. At the momemnt this is document-v1 I see that. I've been trying to get the meta element from v 2.0 DTDs to make it into the final rendition. Right now if you add a meta tag to a v 2.0 how to or document xml file you will get non-validating html from the pelt skin. Even if you don't include a meta tag, you get an empty element in the output and the html no longer validates. Hopefully I can get that figured out. -- Mark Eggers <[EMAIL PROTECTED]>
Re: Howto V 2.0 transform
Mark Eggers wrote: > David Crossley wrote: > > > Hey, that was a clever way to demonstrate a fix, > > to tweak the sitemap to call a copy of the xsl. > > Thanks, I was just following the pattern that's being used. > > > However, if you are using svn, then you could just change > > the actual file and send the 'svn diff'. > > I've just started using svn extensively. Right now most of my big > projects are in CVS, and I keep configuration files in RCS. > > I'll try svn diff for my next submission (making faqs v2.0 consistent > with document v2.0 and howto v2.0 I think). Hmm, i am not clear what you mean by that. > At any rate, after looking at forrest.xmap, it appears that the same > howto2document.xsl is used to transform all howto vxy DTD documents. > Since there were changes on going from V1.3 to V2.0, I didn't want to > disturb any additional translations. That is correct. These stylesheets need to be able to cope with both formats. Your changes did. Don't be tricked by some of the filenames in there. Many of the stylesheets are from old versions of Forrest. The basic thing to bear in mind is that all formats (i.e. v*.* of faq, changes, document) get transformed into the internal format. At the momemnt this is document-v1 > I picked a name that seemed to follow the pattern for other translations > in $FORREST_HOME/main/webapp/resources/stylesheets and went from there. That is the point of my comments. You didn't need to duplicate the xsl file. --David
using view/viewHelper
Hi everyone,
I'm playing around with view/viewHelper -- pretty cool! Its easy to
define new views by placing them in ${content-dir}/conf/. I can either
use default.fv or define per-page views. All rocks.
However, I wasn't very sure where to put the relevant CSS stuff? The
plugin itself contains some CSS as part of the contracts. I looked at
input.xmap in the view plugin, but couldn't find a definite answer.
TIA
Diwaker
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
Re: Howto V 2.0 transform
On Fri, 2005-04-15 at 15:18 +1000, David Crossley wrote: > Hey, that was a clever way to demonstrate a fix, > to tweak the sitemap to call a copy of the xsl. Thanks, I was just following the pattern that's being used. > However, if you are using svn, then you could just change > the actual file and send the 'svn diff'. I've just started using svn extensively. Right now most of my big projects are in CVS, and I keep configuration files in RCS. I'll try svn diff for my next submission (making faqs v2.0 consistent with document v2.0 and howto v2.0 I think). At any rate, after looking at forrest.xmap, it appears that the same howto2document.xsl is used to transform all howto vxy DTD documents. Since there were changes on going from V1.3 to V2.0, I didn't want to disturb any additional translations. I picked a name that seemed to follow the pattern for other translations in $FORREST_HOME/main/webapp/resources/stylesheets and went from there. -- Mark Eggers <[EMAIL PROTECTED]>
Re: Tidying up plugins for 0.7 release
On Thu, 2005-04-14 at 17:33 +0100, Ross Gardler wrote: > So, unless there is a -1 before by the end of the weekend I will move > the following plugins to whiteboard/plugins next week. > o.a.f.p.internal.views > o.a.f.p.output.ViewHelper -1 on them, why in the whiteboard? I agree they are not perfect yet, but they are working fine. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Daisy as a docs editor (was Re: [CocoonInAction] Opening announce)
[Cross posted to Forrest-Dev for obvious reasons] Steven Noels wrote: On 15 Apr 2005, at 00:09, Linden H van der (MI) wrote: If someone would offer a Cocoon hosting or Daisy hosting for the project, I personnaly be happy to move the content there. Stay tuned. Interesting, that is my response too. I'm about to go away for nearly a week so cannot participate in any discussion. However, since Steven clearly has some plans in this area I may as well mention my own - which I hope will be compatible. I am using Daisy internally and am building a plugin for Forrest that allows users to include Daisy pages in their Forrest sites. The current status of the plugin is that it includes the text of documents from multiple repositories. It needs some URL rewriting to make things like images work. I will commit what I have to the Forrest whiteboard area in case anyone wants to have a play. I intend to finish this after Forrest has released 0.7 (we're working on the final leg of that release right now). Why is this significant? If Steven is going to be able to source/offer Cocoon hosting, with a Daisy Wiki then we get some pretty powerful options, that compliment the proposal at http://wiki.apache.org/cocoon/CocoonDocumentationSystemSUMMARY very well: Daisy Wiki is used as the document creation/editing tool. Daisy provides a basic edit/review/publish workflow so quality control remains the domain of committers. Forrest is used to generate the site, but rather than having a separate repository via SVN it works directly with the Daisy repository using the new plugin. The plugin can be set to always retrieve the current live page in the daisy repository, i.e. the one that has been approved for publication. This means that the Daisy Wiki will make the alpha docs available, whilst the cocoon site will show the published docs. A further benefit of this two phased publication approach is that we can avoid the unstructured navigation of an evolving wiki site. The idea of the Forrest plugin is that you can have a separate site definition from that defined in the daisy repository. Consequently the cocoon site can ignore internal documents (such as the one above about the documentation system) and instead focus on docs interested to users and potential users. It would also be possible to have a separate site organisation for developers, marketeers, users, committers etc. etc. All documents would come from the same central repository, we just maintain a different forrest site.xml file for each of the sites. Note - there would have to be some work to handle links from pages that are in Daisy, but not yet published on the main site. I haven't thought about how to handle those yet, perhaps point them at a holding page explaining the document is an alpha document, then providing a link to the daisy wiki. Anyway, I'll catch up on any discussion when I come back, or I'll just let you know when the plugin is complete. Ross
