i think we really could need some guidelines or at least a basic principle of how macros are designed. i think it makes the the macro coders' lifes easier.

e.g. i consider the topic_macro badly designed (or badly named in this case), because it returns the name of the topic as link. i would expect this functionality to be in topiclink_macro. and topic_macro should return the plain topic's name only.

another example are macros which render html tags. imho it is very important to give access to (almost) all of the html attribiutes via the macro. if that's too much hassle, please take in account at least "style", "class" and "id" to let the people control the element via cascading style sheets.

again, i think this will release a lot of pressure from the antville developers because users get the power to play their individual games without permanently crying for changes in antville source code.

if you want me to, i happily will browse through the macro code and try to develop some consistent practice how they generally should be implemented. whatcha say?

i definetly appreciate your will to "standardize" macros :-) regarding your example with the topic_macro(), i'd vote for not creating two macros but instead using parameters (like as="link" or linkto="main" ...) to define if the name of the topic should appear as link or not (ev. we should rewrite the whole functions involved in creating a link).

i am particularly sensitive when it comes to these issues. that's why i asked you about it. antville is a sexy web application and not a siemens telephone, innit?

although i certainly did not finished browsing through the quite impressive collection of antville macros, i would like to already make a first proposal (because it could affect my further proceeding):

could we extend the macro support built-in into hop insuchaway that the prefix and suffix parameters are evaluated by hop and not by custom macro code anymore?

these two params are a really glorious idea and they once more underline how beautiful helma can separate content from code. they always work like this: when the value of the macro is null they are omitted. otherwise the value of prefix is inserted at the beginning and suffix is added to the end of the value (ie. a string).

however, there is one twist that could rain on my parade. hop should be able to apply this new behaviour to macro structures like this:

<% this.title prefix="<p>" suffix="<br>" %>

function title_macro(param) { res.write("here comes some stuff "); res.write(this.title); res.write(" and here comes some stuff, too"); }

question is if hop can be aware of that prefix hast to be inserted before "here" and suffix has to be added after "too"? ie. the correct output should be:

<p>here comes some stuff TITLE and here comes some stuff, too<br>

(i know that the macro code could be rewritten but regarding antville that possibly could mean more work than the feature could provide as benefit.)