no, i haven't benchmarked the new code, yet (what's a good way to do this effectively, btw.?)

however, i think it's fine to have a possibility of directly rendering strings to the output buffer as well as using the strings as is in other functions...

if we would replace the renderFunctions with new code, where would the res.write stuff move to? macro functions only? or could we completely drop them? what became of automatic processing the prefix and suffix parameters in macro functions that return null (bug 73)?

what i meant is that i'm not sure if it's so much cleaner/better to call a function e.g. renderColor() (which then does res.write(renderColorAsString()) instead of directly doing res.write(renderColor()) somewhere in a macro-function. but what might be a good idea is to set up naming-convention where functions that return a string are called renderSomethingAsString and those that write directly to response just renderSomething.

reg. benchmarking: this was just a sidestep in my mind (so don't take that too seriously), and i'm not sure if this really has a negative effect on performance. tools? i use apache benchmark or, for a more realistic result, http_load.

i see. i mainly did this as a first step to provide backwards-compatibility. because from the macro point of view it makes a huge difference if a function is called simply by renderSomething() or res.write(renderSomething()) and the function returns a value or itself writes to the output buffer.

for now every render function call gets the right handling as before, except where i modified the calling functions itself.

in the bigger picture and as next step, we certainly should modify the macros itself to call the right render function type.

anyway, this is still depending on if bug 73 will be resolved...

and thanks for the benchmarking tool tips, robert. :)

do you think this will be a big problem or cause a lot of confusion / misunderstanding?

<% image name="picture" as="thumbnail" %> will produce this output:

while <% image name="picture" as="popup" %> will produce what formerly was done by the thumbnail macro:

the difference is what happens when you click on the thumbnail...

btw. who the fsck has posted all these fscking pictures to the pool? it takes a nation of millions to hold me back from deleting them!

i think the problem is: now we have a lot of stories (i guess) that have a thumbnail_macro embedded: if we throw out the macro, those thumbnails won't appear anymore. if the thumbnail-macro becomes a wrapper-macro (for image_macro), those images will be displayed as normal-size-images (because the parameter as="thumbnail" is missing). and replacing all thumbnail-macros in those stories is quite a lot of (coding-)work ...

we don't have to throw out thumbnail_macro. but we can modify it to call image_macro with param.as set to "thumbnail", can't we?

function thumbnail_macro(param) {
var p = cloneObject(param); // param is read-only
p.as = "thumbnail";
return(this.image_macro(p));
}

i forgot that you're heavy in cloning business ;-) sure, doing that makes perfect sense, and solves any backwards-compatibility-issues.

but probably also a question of taste or what one considers as natural.

well, one objection i have: a function streaming the output is not re-usable if i would like to post-process its result in another function. at least that's why i have started in this direction: i stumbled too many times across direct output but wanted to have post-processing.

another reason that i ended here is probably because i started with a skin (which is not used anymore, and therefor the streamed approach is possible again). i don't know if it is helma who encourages this or that approach or the peops behind it... (might make no difference, anyway). however, helma supports both ways pushing something ready-made into or getting something serially from within a skin. i'd prefer freedom of choice, as usual.

i happily will make another trial to follow your suggestion, just to see what it's like.

but still remains the question if prefix and suffix will be automatically rendered in such streaming output... (you once said it was possible)?

the skin based approach does have its place, but higher up where flexibility is the main concern.

Here, for low level infrastructure stuff, I'd say the other approach is the better fit for the benefit of an easier to follow render-flow.

Regarding native prefix and suffix support in Macros: yes, I'll implement it right now.

sounds all very good and reasonable! I think renderMarkupElement() would better be called emptyMarkupElement() if it only does empty elements, but that's really a minor point.

+1 on renaming/reworking doWikiStuff, it's really a quick hack as far as I remember.

i just gave your branch a look, and everything looks really good. kudos! there's just one minor thing: it seems that you forgot to clone the param-object in hopobject/createLinkParam(), so weblogs on root-frontpage don't appear as link (which is - me parece - because you're deleting properties).

and: shouldn't we throw away the openLink() and closeLink()-macros (i assume there are also some other old functions left that could be replaced by your general markup-functions)?

ad emptyMarkupElement: i thought about this for a while and considered "emptyMarkupElement" would sound like "emptyTrash" or "make an markup element empty"... that's why i was looking for an alternative. don't take the naming as granted, though.

ad root frontpage: this should be fixed again, right? you probably took a look at the code when it was under heavy processing... :)

ad openLink et al.: i don't want to throw it away right now, because whole antville already was shaking a little bit when i tried to fiddle around with too many parts at once. but generally i support the idea of simplifying the code wherever possible.

btw. i compiled a new snapshot with hannes' recent changes (suffix, prefix support in response buffer) and checked out the current version of the devjamtobi branch to hopdev. please feel free to take a look!

and the frontpage already is valid xhtml!