Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips

Keywords issue

Following Mr. Spolsky's comments about the power of the keywords feature, I tried the following in a template file:

{$ forEach a in (and (thisFolder) (keywordContains "{$ .extra1 $}")) $}
<li><a href="{$ $}">{$ a.headline $}</a></li>
{$ next $}

The aim of this is to provide a list with similar articles on each page.

Then, I've entered keywords into the keyword field of each article and again one keyword which represents the article well [ex: (bike)].

Intended behavior at preview/publish:
- page is generated using template
- CD grabs keyword to search for from .extra1 field of current article, CD searchs for other pages which have the same keyword and runs them through the forEach loop.

However, nothing of the sort seems to happen.

What am I doing wrong (or am I hitting the glass ceiling again)?

Saturday, August 30, 2003

I don't know the right way to explain it but you can't
(keywordContains "{$ .extra1 $}") in CityDesk yet.

Saturday, August 30, 2003

wooha... I had the same exact problem before. I posted the problem as a request for CD2, but it didn't help. i.e., using *any* {$.cityscript$} as a (condition) in a {$forEach$}.

I've got an entire project stuck solely because of this.

john doe
Sunday, August 31, 2003

geraldH :re "the power of the keywords "

The way that I read the CD help manual I understand when using “keywordContains” CD expects those keywords to be found in the "keyword" input section of the article properties dialog container.

By placing keywords in other CD fields found in the "Extras" article dialog container one does not conform to the way that CD expects to find keywords using “keywordContains”.

My suggestion is to stick with the methodology the CD Help system suggests and you should be able to accomplish what you desire. That's my take.

David Mozer
Sunday, August 31, 2003

In my post the following paragraph should read as "By placing keywords in other CD fields found in the "Extras" article dialog container - and then accessing those keywords by way of reference [like on the fly parameter passing] -- one does not currently conform to the way that CD expects to find keywords using “keywordContains”.

And I should have added: So when you have a keyword in "{$ .extra1 $}" and then expect "keywordContains" to extrapolate whatever is found in {$ .extra1 $} and then match that to the actual keyword found in the "keyword" input section of the article properties dialog container .. its not going to happen IMO because that king of "passing" is not built in just yet.

David Mozer
Sunday, August 31, 2003

David: What I'm looking for, and perhaps you can help me accomplish that goal, is to develop an "automagic" way to add related links to the bottom of a page.

I could, of course, stick something like this in the {$ .about $} field:
{forEach duh in (and (thisfolder) (not(index) (keywordContains "subject"))}
and adapt the "subject" with the keyword I want to look for, but that would mean cutting and pasting this code for every page, editing it to match the proper keyword, over and over.

However, I am looking for a more elegant solution.

Sunday, August 31, 2003

Sorry I do not currently have any auto-magic ways to suggest. The keyword principal should work very nicely assuming that each article contains the reference key word where CD expects to find it.

With proper planning this type of thing is straightforward in a structured environment like CD. That means that you need to go over each article in your database and assign the “relevant” keyword etc. It also means that you may need to keep track - via a log - of the keywords used and how those keywords are associated for reference down the line. If not done properly – keywords and their associations - can become a nightmare under certain circumstances.

The more powerful CMS systems [including DMS] out there have the ability to work [via scripting] with unstructured data applying data mining technology etc. But those systems are very expensive and cumbersome to use IMO and all of the data mining is done at the server.

Also when doing data mining via the unstructured route the processing overhead is significantly greater and that has its end-user implications. Since CD is a desktop system I suspect that tradeoffs will be made in how much power is given to the data mining engine. The bottom line is called proper planning.

David Mozer
Sunday, August 31, 2003

Far be it from me to expect local data mining from CD. Not at current CPU speeds, certainly. But the way I originally envisioned seemed to be a nice hack which would reduce manual intervention to a minimum -- i.e. filling out one field in the extras tab, done.

I don't really look forward to have a whole chunk of CityScript within an extras field, but if that's the way it has to be...

Joel: What is the rationale behind not allowing the nesting of Extras fields within keywordContains parameters, please? I presume there is a technical reason for not allowing this?

Sunday, August 31, 2003

Hmmm.. I just wanted to remind that it's a broader problem. what i wanted to do is this:

dirA\ files
dirB\ files

the $headline of the articles in both A and B is identical, so linking them from one to the other should be simple using in each of them:
{$forEach x in (and(folder "/dirA")({$.headline$}) $} <a href="{$x.fileName$}">filename</a>{$next$}

urgh. its so frustrating. i couldn't figure away around it for three weeks and i'm simply stuck.

john doe
Sunday, August 31, 2003

I think the short answer is that you can't use a self-contained CityScript command (such as {$.headline$} inside another CityScript command.

As a solution, I propose the creation of an new CityScript command {$ insert "/path/to/article" .field $} which would work similarly to the {$ include "article" $} command, with some small changes.

Presumably, {$ include $} works by getting the body of the foreign article, running that data through the script processor, and then throwing the result onto the end of an output stream that stores the file as it will be writting to the web server.

Similarly, {$ insert $} could grab a field from a foreign article, except it could leave it unprocessed, and stick it in front of the remaining unprocessed data from the current article.  The CityScript processor would then continue on its way.

Doesn't seem like it'd be too difficult to implement, as all of the functionality must exist for {$ include $} to work, and I can think of quite a few ways that some creative use of this would get around limitations in CityScript.

Monday, September 1, 2003

"output stream that stores the file as it will be writting to the web server"

Rather, as it will be written to the web server, that should say.

Monday, September 1, 2003

*  Recent Topics

*  Fog Creek Home