forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [jira] Commented: (FOR-680) The jspwiki parser renders nested lists invalid
Date Wed, 26 Oct 2005 01:11:38 GMT
Gav.... wrote:
> David Crossley wrote:
> | Gav.... wrote:
> | > | >
> | > | > Anywhere else I should be looking ?
> | > |
> | > | Don't forget the sitemaps too. They build a parser
> | > | out of the grammar and then apply it to the text.
> | > | plugins/...input.wiki/input.xmap lines 55 and 56
> | > | and then either
> | > | plugins/...input.wiki/input.xmap line 93
> | > | or
> | > | webapp/sitemap.xmap line 326
> | > | (i am not sure which).
> | > |
> | > | Change the wiki/input.xmap at line 91 to let
> | > | the pipeline be external, then view
> | > | localhost:8888/wiki.xlex
> | >
> | > I did that but resource not found.
> |
> | Oh, i just tried it too. It seems that setting
> | <map:pipeline type="caching" internal-only="false">
> | has no effect when used in a plugin. It does work when
> | used in the main/webapp sitemaps.

This new bug is a problem for you. That would have
enabled you to see the xml output from building the
dynamic Chaperon "lexer" and "parser" at step 5 below.
Using the Cocoon Profiler as described below might be
the only way that you can see the xml stream (for debugging
purposes) at the points where wiki.xlex and wiki.xgrm
are built from the wiki.grm file.

> | > | Perhaps the wiki.grm is not quite correct or too
> | > | strict. Wiki documents are very fragile. Perhaps
> | > | there is an additional space (or some such) before
> | > | or after the bullet item in the source file.
> | >
> | > No spaces that I know of, the wiki.grm seems correct from what
> | > little I know, but am still checking it out.
> |
> | Good luck then.
> |
> | > | Also try looking at the intermediate pipelines
> | > | to see if xml is being created properly at each step
> | > | of the way.
> | > |
> | > | The easiest way to do that is to use the
> | > | Cocoon Sitemap Profiler:
> | > | http://forrest.apache.org/docs_0_80/howto/howto-dev.html#debug
> | >
> | > Ok, did that, wow, seems to be a lot going on there!
> | >
> | > The .xml file contains the wrong code, not knowing too much
> | > at this stage I'm not sure if it is a base .xml file that the xsl uses
> | > to produce the final html output or if it is an output .xml file
> | > as a result of the xsl. It is important that I determine this
> | > obviously as it would rule in or out the xsl as the problem.
> | >
> | > I would suspect a pipeline otherwise (npi) but can not see where
> | > any problem lies at the moment.
> |
> | Sorry, i have no idea what those last two paragraphs mean.
> 
> And you think I do :) , Well from what I am trying to understand, is
> whether this or something else happens,
> 
> jspwiki.sample.jpswiki -> jspwiki-sample.xml -> wiki2xdoc.xsl -> 
> jspwiki-sample.html

1) http://localhost:8888/samples/jspwiki-sample.html

2) plugins/...wiki/input.xmap produces the "internal xml" via
its "file-resolver" resource at line 85 then line 37 ...

3) finds the source at .../xdocs/samples/jspwiki-sample.jspwiki

4) processes the source via the Chaperon "lexer" and "parser"

5) which are both built dynamicallly (e.g. input.xmap:55
then input.xmap:93 then input.xmap:98) from the wiki.grm

6) the output of the Chaperon parser is then transformed
to the Forrest internal format at input.xmap:58

7) then the normal Forrest machinery does the rest.

-David

Mime
View raw message