Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

Citydesk best use practices?

I would appreciate if long time users could share some of their practices using citydesk.

1. When do you use regular (non article type) html files?

2. Who would actually share their project files? I'm hoping to learn even more from actually looking at how people do things.

Thanks in advance for help!

Maurice Fäh
Wednesday, May 19, 2004

Hello Maurice,

"1. When do you use regular (non article type) html files?"

Never.

"2. Who would actually share their project files? I'm hoping to learn even more from actually looking at how people do things."

Did you go here http://templates.fogcreek.com/. All my websites are based on one of those templates. The rest is filling in the articles. The only thing i used besides that are a couple of perl scripts for a contact form.

PeterM
Wednesday, May 19, 2004

Hi Peter

I had come across this template area before. But didn't have closer look. I will do this now. Thanks!

But I am also looking for examples on how to structure things.

For example:

The Citydesks help file that Fogcreek created (it's available in the Citydesk news area), shows that they created the main menu list looping trough all articles in a folder called "Top_Level". Each of these articles in turn loops trough another folder containing articles...and so on.

Maurice Fäh
Wednesday, May 19, 2004

Here a list of CityDesk sites that I know of:
http://tk-jk.net/city/Articles/OtherCityDeskSites.html

If you know of more, I'd be happy to list them.

I'm sure many of the publishers would be willing to share an emptied out .cty file with you. Most of them are beyond me and many are extraordinary. I've asked several folks, "how did you do that?"

tk
Wednesday, May 19, 2004

I use "non-article html type" files when I use ASP pages within a site, although I copy the html for the template from an empty article to give a consistent look and feel.

Provided that you avoid opening the ASP pages outside of the html view all is well ( to view ASP pages working you obviously need to view it through a web server).

BTW - I'm now using CD as my main Web development tool instead of Interdev - brownie points to Spolsky et al.

Andy Gray
Wednesday, May 19, 2004

Thanks for these inputs.

I am also quite confused, when to use Cityscript in articles. I would have thought, that the ideal place for that would be the template.

Would you share suggestions for that, please?

Maurice Fäh
Monday, May 24, 2004

For me, the fewer templates the better. One template is my ideal I usually put a script for the menu in the template.

I put most scripts into articles but even then, I don't have that many scripts in any site. Here's a index page (an article) that has:

One script in the template that generates the menu

5 scripts in the article to generate "Current Euphonic Shows," "Current Notes, " Euphonic Shows," "Non-Euphonic (and out-of-town) shows," and "Euphonic recommends"

This page:
http://tk-jk.net/euphonic/blog/general/Euphonicshows.html
Has 2 scripts, one that lists the upcoming shows, and one that lists the previous shows.

It's worth looking at John Conners' web log template:
http://www.johnsadventures.com/backend/WeblogTemplate/ACityDeskWeblogTemplate.html

tk
Monday, May 24, 2004

Dear tk

But when you put cityscript in articles, then every other content contributor has to know how to write scripts too. Isn't that contrary to Citydesk's "philosophy", which is to separate concerns of designers and contributors?

designers:
design templates and site structure...

content contributors:
write articles, and might occasionally select a variable...

Sincerely

Maurice Fäh
Monday, May 24, 2004

In this case, nobody works on the home page. It's all generated from scripts. I only add articles about performances. The home page pulls all those articles together.

tk
Monday, May 24, 2004

I try to put scripts into variables whenever I can. There are several benefits:

- It prevents CityDesk from munging the HTML around your script when changing views (e.g. adding extra <p> tags, messing up <li> tags, etc).

- Non-technical users can understand that {$.latestArticles$} inserts a list of the latest articles into their article. Much better than giving them a script to insert, which they'll be afraid of and likely mistype.

- If you want to change the script, you just do it in one place and all your articles are updated.

The biggest downside is that CityDesk currently doesn't have a very nice interface for managing and inserting variables.

Darren Collins
Monday, May 24, 2004

Dear Darren

It looks like I'm automatically also gravitating towards putting scripts in variables.

I agree, that there are shortcomings in the variable environment:

1. The ability to hide certain variables from article contributors is missing.

2. Being able to translate a variable in the side by side editor would make things much easier.

3. Grouping all language versions of the same variable would be helpful.

4. Being able to sort the list of veriables is a must.

5. A WYSIWIG view of the executed Cityscript would be heaven.

:-) Anything else anyone?

Maurice Fäh
Tuesday, May 25, 2004

I don't have a page to point to as an example, but I like to add a "navList" variable to list pages like Home, Contact, About. Without using the exact syntax here (imagine the angle brackets/curly brackets rather than square; also the ".navList" defined in the CSS), it goes something like:

[ul class="navList"]
$foreach x in (and(not(thisArticle))(keywordContains "mainmenu)))$
[li][a href="[$x.link$]"][$x.headline$][/a][/li]
[$next$]
[/ul]

Put this in the template if you want it on every page. Or for a different subsection menu, a similar loop goes into a variable that plugs into the sidebar field.

I try to use variables rather than [$include "foo/bar"$]. It makes for less clutter in the cty file--and these includes which CD only uses to generate the page don't get uploaded to the server where they aren't needed (I use only static pages however, no serverside scripting).

JackHammer
Wednesday, May 26, 2004

Oh, and the only way I've found to "sort" variables is in a very rudimentary way. For instance, variables containing scripts that might be used only once in a template, never in articles, I name beginning with "z" ("[$z.CounterScript$]") just to keep them at the bottom of the list. That's as far as I got with a "system". It might be something to think about, grouping variables by name according to whether they're used in articles for content/formatting or for scripting.

My above comment was a little misleading: I do put JavaScript into variables...even though I always edit templates/indices in HTML View, I've found it's still safer to keep them in variables.

JackHammer
Wednesday, May 26, 2004

>>But when you put cityscript in articles, then every other content contributor has to know how to write scripts too. Isn't that contrary to Citydesk's "philosophy", which is to separate concerns of designers and contributors?

>>designers:
design templates and site structure...

>>content contributors:
write articles, and might occasionally select a variable...


OK...I come from a single-user perspective, but I guess it depends on whether you want to make things as easy as possible for the contributors--you want the contributor to have variables they might use, such as for boilerplate text, or some horizontal rule or other bit of formatting they want to easily put in, as well as text that might be "flavorDuJour" but don't want them accidentally inserting something that doesn't belong. "Don't select any variable beginning with Z!"
In this case, I suppose it would be possible to create directories to keep scripts in, whether they're CityScript or JavaScript (except that the JavaScript would be a .js file created outside of CityDesk and dragged to the directory), and call them using "include" in the template or index. But as a single user, I prefer to keep as many scripts as possible in variables. I can see, however, accumulating an unweildly list of them...eventually.

I've never found any reason to use HTML files. Better to make it in HTML View in CityDesk, in order to take advantage of CityDesk's capabilities, or (rarely) I might copy an existing HTML file into CD. The best part is CD's taking care of all the relative links in the page (one might someday want to change to a new stylesheet, even if the other relative links remain stable), as well as being able to add keywords and all the other fields, specifying a different template...

Speaking of templates, the default Simple template and the basic.css _can_ serve as a beginning, but they basically need to be gutted and completely overhauled. I'm not just talking about the look; it's not all that elegant under the hood either. (Yes, I realize there are other templates available to download, and I'm sure they're better, but I like to roll my own.)

JackHammer
Wednesday, May 26, 2004

Thank you all for this great feedback!

It think, that there's no difference between what can be accomplished (functionally) by using Cityscript in an article or by using it in a template.

So I will use Cityscript in templates when I'm dealing with content in structures that won't change, and I'll use Cityscript in articles when I can't be sure what a content structure will eventually look like or if content output requirements will probably change frequently.

Maurice Fäh
Friday, May 28, 2004

...and when it comes to regular HTML files, I^ll just say no :-)...

Maurice Fäh
Friday, May 28, 2004

*  Recent Topics

*  Fog Creek Home