Getting started docs. Question re: SSI and OCs.

Hi ho,

I'm working (still!) on a bunch of getting started docs. I'm
trying  
to describe (and double-check by doing it) the process of
setting up  
the appropriate story elements and the necessary Output
Channel to  
generate server-side includes that would be included by the
front-end  
server. However, I've hit a bump that I recall hitting
before ...  
and, before I just document the workaround I used last time,
I wanted  
to double-check the options...

So, let's say that you have a "Navigation menu"
story (Fixed). And  
that uses "Server-side include" as the primary
output channel. And  
that the Server-side include OC is set to "Use slug for
filename,"  
and has the following settings:

URI Format: /%/%/
Fixed URI Format: /%/

At first, I'm able to easily create a story called
"Header  
navigation" and use a slug of header_navigation and
generate a /ui/ 
ssi/header_navigation.html file that can be included in
other files.  
This is lovely, and obvious.

However, when you next go to create  your "Footer
navigation" file,  
with footer_navigation as the slug, and /ui/ssi/ as the
category, you  
get the infamous "The URI "/ui/ssi/" is not
unique. Please change the  
cover date, output channels, slug, or categories as
necessary to make  
the URIs unique." message.

In the past, I simply changed the Fixed URI Format to
/%/% 
/ and turned of the Use slug for filename option to
generate  
files like: /ui/ssi/header_navigation/index.html

That works fine, but does seem like a non-obvious
workaround. Is  
there another option for folks to use?

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
	

Hey, I like to think of it as an elegant workaround. Every
include in 
its very own directory! How tidy!

Seriously, this is exactly how it works on the Sportsnet
site.

Cheers,

Bret

Phillip Smith wrote:
> 
> Hi ho,
> 
> I'm working (still!) on a bunch of getting started
docs. I'm trying  to 
> describe (and double-check by doing it) the process of
setting up  the 
> appropriate story elements and the necessary Output
Channel to  generate 
> server-side includes that would be included by the
front-end  server. 
> However, I've hit a bump that I recall hitting before
...  and, before I 
> just document the workaround I used last time, I wanted
 to double-check 
> the options...
> 
> So, let's say that you have a "Navigation
menu" story (Fixed). And  that 
> uses "Server-side include" as the primary
output channel. And  that the 
> Server-side include OC is set to "Use slug for
filename,"  and has the 
> following settings:
> 
> URI Format: /%/%/
> Fixed URI Format: /%/
> 
> At first, I'm able to easily create a story called
"Header  navigation" 
> and use a slug of header_navigation and generate a /ui/

> ssi/header_navigation.html file that can be included in
other files.  
> This is lovely, and obvious.
> 
> However, when you next go to create  your "Footer
navigation" file,  
> with footer_navigation as the slug, and /ui/ssi/ as the
category, you  
> get the infamous "The URI "/ui/ssi/" is
not unique. Please change the  
> cover date, output channels, slug, or categories as
necessary to make  
> the URIs unique." message.
> 
> In the past, I simply changed the Fixed URI Format to
/%/% 
> / and turned of the Use slug for filename option
to generate  
> files like: /ui/ssi/header_navigation/index.html
> 
> That works fine, but does seem like a non-obvious
workaround. Is  there 
> another option for folks to use?
> 
> Phillip.
> 
> -- 
> Phillip Smith,
> Simplifier of Technology
> Community Bandwidth
>     
> 
> 
> 


-- 
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com

On Oct 31, 2007, at 10:40, Phillip Smith wrote:

> However, when you next go to create  your "Footer
navigation" file,  
> with footer_navigation as the slug, and /ui/ssi/ as the
category,  
> you get the infamous "The URI "/ui/ssi/"
is not unique. Please  
> change the cover date, output channels, slug, or
categories as  
> necessary to make the URIs unique." message.
>
> In the past, I simply changed the Fixed URI Format to
/% 
> /%/ and turned of the Use slug for
filename  
> option to generate files like:
/ui/ssi/header_navigation/index.html
>
> That works fine, but does seem like a non-obvious
workaround. Is  
> there another option for folks to use?

Did you enable STORY_URI_WITH_FILENAME in bricolage.conf?

Best,

David

On Oct 31, 2007, at 1:54 PM, David E. Wheeler wrote:

> On Oct 31, 2007, at 10:40, Phillip Smith wrote:
>
>> However, when you next go to create  your
"Footer navigation"  
>> file, with footer_navigation as the slug, and
/ui/ssi/ as the  
>> category, you get the infamous "The URI
"/ui/ssi/" is not unique.  
>> Please change the cover date, output channels,
slug, or categories  
>> as necessary to make the URIs unique."
message.
>>
>> In the past, I simply changed the Fixed URI Format
to /% 
>> /%/ and turned of the Use slug
for filename  
>> option to generate files like:
/ui/ssi/header_navigation/index.html
>>
>> That works fine, but does seem like a non-obvious
workaround. Is  
>> there another option for folks to use?
>
> Did you enable STORY_URI_WITH_FILENAME in
bricolage.conf?

# URI setting. Enable this directive if you wish for story
URIs to  
always
# include their file names. This is useful for allowing
stories to be  
in the
# same category and date but have different file names and
still be
# unique. Disabled by default and not generally
recommended.

STORY_URI_WITH_FILENAME = No

I have always wondered about this. In general, I've thought
that I  
wouldn't want this applied "globally," e.g., to
all story types. But,  
now that I re-read it, perhaps it doesn't matter, as the OC
defines  
the file name.

/me goes to try that...


--
Phillip Smith,
Simplifier of Technology
Community Bandwidth

On Oct 31, 2007, at 2:42 PM, Phillip Smith wrote:

> On Oct 31, 2007, at 1:54 PM, David E. Wheeler wrote:
>
>> On Oct 31, 2007, at 10:40, Phillip Smith wrote:
>>
>>> However, when you next go to create  your
"Footer navigation"  
>>> file, with footer_navigation as the slug, and
/ui/ssi/ as the  
>>> category, you get the infamous "The URI
"/ui/ssi/" is not unique.  
>>> Please change the cover date, output channels,
slug, or  
>>> categories as necessary to make the URIs
unique." message.
>>>
>>> In the past, I simply changed the Fixed URI
Format to /% 
>>> /%/ and turned of the Use
slug for filename  
>>> option to generate files like:
/ui/ssi/header_navigation/index.html
>>>
>>> That works fine, but does seem like a
non-obvious workaround. Is  
>>> there another option for folks to use?
>>
>> Did you enable STORY_URI_WITH_FILENAME in
bricolage.conf?
>
> # URI setting. Enable this directive if you wish for
story URIs to  
> always
> # include their file names. This is useful for allowing
stories to  
> be in the
> # same category and date but have different file names
and still be
> # unique. Disabled by default and not generally
recommended.
>
> STORY_URI_WITH_FILENAME = No
>
> I have always wondered about this. In general, I've
thought that I  
> wouldn't want this applied "globally," e.g.,
to all story types.  
> But, now that I re-read it, perhaps it doesn't matter,
as the OC  
> defines the file name.
>
> /me goes to try that...


Okay: so that worked perfectly and doesn't seem to have much
impact  
on other story types, e.g., the Primary URI / URI in the
user  
interface now shows as /cat/slug/index.html vs. /cat/slug/

Why is this setting "not generally recommended"?


--
Phillip Smith,
Simplifier of Technology
Community Bandwidth

On Oct 31, 2007, at 2:46 PM, Phillip Smith wrote:

> Okay: so that worked perfectly and doesn't seem to have
much impact  
> on other story types, e.g., the Primary URI / URI in
the user  
> interface now shows as /cat/slug/index.html vs.
/cat/slug/
>
> Why is this setting "not generally
recommended"?

Isn't it because the other way reflects some web body
standard?

I think it's to future-proof your URLs. So that if you're
running .jsp 
pages today, and in two years you switch over to some crazy
futuristic 
new thing, the same document can live at the same address
even after the 
migration.

So, in my opinion, it's nicer to have every URI end in a
slash, and 
learn to love the one-directory-per-include thing.

But maybe that's just me. 

Cheers,

Bret




Matt Rolf wrote:
> 
> On Oct 31, 2007, at 2:46 PM, Phillip Smith wrote:
> 
>> Okay: so that worked perfectly and doesn't seem to
have much impact  
>> on other story types, e.g., the Primary URI / URI
in the user  
>> interface now shows as /cat/slug/index.html vs.
/cat/slug/
>>
>> Why is this setting "not generally
recommended"?
> 
> 
> Isn't it because the other way reflects some web body
standard?
> 
> 
> 


-- 
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com

On Oct 31, 2007, at 12:05, Matt Rolf wrote:

> On Oct 31, 2007, at 2:46 PM, Phillip Smith wrote:
>
>> Okay: so that worked perfectly and doesn't seem to
have much  
>> impact on other story types, e.g., the Primary URI
/ URI in the  
>> user interface now shows as /cat/slug/index.html
vs. /cat/slug/
>>
>> Why is this setting "not generally
recommended"?
>
> Isn't it because the other way reflects some web body
standard?

Yes, Cool URLs are to directories, and the server should
serve back  
the appropriate content for the request. So in theory, you
could  
request /foo/, and the server knows whether to return HTML,
XML,  
JSON, PDF, or whatever based on the request, but all are
considered  
the same document, so the URL is the same.

But It does mean that your users will be able to create two
stories  
with the same URI if the output channel uses the slug for
the file  
name or has a different file name (because index.html is
different  
from email.php).

Best,

David

On Oct 31, 2007, at 3:59 PM, Bret Dawson wrote:

> So, in my opinion, it's nicer to have every URI end in
a slash, and  
> learn to love the one-directory-per-include thing.
>
> But maybe that's just me. 

Nope. I'm convinced and will document this discussion of the
topic.  

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth