Looking at the relevant code for the first time. For both #1 and #2, I
don't know if there would be use cases where authors would want to make
these settings at the blog or the entry level, but I don't need that.
Based on my current limited familiarity with the Roller code, I think it
would add weeks of dev and testing to add the management side work
needed for non-global configuration. I'll assume that global settings,
probably via roller.properties/custom will be adequate.
I'm thinking for #1 [Allow comments only by logged in users]
Implement a CommentAuthenticator which will check for a non-null and
non-Anonymous Acegi principal and display message as explained in my
original email below.
Need to find where the Preview and Post button HTML is generated.
Depending on how dynamic that code is now, according to same criteria as
above (if sequence works out right, could have the procedure above set a
flag in the appropriate context), either disable the buttons, or replace
them with Login and/or Register buttons. No idea how to switch this in
an extensible way until I have time to look at the existing code.
* Can somebody help me find where the HTML for the Preview and Post
buttons is generated?
For #2 [If user is logged in, submitter details are obtained by Server
instead of bothering commenter]
The user name and addr settings can be set very easily in
WeblogCommentRequest. I suspect you already have a Roller object in
scope with this info. If not, the Acegi User object will have it.
Once again, I'm not having much luck finding where the form HTML is
generated.
* Can somebody help me find where the HTML for the Name and email
addr fields are written into the comment form?
On the other Blog servers which I've used, the URL field is intended
to be set to the commenter's home page. It doesn't make sense to me to
use it as a reference for details related to the current entry, since
such a reference would generally be more useful in context in the main
comment text. If the comment URL is intended to be a "personal" URL,
then I think this should be a user profile setting, stored in the
rolleruser table, and auto-populated into comments the same as commenter
name and addr.
POSSIBLE IMPL. OPTION
If it's troublesome to selectively display form fields, we could pass
the name/addr[/url] values to the form for pre-population, make the
fields read-only, and ignore them on submit. Similarly, always write
the Preview and Post buttons, but disable them. I prefer a more
minimalist interface that doesn't show fields and buttons which the user
can't use.
UNRELATED SUGGESTION
How about adding some JavaScript to the existing
MathCommentAuthenticator to disable the Preview and Post buttons until
the user enters the correct math answer? Spare useless xmits for both
user and server. (If the client side is not going to use the
pre-calculated answer, then I don't know why this pre-calculated answer
is passed back and forth in the form).
Elias Torres wrote:
> I'm interested in this. We've been bouncing some ideas on how to do this
> with the proper user experience. Please share your thoughts, we can
> probably work on this together.
>
> -Elias
>
> Blaine Simpson wrote:
>
>> I'm going to add two new, independent capabilities to the Comment
>> classes. Both optional and settable by roller.properties (unless
>> somebody has a better idea on how to toggle the features).
>>
>> 1) Allow comments only by logged in users (for non-logged-in users,
>> comment form will be replaced by a suggestion to log in or register so
>> that a comment can be submitted).
>>
>> 2) If user is logged in, the submitter's name and email address will be
>> taken from their Roller account record. If user is logged in, then the
>> comment form will not have fields for submitter name and email addr.
>>
>> The reason that I'm posting to this thread is to get recommendations as
>> to whether I should wait to fit this in with the suggested
>> Authenticator/Validator strategy. If so, could somebody give me a
>> realistic expectation of when I can expect that code to be usable in the
>> trunk?
>>
>>
