You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2005/06/04 14:56:01 UTC
dev environment
Can someone please describe the proper dev environment for Forrest?=20
Sorry for such an elementary question but I'm getting past the point
where TextPad is useful. With it seemingly being 80% xml files, I'm
having a difficult time getting my mind around how to
watch/trace/debug things properly.
Thanks,
--tim
Re: dev environment
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Tim Williams wrote:
> >Can someone please describe the proper dev environment for Forrest?=20
> >Sorry for such an elementary question but I'm getting past the point
> >where TextPad is useful. With it seemingly being 80% xml files,
>
> There is no *proper* dev environment. It really depends on your personal
> preferences. The most important thing is to have a good XML editor.
Everyone is different Tim. I just use vi to edit everything,
xml included. If doing 'forrest validate-xdocs' does not
reveal the cause of an xml issue, then i use 'xmllint'.
> I like JEdit and Eclipse, with the relevant XML plugins, but others use
> all sorts of different tools. You may like to look at
> http://forrest.apache.org/0.7/docs/catalog.html for some hints as to
> what people are using and how.
>
> > I'm
> > having a difficult time getting my mind around how to
> > watch/trace/debug things properly.
>
> There is no watch/trace/debug type functionlaity (or at least not that I
> use). Cocoon probably provides some such functionality, but I have never
> found it necessary, but then I don't often use such devices when
> programming either, it's just the way I like to work.
There is not much Java code in Forrest anyway.
> For me find the easiest way to "debug" Forrest is to be aware of all the
> processing steps between taking in the source and outputting the end
> result. When you know these you can do 'forrest run' and request the
> intermediate documents, such as "http://localhost:8888/body-index.xml"
> which will return the intermediate processing of the body of the document.
Yes, there are some very powerful debugging techiques,
once you understand Cocoon.
Anyway see some tips about our logfiles at
http://forrest.apache.org/0.7/docs/faq.html#logs
--David
> This is a real candidate for a new document. One that would considerably
> lower the barrier to entry for new devs. For now though, I would suggest
> that when you get to a point that you have no idea how to move forwards
> with respect to debugging drop a mail to the list and we'll try and tell
> you how to do it. Our replies can form the start of a document dealing
> with this.
>
> Ross
Re: dev environment
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Tim Williams wrote:
>
>> Can someone please describe the proper dev environment for Forrest?=20
>> Sorry for such an elementary question but I'm getting past the point
>> where TextPad is useful. With it seemingly being 80% xml files,
>
>
> There is no *proper* dev environment. It really depends on your personal
> preferences. The most important thing is to have a good XML editor.
>
> I like JEdit and Eclipse, with the relevant XML plugins, but others use
> all sorts of different tools. You may like to look at
> http://forrest.apache.org/0.7/docs/catalog.html for some hints as to
> what people are using and how.
>
> > I'm
> > having a difficult time getting my mind around how to
> > watch/trace/debug things properly.
>
> There is no watch/trace/debug type functionlaity (or at least not that I
> use). Cocoon probably provides some such functionality, but I have never
> found it necessary, but then I don't often use such devices when
> programming either, it's just the way I like to work.
>
> For me find the easiest way to "debug" Forrest is to be aware of all the
> processing steps between taking in the source and outputting the end
> result. When you know these you can do 'forrest run' and request the
> intermediate documents, such as "http://localhost:8888/body-index.xml"
> which will return the intermediate processing of the body of the document.
>
> This is a real candidate for a new document. One that would considerably
> lower the barrier to entry for new devs. For now though, I would suggest
> that when you get to a point that you have no idea how to move forwards
> with respect to debugging drop a mail to the list and we'll try and tell
> you how to do it. Our replies can form the start of a document dealing
> with this.
Another *very* useful tip is that the log files WEB-INF/logs will often
provide much more detail when an error occurs.
Ross
Re: dev environment
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> Can someone please describe the proper dev environment for Forrest?=20
> Sorry for such an elementary question but I'm getting past the point
> where TextPad is useful. With it seemingly being 80% xml files,
There is no *proper* dev environment. It really depends on your personal
preferences. The most important thing is to have a good XML editor.
I like JEdit and Eclipse, with the relevant XML plugins, but others use
all sorts of different tools. You may like to look at
http://forrest.apache.org/0.7/docs/catalog.html for some hints as to
what people are using and how.
> I'm
> having a difficult time getting my mind around how to
> watch/trace/debug things properly.
There is no watch/trace/debug type functionlaity (or at least not that I
use). Cocoon probably provides some such functionality, but I have never
found it necessary, but then I don't often use such devices when
programming either, it's just the way I like to work.
For me find the easiest way to "debug" Forrest is to be aware of all the
processing steps between taking in the source and outputting the end
result. When you know these you can do 'forrest run' and request the
intermediate documents, such as "http://localhost:8888/body-index.xml"
which will return the intermediate processing of the body of the document.
This is a real candidate for a new document. One that would considerably
lower the barrier to entry for new devs. For now though, I would suggest
that when you get to a point that you have no idea how to move forwards
with respect to debugging drop a mail to the list and we'll try and tell
you how to do it. Our replies can form the start of a document dealing
with this.
Ross