I put out a first version of mobile channels for antville. Just download the mobilechannel.zip file and move it to your apps/antville folder. Like I mentioned on the mailing list it doesn't work yet to create a mobileChannel, because of the lack of file extensions in the URL. But you can access the mobilePages at helma/antville/yourweblog/cdf . You also could try to create a AvantGo channel from that start page. That should work already.

Tobi, thats propably your department:

I want to create a mobile channel for pocket pc's (win ce) for antville. Mobile Channels are pretty much the same like rss, with the difference, that the Internet Explorer can use a mobile channel (which is a xml file) to download all linked items of that channel. So you can browse them offline in the subway. (what i realy would love to do )

i saw that you have all your rss.skins located in /global is there any special reason for this?

to create a mobile channel i would need to go into story, weblog and comments, because i need not just to provide a channel-xml file, but also create cdf-pages (cdf=Channel Description Format) for each story. this are the html pages you can read offline.

but i think when we .zip the functionality at the end of the process (for the live server) and make it a package this should be o.k.

i would need some hints and comments on the way how you develope at antville. (are there any don'ts ?) and: i don't have a cvs account

a good example of a mobile channel is: derstandard.at

the docs on msdn are not realy up to date. (and complete)

if you modify or add markup to any skin please check if it does not hurt the xhtml specs either by following these simple rules or even better by using the w3c html validator – at least the part you have modified/added, since not every skin has been transformed to xhtml, yet.

thanks for listening.

btw. up to now, i was validating against xhtml 1.0 only which already resulted in a bunch of error messages for most pages. now there's also the option to validate against version 1.1 which returns even worse results... should we do it with 1.1, anyway?

getting further along with rewriting and rearranging the helma documentation at hopdev, i treated myself with another gift: the list macro.

if you take a look at the introduction to the section "image processing" you'll see a list of image functions at the bottom of the text.

this list was created by the macro call <% list filter="topic" name="Image Processing" itemprefix="<li>" itemsuffix="</li>" %>

it simply loops over the stories contained in the topic named "Image Processing" and displays their titles as links to themselves.

future applications of this macro could be lists of weblogs and users, too (that's why there is that filter parameter already).

there is just one question left: with the new extended content scheme i don't have a clue how i could sort this list by titles except if i put them into an array and do it in javascript...?

btw. i checked in these modifications as well as those made for the shortcut macro into a new branch called helmaville.

yesterday, i quickly added some code to the antville installation at hopdev.helma.org (ie. what will become the future helma.org website) and fulfilled a desire i've had since i began writing parts of the helma documentation: creating shortcuts.

i don't know if or how this could be related to a request over at help.antville.org but here is how it works:

you create a short cut by entering its title (ie. the name you will use for it later) and the content (ie. what you want to spare yourself writing all the time) and then include it in a story or skin via a new macro <% shortcut name="shortcutTitle" %> (quite similar as you might be used to do with images or links).

hence, the macro will be replaced by the corresponding content of the shortcut which title equals the name parameter.

here's a screenshot of how it looks at hopdev:

e.g. the third shortcut is called by <% shortcut name="FESI" %&gt, and produces FESI as output.

and now my question: should this get into the main cvs branch of antville or not?

Yesterday I checked in a patch to the xml_content branch of the CVS that changes how Antville stores Stories and Comments in the relational DB. Instead of storing titles and bodies of stories in a separate column each, everything is encoded into an XML document using Helma's native XML extension and stored into a generic "content" column.

This great advantage to this is that it is now possible to add custom properties to stories (and, if desired, comments) with almost no effort. The only thing one has to do is to add macros for the custom parts both in the story (or comment) editor skin and in the story (or comment) skins where that part is to be displayed. Antville still requires a text property to be there, and text and title are assumed by some internal parts like the recently modified list. Other than that, there is no limit on the number and names of custom story properties.

The macro used to edit or display story properties is called content and it is very similar to the old title and text macros (which are still supported for backward compatibility), except that it requires an attribute called part describing the name of the content part to be edited or displayed. For example, editing a story title with the content macro looks like this:

<% this.content part="title" as="editor" width="24" style="formTitle" %>

while displaying a custom property called "teaser" might look like this:

<% this.content part="teaser" %>

The content macro takes one extra attribute called fallback, which describes a content part which is to be used in case that the one specified by the part attribute is not set. Thus, the following code

<% this.content part="teaser" fallback="text" %>

would display the content part called "teaser" if it exists and the content part called "text" if not. If a part is not defined, nothing is displayed.

I must say that I'm myself astounded by the flexibilty, simplicity and usefulness of this concept. A lot of things suddenly become very easy. Most of these are beyond what we will likely ever want to do with Antville, but it's still worth to pick out a few: stories in multiple languages, partitioning a story into multiple parts or over multiple pages, versioning ... the list goes on.

Here's a quick look into how this is implemented. All in all, it was surprisingly simple because of Stefan's XML Extension. I'm using the native dumping/reading of Hopobjects, so all I have to do is create a transient Hopobject and add the content parts to it as properties. The Hopobject can be transformed into an XML string in one call of XML.writeToString(hopobject), and converted back from XML to Hopobject calling XML.readFromString(xmlstring). Basically, story content is managed via these three simple functions in story/objectFunctions.js:

/**
 *  Get a content part by name.
 */
function getContentPart (name) {
   var cnt = this.getContent();
   return cnt[name];
}

/**
 *  Return the content parsed into a HopObject.
 */
function getContent () {
  if (!this.content)
     return new HopObject ();
  return Xml.readFromString (this.content);
}

/**
 *  Set the content of this story object.
 */
function setContent (cnt) {
    this.content = Xml.writeToString (cnt);
    var raw = "";
    for (var i in cnt)
       raw += cnt[i]+" ";
    this.rawcontent = raw;
}

(The last section in setContent() is used for writing the raw content without XML markup into a separate column for searching. I'm still thinking about other ways to search over story content. Just as a note, it would technically be possible to search for content in specific content parts using something like "%<partname>%searchterm%</partname>%".)

The XML that's written to the DB looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- printed by helma object publisher     -->
<!-- created Wed Jun 12 18:52:09 CEST 2002 -->
<xmlroot xmlns:hop="http://www.helma.org/docs/gui
de/features/database">
  <hopobject id="t15" name="" prototype="hopobject" 
  created="1023900729721" 
  lastModified="1023900729722">
    <text>some text</text>
    <title>hello world!</title>
  </hopobject>
</xmlroot>

I hope this gave you a good impression of what this feature is about and how it works. I'm curious to hear what you think.

This is a proposal for restructuring the way Antville handles site navigation, i.e. displaying links within a weblog for various groups of users. Here is a list of proposed changes:

1. Leave the current weblog.navigation macro as is to avoid breaking current antville.org weblogs.
2. Directly embed navigation elements that are the same for all users into the main page skin.
3. Create a new macro called "weblog.adminlinks" that only display links for contributors and admins. Points 2. and 3. solve two problems:
   • it makes it possible to separate basic site navigation from navigation links displayed only for contributors and administrators
   • it makes basic site navigation easier to customize
4. Replace the "search" link with an embedded search field (already discussed and agreed upon here)
5. Replace the "topics" link with a macro that displays an inlined list of all topics (imagine, no more links to empty topics page, and new topics would automagically appear in sidebar!)
6. Move the "polls" link to the links only displayed for contributors and admins. The reason for this is that I consider polls to be building blocks similar to images and goodies which would be displayed to ordinary users only when linked or embedded from a story or comment or skin.

Thus, the site navigation code that would be directly embedded into the main page skin would look something like this (in pseudo-macro-code, so to say):

<% weblog.link to="main" text="home" %><br />
<% weblog.topiclist %><br />
<!-- insert more static links here if you want -->
<% weblog.adminlinks %><br />

<!-- um, maybe we should write a macro 
for the search box? -->
<form action="<%this.url%>search"><input name="q"
value="<% request.q encoding="form" %>"><input
type="submit" value="search"></form>