Sam Ruby wrote:
Adam R. B. Jack wrote:
My first proposal was to run forrest dynamic for gump. This means that
you don't have to change anything in the code right now *AND* you get
immediate changes as soon as they are written on disk.
I am game to explore alternatives, but this one really attra
Adam R. B. Jack wrote:
Ok, so help me understand this more. Once we have a webapp installed
(somehow we have to build it based upon the empty template, right?) we can
then just squirt new xdocs and/or other content into that directory?
Can we do things like change the site.xml on the fly?
Yes
[
> http://xml.apache.org/forrest/your-project.html#installing
>
> use the /forrest webapp/ command to create a webapp for deployment and
> then copy that over to the tomcat applications dir.
>
> I think the webapp ends up in build/webapp
Ok, so help me understand this more. Once we have a webapp
http://xml.apache.org/forrest/your-project.html#installing
use the /forrest webapp/ command to create a webapp for deployment and
then copy that over to the tomcat applications dir.
I think the webapp ends up in build/webapp
R,
Nick
Sam Ruby wrote:
If somebody can give me a "bill of material
Adam R. B. Jack wrote:
My first proposal was to run forrest dynamic for gump. This means that
you don't have to change anything in the code right now *AND* you get
immediate changes as soon as they are written on disk.
I am game to explore alternatives, but this one really attracts me as a
short t
> My first proposal was to run forrest dynamic for gump. This means that
> you don't have to change anything in the code right now *AND* you get
> immediate changes as soon as they are written on disk.
I am game to explore alternatives, but this one really attracts me as a
short term fix. Can anyb
Sam Ruby wrote:
Adam R. B. Jack wrote:
>
> We have gump.document.text, and we could create gump.document.html
> that use cheetah to write it.
Stefano Mazzocchi wrote:
+1 in removal of forrest and go plain XHTML + CSS. But please, let's
use a velocity-like approach, not a DOM like approach!
Sam Ruby wrote:
At the moment, gump.document.* take a complete set of knowledge and
produce a set of artifacts. The best analogy to Cocoon for this would
be a serializer which terminates a pipeline.
An alternate approach would be to completely flip this. Have the
equivalent logic drive the ac
> For us to get to the point where others are interested in personal
> gumps, we need to make it easier to build profiles which use
> repositories for components that an individual is not interested in
> rebuilding for themselves.
Yeah, I agree, I also think this'd help more Gump 'communities' (no
Adam R. B. Jack wrote:
An alternate approach would be to completely flip this. Have the
equivalent logic drive the acquisition of certain pieces of information,
which can be processed as it is being received.
Whilst most of the forrest documenter generates pages for single entities
(for workspace
> At the moment, gump.document.* take a complete set of knowledge and
> produce a set of artifacts.
Sounds accurate. [I am not familiar w/ Cocoon, so won't comment there.]
> An alternate approach would be to completely flip this. Have the
> equivalent logic drive the acquisition of certain piece
Adam R. B. Jack wrote:
>
> We have gump.document.text, and we could create gump.document.html
> that use cheetah to write it.
Stefano Mazzocchi wrote:
+1 in removal of forrest and go plain XHTML + CSS. But please, let's use
a velocity-like approach, not a DOM like approach!
I may be reading too mu
12 matches
Mail list logo
