Writing generated page to disk in "forrest run"

Ross Gardler wrote:
> 
> Comments?

If they have other forms of the document e.g.
*.pdf or *.pod or *.txt etc. then those duplicate
formats would not be generated, because links
would not be followed.

-David

David Crossley wrote:
> Ross Gardler wrote:
> 
>>Comments?
> 
> 
> If they have other forms of the document e.g.
> *.pdf or *.pod or *.txt etc. then those duplicate
> formats would not be generated, because links
> would not be followed.

Good point.

That will have to be addressed. Couple of options:

I think that should be fairly easy to do by flagging links
that are 
created by output plugins in the skin/theme with a specific
class. The 
tool can then look for such links in the page and publish
them (doesn't 
work is a user manually adds such a link)

Alternative:

Assume page is foo.html, then scan the page for links to
"foo.*" and 
render those pages too. Still doesn't work is the different
format is 
linked from another site.

Interim conclusion:

We need to provide site validation tools that check all
local links in 
the locally built site. These could be run on a deploy
command.

Ross

Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >
> >>Comments?
> >
> >If they have other forms of the document e.g.
> >*.pdf or *.pod or *.txt etc. then those duplicate
> >formats would not be generated, because links
> >would not be followed.
> 
> Good point.
> 
> That will have to be addressed. Couple of options:
> 
> I think that should be fairly easy to do by flagging
links that are 
> created by output plugins in the skin/theme with a
specific class. The 
> tool can then look for such links in the page and
publish them (doesn't 
> work is a user manually adds such a link)
> 
> Alternative:
> 
> Assume page is foo.html, then scan the page for links
to "foo.*" and 
> render those pages too. Still doesn't work is the
different format is 
> linked from another site.
> 
> Interim conclusion:
> 
> We need to provide site validation tools that check all
local links in 
> the locally built site. These could be run on a deploy
command.

We already have that ... 'forrest site' or the forrestbot
"build"
workstage.

I am becoming wary of this proposed new ability.
Perhaps okay if we have a loud FAQ about the limitations
and encourage its use only for a quick re-build of
the current page, i.e. do not make it the primary way
of working.

I am also wary about turning Forrest into a poor person's
content management system by using htmlarea and such.

-David

David Crossley wrote:
> Ross Gardler wrote:
> 
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>Comments?
>>>
>>>If they have other forms of the document e.g.
>>>*.pdf or *.pod or *.txt etc. then those
duplicate
>>>formats would not be generated, because links
>>>would not be followed.
>>
>>Good point.
>>
>>That will have to be addressed. Couple of options:
>>
>>I think that should be fairly easy to do by flagging
links that are 
>>created by output plugins in the skin/theme with a
specific class. The 
>>tool can then look for such links in the page and
publish them (doesn't 
>>work is a user manually adds such a link)
>>
>>Alternative:
>>
>>Assume page is foo.html, then scan the page for
links to "foo.*" and 
>>render those pages too. Still doesn't work is the
different format is 
>>linked from another site.
>>
>>Interim conclusion:
>>
>>We need to provide site validation tools that check
all local links in 
>>the locally built site. These could be run on a
deploy command.
> 
> 
> We already have that ... 'forrest site' or the
forrestbot "build"
> workstage.

exactly, see the first mail in this thread, I'm proposing
integrating 
the forrestbot webapp in "forrest run" 

> I am becoming wary of this proposed new ability.
> Perhaps okay if we have a loud FAQ about the
limitations
> and encourage its use only for a quick re-build of
> the current page, i.e. do not make it the primary way
> of working.

Agreed - in fact I was thinking that when you save a page
the browser is 
redirected to a report page that says how likely it is that
your site is 
still synchronised. We could keep a timestamp of the last
time the site 
has been built, keep a count of the number of pages
individually saved, 
check timestamps of navigation and theme files against the
last build 
timestamp etc.

> I am also wary about turning Forrest into a poor
person's
> content management system by using htmlarea and such.

I agree I think we should deprecate the htmlArea plugin (it
probably 
doesn't work anymore anyway). What other plugins are there
that cause 
concern about being a poor mans CMS?

Ross

> 
> -David
> 
> 

Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>
> >>Interim conclusion:
> >>
> >>We need to provide site validation tools that
check all local links in 
> >>the locally built site. These could be run on a
deploy command.
> >
> >We already have that ... 'forrest site' or the
forrestbot "build"
> >workstage.
> 
> exactly, see the first mail in this thread, I'm
proposing integrating 
> the forrestbot webapp in "forrest run" 

I had seen references to forrestbot, but i had assumed
that you meant the backend of it. Now i begin to see
your vision. Interesting.

> >I am becoming wary of this proposed new ability.
> >Perhaps okay if we have a loud FAQ about the
limitations
> >and encourage its use only for a quick re-build of
> >the current page, i.e. do not make it the primary
way
> >of working.
> 
> Agreed - in fact I was thinking that when you save a
page the browser is 
> redirected to a report page that says how likely it is
that your site is 
> still synchronised. We could keep a timestamp of the
last time the site 
> has been built, keep a count of the number of pages
individually saved, 
> check timestamps of navigation and theme files against
the last build 
> timestamp etc.

Yes i was wondering about such a solution too. Good.

> >I am also wary about turning Forrest into a poor
person's
> >content management system by using htmlarea and
such.
> 
> I agree I think we should deprecate the htmlArea plugin
(it probably 
> doesn't work anymore anyway). What other plugins are
there that cause 
> concern about being a poor mans CMS?

Well it is hard to know where the line is.
Our mission statement is intentionally vague.
htt
p://forrest.apache.org/guidelines.html#mission
The Introduction on the home page also avoids
mention of it. Perhaps it would help to have an
FAQ about the CMS aspect.

Every day i intend to explore the new "NoteTaking"
plugin.
(Oh, something wrong with the online docs.)
I suspect that that is a fine use.

-David

David Crossley wrote:
> Ross Gardler wrote:

...

>>>I am also wary about turning Forrest into a poor
person's
>>>content management system by using htmlarea and
such.
>>
>>I agree I think we should deprecate the htmlArea
plugin (it probably 
>>doesn't work anymore anyway). What other plugins are
there that cause 
>>concern about being a poor mans CMS?
> 
> 
> Well it is hard to know where the line is.
> Our mission statement is intentionally vague.
> htt
p://forrest.apache.org/guidelines.html#mission
> The Introduction on the home page also avoids
> mention of it. Perhaps it would help to have an
> FAQ about the CMS aspect.
> 
> Every day i intend to explore the new
"NoteTaking" plugin.
> (Oh, something wrong with the online docs.)
> I suspect that that is a fine use.

The note-taking plugin is quite different from CMS. It is
simply a place 
to jot notes about each page. No version control, no user
management 
etc. They are rendered separately from the core content. All
notes are 
stored in a single file, linked to the source files by URL.

Editing is just a plain text form field - no wysiwyg or
anything like that.

I use it in a (protoype) educational product that allows
text books to 
be distrbited as Forrest content objects.

I have no problem moving it over to Burrokeet if it blurs
the boundaries 
too much. Thinking about it it may be better to do that in
order to keep 
the distinction between publication and content editing. It
would also 
provide another off-site plugin which would be a good idea.

Ross

Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> 
> ...
> 
> >>>I am also wary about turning Forrest into a
poor person's
> >>>content management system by using htmlarea
and such.
> >>
> >>I agree I think we should deprecate the
htmlArea plugin (it probably 
> >>doesn't work anymore anyway). What other
plugins are there that cause 
> >>concern about being a poor mans CMS?
> >
> >Well it is hard to know where the line is.
> >Our mission statement is intentionally vague.
> >htt
p://forrest.apache.org/guidelines.html#mission
> >The Introduction on the home page also avoids
> >mention of it. Perhaps it would help to have an
> >FAQ about the CMS aspect.
> >
> >Every day i intend to explore the new
"NoteTaking" plugin.
> >(Oh, something wrong with the online docs.)
> >I suspect that that is a fine use.
> 
> The note-taking plugin is quite different from CMS. It
is simply a place 
> to jot notes about each page. No version control, no
user management 
> etc. They are rendered separately from the core
content. All notes are 
> stored in a single file, linked to the source files by
URL.
> 
> Editing is just a plain text form field - no wysiwyg or
anything like that.
> 
> I use it in a (protoype) educational product that
allows text books to 
> be distrbited as Forrest content objects.
>
> I have no problem moving it over to Burrokeet if it
blurs the boundaries 
> too much. Thinking about it it may be better to do that
in order to keep 
> the distinction between publication and content
editing. It would also 
> provide another off-site plugin which would be a good
idea.

Wait. I was trying to say that it is probably
a good example of something that is within our scope.
And probably nicely defines the limit.

-David