well, almost. the <% this.commentform %> works only on the url that ends with "comment", not on "main". that is, you can display it on but you cannot submit a comment.

plan b was to rewrite the "comment" page. this doesn't work either, because if you are not logged in, you cannot access it, because it redirects you to the login screen.

yep, i found this bug as well. but as said before, this form is not working. not even for logged in users.

doesn't check if the user is logged in because a not-logged-in user wouldn't get to the comment-page, but be redirected to the login-page. so i don't consider this a bug.

funny thing, kris, what you're trying to do is nearly exactly what antville worked until one week ago (just with threaded comments), which then lead to much confusion ;-) see [Macro not allowed in sandbox: comment.link] , so i moved the comment-form to a separate page.

actually, to make the "edit"-skin of comment work also with urls that end in "main", you just have to modify it by adding action="comment" to the <form ...>-tag (since you wanted to disable the reply-functionality, it would work this way). but then there is no checking done if the user is logged in ...

Yes, but what's the point in being flexible with skins and macros if we don't allow as much flexibility as having a flat comment structure and directly showing the comment form - a combination that works very well? So I definitely think it should be fixed. Which way did it work until one week ago? Did you use a different macro to display commentform-or-loginlink, or did you change the functionality of the macro?

I just checked in the CVS, the commentform macro did in fact include a check if the user was not logged in or blocked, and display a login link instead of the form in case. It would be quite easy to reactvivate that. (Generally speaking, I think it's good that every macro makes this kind of checks, even if they may be redundant in some cases, because it's in the nature of the application that we can't control in which context a macro is called.)

Then, we'd only have to make sure that the comment form would contain the correct form action (story/comment.hac in this case), which is a bit tricky because it's also used to edit existing comments, but I think we can come up with a nice way to include an optional form action.

Robert, if you give me green light I'll do that.

yes, it's the same macro, but i removed all checking from it because i thought it would not be needed anymore ( [Macro not allowed in sandbox: comment.link] ).

in this case it would mean to (re-)add some code not only to the commentform-macro (for the checking above), but also to main.hac of story (so that one has not to change the edit-skin of comment too as i described above). easy done.

but basically i'm just wondering to what extend antville should allow/support structural changes. so to say: if one can build a weblog with a flat discussion, shouldn't we also enable fully threaded discussions too? and what does that mean for code-structure? things to think of ...

hns, i would be glad if you would do it, so of course you're getting a big green light ;-) regarding the optional form-action: i don't know if we really need it, why not just add the necessary code to story/main.hac? (just a quick thought, didn't go through the code).

i already made several bug-fixes (mostly to solve the bugs kris reported), and now i'm restructuring antville to use prototyped groupnodes ...

I also just realized that it would be easier to reactivate addComment in story/main.hac than messing with the comment form.

I think flexibility is what within our skin/macro approach makes the difference between an extremely powerful framework or "just a theoretical concept". Having a macro called "commentform" within the story prototype should mean for the user that this macro can be used everywhere within a story object.

Regarding nested discussions: We need users who try it, then it either works, or it doesn't. If it doesn't, we need to check it in the corresponding macros to avoid bad things from happening, or we go the extra mile and make it work.

i just played around with the skins in my local installation, and one can actually create a fully threaded discussion just with editing some skins. (didn't know that this would work so easy). but this really needs an unspecified form-action in the edit-skin of comment.

What about taking the form tag out of comment/edit.skin and generate that by the corresponding macro or action? For instance:

res.write ("<form ..." ... this.href(...)...) cmt.renderSkin ("edit"); res.write ("</form>");

also possible. i did it the other way because a) i wanted keep the code as much html-free than possible, and b) enable changing the position of the tag (because form-tags tend to create stupid line-breaks which can be annoying)

i think the confusion arises because the "place a comment" link is immediately after the story or the comment. just look at this thread. if you read all the comments and if you want to respond you have to scroll up. an "add your comment" link after the list of comments would be better. no matter if the discussion is threaded or not.

a response form (and a login link or even the form for the non-members) right after the last comment is even more in-your-face. that's why i want it :)

from my point of view it would be great to have a response link as well as a response form (with a configurable alternative for non-members) that works everywhere. with these elements and the skins for reply and top-level reply you can create flat and threaded discussions with one or infinetely many levels.