Turning off SSI

[Igor Galić <i....@brainsware.org>]

Hey folks,

I talked to infra (well, Joe) and they would like to see
SSI turned off on our vhost

it appears there's a much simpler way to implement our
navigation using the CMS' philosophy more directly.

  < joes4> jMCg: can we finally shut off ssi for trafficserver?
  < jMCg> joes4: I'm afraid not: For two reasons: The old docs still use it, and the new docs use it for the navigation.
  < gmcdonald> cms has its own nav includes
  < joes4> bad design jMCg
  < joes4> should just enable it for the old docs
  < jMCg> joes4: how am I supposed to generate the nav for the CMS without regenerating all the pages?
  < joes4> why wouldn't you want to regenerate all the pages?
  < joes4> you just drop the nav stuff into templates
  < joes4> and include those templates into your main template
  < jMCg> joes4: that.. makes sense.
  < jMCg> Well, except that the nav is different for different subtrees.
  < joes4> there's no point to ssi with the cms
  < joes4> you need to break out that logic in your path spec
  < joes4> template names can be parametrized
  < jMCg> joes4: ACK, will discuss with amc.
  < joes4> in your path.pm pass a variable which represents the name of the nav template to use
  < joes4> and in your main template use that variable with an include statement
  < joes4> no perl code necessary in view.pm
  < joes4> that is the standard way of doing nav
  < joes4> with django templates
  < joes4> might require an eval if you want to use a piece of the path as the argument
  < joes4> lemme look at the build system
  < joes4> yes so if you went that route i don't recommend monkeying with path.pm
  < joes4> just use captured variables in your regexp and reference them in the corresponding view
  < joes4> and in there add something to %args
  < joes4> it'd probably be worthwhile to document your steps at cmsref.html

So long,

i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE

Re: Turning off SSI

["Alan M. Carroll" <am...@network-geographics.com>]

Joe's suggestion doesn't address the problem which is outdated information in the navigation tree on page A because of a change to page B.

Using his suggestion, the included file is included at the time page A is built. If page B is changed, the include on page A (the navigation tree) is not updated, it remains as it was when page A was built. With SSI, the navigation tree is included at the time the page is served, which means the included information is up to date (that is, accurate).

On the other hand, if the entire site was built when any file was changed, then Joe's suggestion might work. It might depend on the ordering of processing of page A and page B. Our current solution (with or without SSI) would work for either order because of how the code is structured.

The fundamental issue is that a change to page B may cause content on an arbitrary number of other pages to be updated. As far as I can tell, that must be done either through always doing a site build, or using SSI. I would prefer always building the site, personally.

Re: Turning off SSI

[Igor Galić <i....@brainsware.org>]

----- Original Message -----
> Hey folks,
> 
> I talked to infra (well, Joe) and they would like to see
> SSI turned off on our vhost
> 
> it appears there's a much simpler way to implement our
> navigation using the CMS' philosophy more directly.
[snip]
>   < joes4> it'd probably be worthwhile to document your steps at
>   cmsref.html

So it seems that Joe already did that since yesterday(?):

  < joes4> jMCg: i wrote docs on per-dir navigation and posted them
  http://www.apache.org/dev/cmsref.html#navigation

So long,
i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE