[Seaside] [ANN] A/B Testing

[Julian Fitzell]

Hi Paul,

Interesting idea. I haven't looked at the code yet, but here are some
answers to your questions...

On Wed, Mar 31, 2010 at 11:19 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:
> renderContentOn: html
> "This example alternates between two logos, and records when a user
> clicks the button to indicate that they like something.  The logo shown
> follows the user if the user is created prior to the #renderContentOn:
> method. In this example the user is created in the render method, so you
> get a new logo when the refresh is called. Creating the user in the
> initialize method makes the logo follow the session. Creating the user
> when they signup makes the variation follow them throughout their
> experience until a winner is declared. "
>
>        user:=ABUser new.
>        html html: (ABTest showVariation: 'sample'
>                           a:(WARenderCanvas builder render:[:h | h
>                           image
>                           url:'http://www.seaside.st/styles/logo-plain.png' ]   )
>                           b: (WARenderCanvas builder render:[:h | h
>                           image
>                           url:'http://www.seaside.st/styles/esug.gif' ]   )
>                           user: user).
>        html break.
>
>        html form
>        with:[
>        html submitButton
>                callback:[ABTest recordConversion: 'sample' by: user.
>                        html javascript refresh];
>                with: 'I like this one'.
>        ]
>
>
>
> Some questions I have are:
>        1. Is this an appropriate place for WARenderCanvas builder
>        render: or should I use something else?

Well, I guess it should work, but why do you need a new Renderer? Why not just:

       user:=ABUser new.
       html html: (ABTest showVariation: 'sample'
                          a: [ html image
url:'http://www.seaside.st/styles/logo-plain.png' ]
                          b: [ html image
url:'http://www.seaside.st/styles/esug.gif' ]
                          user: user).

>        2. Should I be using Announcements for this somehow?

I have no idea. :) The need doesn't jump out at me, but as I said, I
haven't studied the code yet.

>        3. Is there a need to put some kind of lock on the class ivars
>        in the recordConversion:by: method or the
>        showVariation:a:b:user: method?  I can imagine the ivars getting
>        hit at the same time eventually, but don't know if Smalltalk
>        just handles that sort of thing.

Seaside ensures that only one request is operating within a Session at
a time. Beyond that, there is no locking done for you. So if you have
state that is being accessed by multiple sessions simultaneously, you
should make sure it is safe to do so.

I hope Seaside users will find this useful.

Julian