documentation/content made available to sitemap (Re: 'broken link' causes..)

[Jeff Turner <je...@apache.org>]

On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
> 
> Jeff Turner wrote:
> [...]
> >While I'm clarifying.. what's the difference between a 'resource' and
> >'content'?  I'm not too sure.. I think 'resources' are things like XSLT
> >stylesheets.  Not something served up to the user, whereas 'content' is.
> >By that rule, images should be in content/, not resources/.
> >
> >What do people think about changing that?
> 
> Put the sources in ./documentation/**
> 
> So we have
> 
>  ./documentation/index.xml
>  ./documentation/book.xml
>  ./documentation/images/myimage.gif
>  ./documentation/mypdf.pdf

But then what about genuine 'resources' like stylesheets, DTDs and skins?
Shouldn't they live under 'documentation' too?

> etc
> 
> One content, one dir.
>
> IIRC we had already decided on this, so it should be ok to do it.

We agreed on the principle, but I can't recall details.

About 30 mins ago I made a change whereby everything in
src/documentation/content/ is made visible to the sitemap.

Specifically in order to allow sitemap rules like:

<map:match pattern="forms/**.pdf">
  <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
</map:match>

or:

<map:match pattern="static/**/*.html">
  <map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
</map:match>

Does this sound like a reasonable interpretation of "One content, one
dir"?


--Jeff

RE: [RT] Site versioning, staging and deployment ( was Re: documentation/content made available to sitemap (Re: 'broken link' causes..))

[Robert Koberg <ro...@koberg.com>]

Hi,

> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, November 05, 2002 2:13 AM
>
> These are the requirements I think I have understood:
>
>    1) the system must be updateable to the live site manually
>    2) an automatic system may be used to generate a dev
>       version of the site
>    4) the source must be committed to a VCS
>    5) the results of the docs build must be committed to a VCS,
>       to keep history of the generated version
>    6) an automatic system may publish the site from VCS with a
>       sensible time delay, possibly random to minimize the
>       possibility of bad content being pushed intentionally
>       or erroneously on the site

content, pages and folders could have some status property to indicate their
current state (editorial, archive, static, etc). This could or could not be
observed by the build system to only build what is appropriate for the stage of
the project.

>    7) the automatic publishing system must run from the
>       destination site for security reasons: it will
>       _pull_ content from the generation site.

I would think that you *should* copy to the live site. The site should be
developed, tested, certified, then copied to 'live.'

When it is certified, it is like a gold master from CDROM days

Staging is nothing new - I did not come up this methodology - it is tried and
tested. I think it also shows your client/whoever-you-serve that you are taking
a professional approach to the project's development. It simplifies things a
great deal. You always are sure that only a certified site will be pushed live.

best,
-Rob


>    8) The document build system should not reside in VCS;
>       it's recommended that in VCS there is an automated
>       system to aid in the installation of the build system.
>
>
> I don't agree with all, but nevertheless we must address them, and come
> to a solution to all the _needs_ that bring users to define these
> requirements.
>
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>               - verba volant, scripta manent -
>      (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>

[RT] Site versioning, staging and deployment ( was Re: documentation/content made available to sitemap (Re: 'broken link' causes..))

[Nicola Ken Barozzi <ni...@apache.org>]

Robert Koberg wrote:
 > Hi,
 >
 > <rambling>
 > What about using subversion as the repos? You can set properties +
 > on a 'thing'.
 > Then some bright cocoon or forrest developer can come up with a way
 > to merge these properties into some kind of mapping XML to be used
 > in the transformation.
 >
 > In fact the subversion repos could serve the appropriate version
 >  of the site (to all stagiing environments).
 >
 > You can also get conflicts back as well-formed XML so sometimes,
 > you might be able to fix a merge or provide a gui for
 > non-technical users to fix it.
 > </rambling>

I think that it's in the best interest of the users to have an all-java
solution in Forrest, and be able to use the filesystem as now, so I 
won't want to tie Forrest to subversion.
Besides, Jakarta Slide is a CMS in Java that can use WebDav and 
eventually use Subversion as a backend too.

That said, the fact you brought up subversion gives me the opportunity
to start a discussion about how to manage real-life Forrest sites.

With Mr. Rodent, we have talked about what his expectations were with 
Forrest usage, and I summed them up in my head with all the other stuff 
heard on the dozen lists I have polled.

These are the requirements I think I have understood:

   1) the system must be updateable to the live site manually
   2) an automatic system may be used to generate a dev
      version of the site
   4) the source must be committed to a VCS
   5) the results of the docs build must be committed to a VCS,
      to keep history of the generated version
   6) an automatic system may publish the site from VCS with a
      sensible time delay, possibly random to minimize the
      possibility of bad content being pushed intentionally
      or erroneously on the site
   7) the automatic publishing system must run from the
      destination site for security reasons: it will
      _pull_ content from the generation site.
   8) The document build system should not reside in VCS;
      it's recommended that in VCS there is an automated
      system to aid in the installation of the build system.


I don't agree with all, but nevertheless we must address them, and come 
to a solution to all the _needs_ that bring users to define these 
requirements.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
              - verba volant, scripta manent -
     (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-- 
Nicola Ken Barozzi                   nicolaken@apache.org
              - verba volant, scripta manent -
     (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: documentation/content made available to sitemap (Re: 'broken link' causes..)

[Robert Koberg <ro...@koberg.com>]

Hi,

<rambling>
What about using subversion as the repos? You can set properties on a 'thing'.
Then some bright cocoon or forrest developer can come up with a way to merge
these properties into some kind of mapping XML to be used in the transformation.

In fact the subversion repos could serve the appropriate version of the site (to
all stagiing environments).

You can also get conflicts back as well-formed XML so sometimes, you might be
able to fix a merge or provide a gui for non-technical users to fix it.
</rambling>

best,
-Rob

> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, November 04, 2002 8:37 AM
> To: forrest-dev@xml.apache.org
> Subject: Re: documentation/content made available to sitemap (Re:
> 'broken link' causes..)
>
>
>
> Jeff Turner wrote:
> > On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
> >
> >>Jeff Turner wrote:
> >>[...]
> >>
> >>>While I'm clarifying.. what's the difference between a 'resource' and
> >>>'content'?  I'm not too sure.. I think 'resources' are things like XSLT
> >>>stylesheets.  Not something served up to the user, whereas 'content' is.
> >>>By that rule, images should be in content/, not resources/.
> >>>
> >>>What do people think about changing that?
> >>
> >>Put the sources in ./documentation/**
> >>
> >>So we have
> >>
> >> ./documentation/index.xml
> >> ./documentation/book.xml
> >> ./documentation/images/myimage.gif
> >> ./documentation/mypdf.pdf
> >
> >
> > But then what about genuine 'resources' like stylesheets, DTDs and skins?
> > Shouldn't they live under 'documentation' too?
>
> Meta-content? Seems reasonable as you say.
>
> So maybe  ./documentation/content/** and  ./documentation/resources/**
> is better after all...
>
> >>etc
> >>
> >>One content, one dir.
> >>
> >>IIRC we had already decided on this, so it should be ok to do it.
> >
> >
> > We agreed on the principle, but I can't recall details.
> >
> > About 30 mins ago I made a change whereby everything in
> > src/documentation/content/ is made visible to the sitemap.
>
> Yup, say it.
>
> > Specifically in order to allow sitemap rules like:
> >
> > <map:match pattern="forms/**.pdf">
> >   <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
> > </map:match>
> >
> > or:
> >
> > <map:match pattern="static/**/*.html">
> >   <map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
> > </map:match>
> >
> > Does this sound like a reasonable interpretation of "One content, one
> > dir"?
>
> Hmmm... nope, not all yet... we should use the resource-exists action too.
>
> I'll give it a shot.
>
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>

Re: documentation/content made available to sitemap (Re: 'broken link' causes..)

[Nicola Ken Barozzi <ni...@apache.org>]

Jeff Turner wrote:
> On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
> 
>>Jeff Turner wrote:
>>[...]
>>
>>>While I'm clarifying.. what's the difference between a 'resource' and
>>>'content'?  I'm not too sure.. I think 'resources' are things like XSLT
>>>stylesheets.  Not something served up to the user, whereas 'content' is.
>>>By that rule, images should be in content/, not resources/.
>>>
>>>What do people think about changing that?
>>
>>Put the sources in ./documentation/**
>>
>>So we have
>>
>> ./documentation/index.xml
>> ./documentation/book.xml
>> ./documentation/images/myimage.gif
>> ./documentation/mypdf.pdf
> 
> 
> But then what about genuine 'resources' like stylesheets, DTDs and skins?
> Shouldn't they live under 'documentation' too?

Meta-content? Seems reasonable as you say.

So maybe  ./documentation/content/** and  ./documentation/resources/** 
is better after all...

>>etc
>>
>>One content, one dir.
>>
>>IIRC we had already decided on this, so it should be ok to do it.
> 
> 
> We agreed on the principle, but I can't recall details.
> 
> About 30 mins ago I made a change whereby everything in
> src/documentation/content/ is made visible to the sitemap.

Yup, say it.

> Specifically in order to allow sitemap rules like:
> 
> <map:match pattern="forms/**.pdf">
>   <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
> </map:match>
> 
> or:
> 
> <map:match pattern="static/**/*.html">
>   <map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
> </map:match>
> 
> Does this sound like a reasonable interpretation of "One content, one
> dir"?

Hmmm... nope, not all yet... we should use the resource-exists action too.

I'll give it a shot.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------