Proposal_CommentValidators

Please see inlines, especially the one at the bottom.  I'm
hopeful that
somebody will take the time to point me in the right
direction... at
least to some architecture docs, because I'm wasting more
hours than it
is worth to me to figure out the data access issues on my
own.

>  On 12/11/06, Blaine Simpson <blaine.simpsonadmc.com> wrote:
>  ...
> 
>  > 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.
> 
>  A comment authenticator can provide HTML form fields
to be included in
>  the comment form, but cannot change the buttons.

Changing the authenticator text was easy.

>  >     * Can somebody help me find where the HTML
for the Preview and Post
>  > buttons is generated?
> 
>  The comment form is generated by the
#showWeblogEntryCommentForm()
>  macro in WEB-INF/velocity/weblog.vm.

I need help changing the comment form text.
I can't find an elegant way to access the current UserData
object from
within the velocity templates.
I looked into accessing the Request (to get the UserData
from the static
RollerSession method), and writing the needed data to the
form or comment
POJOs which are accessible to Velocity, but can't find the
right place to
do any of these things.
I've run into similar problems before, where Struts apps
designed to isolate
the View require you to violate MVC (with much difficulty
and highly-coupled
code) to do dynamic stuff like this lower down.
(Cross-cutting stuff like this is done much more elegantly
with SpringMVC).
Any pointers would be appreciated.

>  > 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.
> 
>  Yes. Inside your CommentAuthenticator you should be
able to obtain the
>  request and session information you need to determine
is a user is
>  logged in with the right role to leave a comment.
Unfortunately,
>  that's not documented (yet).

Done.  Easy with the RollerSession.

>  >     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?
> 
>  Again, the comment form is generated by the
>  #showWeblogEntryCommentForm() macro in
WEB-INF/velocity/weblog.vm.

My problem is, once again, getting the UserData object from
here. See above.

>  >     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.
> 
> 
>  Yes. That's true. Unfortunately the
CommentAuthenticator interface
>  does not allow you to pre-populate the comment. Maybe
we should change
>  that.

I have submittal side working just fine.  When a comment is
submitted, it
will be accepted only if user is logged in (based on a
Roller property),
and values for User Name and Email Address are used from
UserData (based
on another Roller Property).

My difficulty is with changing the comment form text.
It is really bad UI to display a usable comment form
followed
by a message that the user has to log in before they can use
the form.
I'm even unable to disable the form fields with Javascript
in the
Authenticator due to hierarchical issues.
If user is logged in (and relevant property is set), I want
to either
pre-fill and disable the User Name, Email Address, and
Save... fields,
or eliminate them.

On 12/28/06, Blaine Simpson <blaine.simpsonadmc.com> wrote:
> Please see inlines, especially the one at the bottom. 
I'm hopeful that
> somebody will take the time to point me in the right
direction... at
> least to some architecture docs, because I'm wasting
more hours than it
> is worth to me to figure out the data access issues on
my own.

I'll give it a shot...


> >  >     * Can somebody help me find where the
HTML for the Preview and Post
> >  > buttons is generated?
> >
> >  The comment form is generated by the
#showWeblogEntryCommentForm()
> >  macro in WEB-INF/velocity/weblog.vm.
>
> I need help changing the comment form text.
> I can't find an elegant way to access the current
UserData object from
> within the velocity templates.
> I looked into accessing the Request (to get the
UserData from the static
> RollerSession method), and writing the needed data to
the form or comment
> POJOs which are accessible to Velocity, but can't find
the right place to
> do any of these things.
> I've run into similar problems before, where Struts
apps designed to isolate
> the View require you to violate MVC (with much
difficulty and highly-coupled
> code) to do dynamic stuff like this lower down.
> (Cross-cutting stuff like this is done much more
elegantly with SpringMVC).
> Any pointers would be appreciated.

We have these methods in the UtilitiesModel class:
   public boolean
isUserAuthorizedToAuthor(WebsiteDataWrapper weblog)
   public boolean isUserAuthorizedToAdmin(WebsiteDataWrapper
weblog)
   public boolean isUserAuthenticated()

But you are correct, we don't yet provide a way to get the
UserData of
the currently authenticated user. I would not be opposed to
adding
another method:

   public UserDataWrapper getAuthenticatedUser()

If you're going to use those methods, then make sure you do
*not*
override the cache.excludeOwnerEditPages=false property.


> >  Yes. That's true. Unfortunately the
CommentAuthenticator interface
> >  does not allow you to pre-populate the comment.
Maybe we should change
> >  that.
>
> I have submittal side working just fine.  When a
comment is submitted, it
> will be accepted only if user is logged in (based on a
Roller property),
> and values for User Name and Email Address are used
from UserData (based
> on another Roller Property).
>
> My difficulty is with changing the comment form text.
> It is really bad UI to display a usable comment form
followed
> by a message that the user has to log in before they
can use the form.

That's pretty subjective. Some authenticators might work
best above
and some below. It would be nice if we could support both.


> I'm even unable to disable the form fields with
Javascript in the
> Authenticator due to hierarchical issues.
> If user is logged in (and relevant property is set), I
want to either
> pre-fill and disable the User Name, Email Address, and
Save... fields,
> or eliminate them.

You should be able to override the #showCommentForm() by
providing
your own implementation. Create a file roller-custom.vm in
the
WEB-INF/velocity directory with that and any other macro
overrides you
might have.

Hope that helps...

I think the CommentAuthenticator interface needs some
redesign if it's
going to properly support the different comment SSO schemes
that folks
are discussing. I'll be working on CommentValidators this
week -- not
sure if I'll have much time to spent on authenticators.

- Dave