Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips

Bugs and suggestions

Like Mark W, I have to consider it a bug that the following doesn't work:

{$foreach x in keyword_contains "Index"$}
{$foreach y in (and (folder {$x.extra1$}) (not keyword_contains "Index"))$}
<li><a href="{$$}">{$y.headline$}</a></li>

The problem being that (folder {$x.extra1$})  is not parsed the way I'd like it to be. In fact, I don't see any way to use a variable as a parameter to a condition.

Also, it would be useful to have an article field to hold the folder name.

Jeff Paulsen
Saturday, March 23, 2002

You're right. This is similar mine. The expression is parsed before the {$x.extra1$} or {$.filename$}.

I know this gets funky when you do nested looping, or even normal looping for example:

{$foreach x in (blah) $}

and blah contains:


how can it parse {$.headline$} in a *different* article before bringing it in? It can only bring it in and then learn it has to parse it. but wait, this works, okay so it parses {$.something$} when it finds it, but not when it's in a foreach?

if it runs through the whole site and parses every {$.something$} before any {$foreach$} it would require a TON of memory as the site got larger - imagine a site with 5,000 pages and 500 variables, and each page had {$.headline$} {$.author$} {$.body$} which they all probably do. You'd have upwards of a hundred thousand variables in memory at this point.

A potential step that would bloat the database & slow down the program would be to store these variables with the article in the database, and then bring those in for parsing.

CityDesk could immediately parse every {$.something$} when it finds it. Would this break any current sites or significantly slow down CityDesk? Or how about this, CityDesk could immediately parse any {$.something$} when it finds it in a condition. Ah, that sounds like a good solution. Why doesn't it parse {$.something$} when it finds it in a condition?

Also, why am I able to name an article {$.filename$}...

Okay, I'm rambling and should probably edit this post to get rid of all of the dead end lines of thought, but I'm giving it to you as-is.

Mark W
Saturday, March 23, 2002

I just want to be sure I got this right.

1) CityDesk parses each {$  statement in an article.

2) It doesn't parse any {$  statements while it's parsing another statement.

3) It then looks through the article again to see if there are any more {$ statements to parse.

It keeps doing this, unless it detects an infinite loop.

When a condition is a {$ $} it never gets parsed because CityDesk encounters things in this order:

{$foreach x <- parses this statement
in (condtion) $}

<a href="{$$}"> <-- pulls this in without parsing it
{$x.headline$}</a> <br> <-- pulls this in without parsing it

For example, I just created an article with the body {$.headline$} and pulled it in to another page with a loop. The headline I got was the one that pulled it in, not the one BEING pulled in.

This would, in effect, break any site that has {$.headline$} in an article body if they did something like create an article that brings every page on their site into it.

Here's my example of it:

if CityDesk parsed every {$ when it found it several things would happen:

1) templates that use articles as parts of the template would break - I couldn't expect {$.headline$} to work right, it would display the article it was in rather than the article it was being pulled into.

2) the time it takes to build a site might increase? it would certainly take more memory to do it because it would have to put loop a on hold while it parsed loop b.. by the time you got to nested loop z, you'd have 26 loops in memory.

so is there any way we can just get this turned on for conditions?

Mark W
Saturday, March 23, 2002

CityScript can't have CityScript as a parameter.  At least not in v.1.

So you can't do things like {$foreach x in (folder {$x.extra1$}) $}

because the folder clause is a parameter.

Michael H. Pryor
Saturday, March 23, 2002

Is this the party line?

Mark W
Saturday, March 23, 2002

*  Recent Topics

*  Fog Creek Home