itistoday wrote:it seems like creating a page for each of those is the solution you're looking for [...]

... I'd consider splitting all of your pages into separate files

Each of those URLs is (when stripped of the domain name) the ID of an entry in a database. It made sense to me to have a single 'design' or template which was then applied to the information when extracted from the database. I'll have another look at the documents and work out how to do it the new way.

cormullion wrote:Each of those URLs is (when stripped of the domain name) the ID of an entry in a database. It made sense to me to have a single 'design' or template which was then applied to the information when extracted from the database. I'll have another look at the documents and work out how to do it the new way.

Ah! Gotcha, sorry, I didn't know that's what you were doing, and my sincere apologies if you mentioned it (I must have missed that part *whoops*).

In that case then a custom-route is the way to go, and yours should be extremely simple. For info on how to create a route (as well as an example) see this page:

Also, I'm puzzled by how the question mark in the URL routes (eg "?welcome") disappears when I'm using Apache, but appears when using newLISP server. Why is that? It's making the search fall over but it works locally using newLISP server...

cormullion wrote:What's the best way to do Atom/Rss? I've got the code to provide the information, not sure about the routes...

If you're serving a static file for your feed then you can just add its extension to the STATIC_TRIGGER_EXTENSIONS in the config.lsp.

You're probably generating it on-the-fly though, so that's probably not what you want.

Instead just make a view (i.e. /feed) and place your newLISP code that outputs your Atom/RSS feed in it. Make sure to set the proper MIME-type though somewhere in there. I.e. place a call like this in your feed view somewhere:

That function is from the example-site, it's defined in plugins-active/dragonfly_basic.lsp and uses the symbol DF:viewname (which is set by the STATIC_TRANSFORMATIONS in config.lsp).

Also, I'm puzzled by how the question mark in the URL routes (eg "?welcome") disappears when I'm using Apache, but appears when using newLISP server. Why is that? It's making the search fall over but it works locally using newLISP server...

newLISP doesn't support the .htaccess redirection that apache does (see the explanation in the Getting Started part of the User Guide), and Dragonfly uses the QUERY_STRING to determine which view/resource is being accessed.

However, I've just added functionality to the mercurial repository that removes the need for the ? even when using the built-in newLISP server.

Not really, I'm not sure why you're outputting the head/story/footer as you're not displaying an HTML document but an RSS/Atom feed.

where the partial files are called head.xml story.xml and foot.xml. (Or should they be 'html'?)

Check the docs for VIEW_EXTENSION. It's also documented via comments in config.lsp.

If VIEW_EXTENSION is .html, they should be .html if you're using the display-partial/display-view functions. Use display-file/include if you want to avoid the use of VIEW_EXTENSION. See the Dragonfly API for details.

5 the header for the main web page refers to the XML feed using this function:

Hmm... that's actually outdated (from pre-0.50), I'll fix that. 'web-root' should not have the ? specified in the string and there's no need for the "/xml" after "dragonfly_rssfeed".

or does there need to be an 'atom' version of this?

If you want to display an atom feed include the appropriate markup to display atom feeds. I personally don't recommend relying too heavily on Dragonfly's markup-shortcut functions like 'rss', it's just as easy to include the actual HTML markup (check what 'rss' does, it's defined in dragonfly_basic.lsp, it's just a shortcut for the the 'link' tag to include an rss file in the page). If you're confused, check with google.

OK, gotcha. I've probably been assuming that I should switch to '.xml' extensions at some stage but sticking with 'html' all the way helps - at least, hitting http://unbalanced-parentheses.nfshost.com/atom seems to want to produce Atom XML.

The head/story/footer stuff is just so that I can output the XML heading stuff (author update etc) and then loop through each of the last x items.

I have one more problem... I'm finding that some pages are being processed through Dragonfly but I didn't think they were going to be (they're not views). For example, if you go to http://unbalanced-parentheses.nfshost.com/downloads/mycroft.nl.html - it's a page generated by newlispdoc - and click on source, the resulting HTML file is being passed through Dragonfly:eval-template. Unfortunately that file contains text (probably multiple [text][/text] pairs) that causes eval-template to fail. It's not supposed to be a template.

It will match all files that end in VIEW_EXTENSION, and your source page does as well. Therefore if there are any "code islands" (i.e. stuff that comes after OPEN_TAG: <%) then that will be interpreted as newLISP code and it will be evaluated.

If you don't want that file getting sent through eval-template then there are several things you can do:

- Update your .htaccess file with a RewriteCond to prevent files ending in .src.html from being sent to the index.cgi script. This requires knowledge of .htaccess files (search google for mod_rewrite).

- Do it instead through a custom route that checks if the QUERY_STRING represents one of your source files and then simply pass it through the 'display-file' function. Make sure this route is added to the front of 'DF:dragonfly-routes' so that it gets evaluated before Route.Static.

- Change your VIEW_EXTENSION to something else (and change all your template files as well to that other extension).

In a future version of Dragonfly we could probably add a hook to Route.Static that will allow you to define a function that determines whether the file should be passed through display-view or display-file (as the former sends it through eval-template and the latter doesn't), but for now your easiest solution is to add a custom route, which isn't difficult to do (again, the docs really help you here).

cormullion wrote:OK, thanks! I can solve it by passing it to DF:include... I didn't fully appreciate the fact that every matching file, not just a view file, is passed through eval-template. Makes sense now, though.

Ack! Sorry for giving you bad information, I've edited my post to mention that DF:include is what you want, not DF:display-file. You figured it out though. :-)

I have to admit that I've studied the documents, but still find it hard to solve problems - I'm not a web developer, so I don't have the basics down yet.