Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

My thoughts on Templates

I have a question about the way people are using Templates.  I wonder if people are trying to do what I am attempting to do.

I am working on my first CD project, for a client that is going from a small, static site to a larger site in which every page will have dynamic content.  That is, the staff will have the ability to edit the content of every page. 

They will also have the ability to add sub-sections, and links to these will have to appear in the left-hand navbar of the parent page.

My philosophy in building such template-based systems has always been that the user NEVER HAS TO EDIT A TEMPLATE.  Template represent the program code.  If the user (that is the staff writing stories and adding sections) has to edit a template, then this is the equivalent of asking them to become computer programmers in order to use your program.

This means that a certain structure for each section must be defined, and a template must be able to traverse that structure in order to generate the pages for that section.  But, more immportantly, the SAME template should be able to be applied to different sections within the overall site structure.  It should not matter where within the overall structure the template is executed as long as it is traversing the same CD directorty structure.

Consider:

index
Support
    index
    Articles
    Files
    Links

Opportunities
    index
    Articles
    Files
    Links
    Volunteer
        index
        Articles
        Files
        Links
    Part-Time
        index
        Articles
        Files
        Links
    Full-Time
        index
        Articles
        Files
        Links
Activities
    index
    Articles
    Files
    Links
    Children
        index
        Articles
        Files
        Links
    Adult
        index
        Articles
        Files
        Links

A single template should be able to be applied to each "index" page.  The template, while being applied irrespective of its location in the directory tree, should be aware of its location so that it can customize its input and output. 

CD does not currently allow, for example, the same template to traverse different sub-directories unless they have identical names.  See, for example, the index page (the "landing page") for Opporunities and Activities.  In this case, we need two almost identical templates.  If the user wants to add another category, she will have to add another template, requiring her to become a programmer.

CD does not currently allow, for example, the same template to output different code depending on "where" it is.  The user might want to define a different look and feel to different sections.  This can be easily accomplished with Cascading Style Sheets.  All the template would have to do is output class names that are appropriate to the location of the page it is generating.  Again, because this is not possible, almost identical templates need to be defined. 

The result is that:
1) There is a proliferation of templates that are almost identical.
2) This leads to a maintenance nightmare, which is exactly what templates are meant to avoid.
3) The users are forced to become programmers if they want to add a section to the site.

The solution is that templates must be more aware of what page they are generating.  The Article retrieval mechanism must be more flexible, accepting variables that address this issue of location and sub-folder naming.

I wonder if these comments resonate with any other developers who are using CD?

Joel Finkel
Tuesday, March 25, 2003

Joel,

I agree that an index page template should be able to generate different content based upon where it is, like:
Foreach article in my folder.  There also needs to me a recursive option to handle sub-folders (and an exclude option?).

David Burch
Tuesday, March 25, 2003

To correct myself, the keyword Not acts to exclude files.

David Burch
Tuesday, March 25, 2003

Yeah, I'm hoping that the new scripting in CityDesk (Joel has hinted before at using something like JavaScript) will be a more complete programming language, with the ability to do all this sort of stuff.

Darren Collins
Tuesday, March 25, 2003

I don't use folders to organise presentation at all. My articles all have keywords to control which section(s) the article appears in, which is more flexible. I also use this to build menus automatically.

The only thing you'd need in CD to create user-defined sections using this mechanism is more complete expansion - ie, deeper than 2 levels, and in the "condition" section of "loops".

If I had this, I could add a menu item for a new section, using (say) extra2 in the menu-item article to define the keyword for articles in that section. Then the template for the menu-item body can iterate through the articles. This seems to be the context-sensitivity you're looking for. The only reason it's not possible now is that you can't write things like :

{$foreach article in (keyword_contains "{$.extra1$}")$}
<a href={$article.link$}>{$article.headline$}</a>
{$next$}

because CS isn't expanded in foreach conditions - a problem that's been discussed elsewhere in this forum.

Associating the right stylesheet is trickier, unless you just bang its name into a field in every article. The keywords field contains a keyword indicating which one you want, but there's no easy way of extracting it, or even knowing which it is.

However a simple extension of which fields you can use as conditions would solve this - the fragment above would become :

{$foreach article in (extra1 "{$.extra1$}")$}
<a href={$article.link$}>{$article.headline$}</a>
{$next$}

and assuming stylesheets were kept in articles, with author "ss" and keywords indicating which section(s) they applied to, the stylesheet would be selected by :

{$foreach 1 ss in (and author "ss" keyword_contains "{$.extra1$}")$}
<link rel="stylesheet" type="text/css" href="{$ss.link$}" />
{$next$}

Michael Wild
Wednesday, March 26, 2003

I avoid keywords - it's too much of a pain to remember which keywords to define in which articles.

I just want to hit control-N, (switch to HTML view and) start typing, and have the right thing happen automatically.

Pat Rice
Wednesday, March 26, 2003

Michael,

You have an intertesting approach.  How do your users like what you have built?

My philosophy has been to build the CD directory structure to mirror the actual site structure.  This allows the users (that is the staff), who are editing articles, to understand more intuitively what they are doing and how their content is going to be displayed.

I am still in development, however, and do not really know how the users are going to react. 

I also want them to use all the other Article "buckets" such as extra1, extra2, and teaser, for actual content, not for programmatic information. 

My ONLY concession is the keyword field, which I use to order Articles in automatically-generated navbars.  This is because the order is not guarenteed if it is not specified, so it must be specified by SOMETHING.

Joel Finkel
Wednesday, March 26, 2003

Joel, the order is guaranteed if it's not specified. The order will be the same as the order the articles are listed in the main window.

I use this a bit, as it's fairly intuitive to non-technical users. If they want to reorder things, they can just move them around how they want them.

Darren Collins
Wednesday, March 26, 2003

I use both folders and keywords to organize my site.  I have a lot of content that is geographically related and a folder hierarchy makes sense.  Folders also help me easily organize, file and find articles.

I also use keywords because my articles can fit in more than one category.

David Burch
Wednesday, March 26, 2003

David - that's what I do with my site. I also make sure I put a condition that won't pull anything into the loop with the keyword (noindex). Here's one of my loops:

{$foreach x in
(and
(or (keyword_contains "(technology)")
    ( folder "technology")
)
  (not
    (keyword_contains "(index)")
  )
  (not
    (keyword_contains "(noindex)")
  )
)
sortdescendby .fileddate$}
<P><A href="{$x.link$}">{$x.headline$}</A><BR>
<SPAN class=teaser>{$ setDateTimeFormat "English" "MM/dd/yy" "hh:mm" $} {$x.filedDate$} <BR>
{$x.teaser$}</SPAN> </P>{$next$}

www.marktaw.com
Wednesday, March 26, 2003

Darren,

You say that:

"the order is guaranteed if it's not specified. The order will be the same as the order the articles are listed in the main window."

However, I have not seen this documented anywhere, and I assume that it is dependent on the underlying database technology, which is subject to change. 

If CD stated that this was guarenteed, then I would consider using it, but then only if there were an aditional confirmation required to alphabetize a CD directory or a method to disable this option.  This is a end-user issue: you want the system to be fool-proof, if not idiot proof.

Joel Finkel
Friday, March 28, 2003

"If you do not specify a sort order at all, CityDesk will list the articles in the order in which they appear in the main window. To change the order, see Manipulating the Site Tree."

- from the CityDesk help file under Scripting With CityDesk / Creating a Loop

www.marktaw.com
Friday, March 28, 2003

Thanks!

Joel Finkel
Wednesday, April 09, 2003

*  Recent Topics

*  Fog Creek Home