WebViewJoinGame should let player add money to table if betting is enabled

[GoogleCodeExporter]

Using the changes that were added in r129 and r130 this issue can be 
completed.  The webview is responsible for determining if betting is enabled 
for the game and modifying the interface appropriately.  Additionally, if 
joining the game fails the webview is responsible for making sure the money 
is added back to the user's account.

Original issue reported on code.google.com by jjhatf02 on 23 Mar 2010 at 2:43

[GoogleCodeExporter]

Note: In the form validation, the WebView should not allow users to make an 
initial 
bet that exceeds their current account balance.

Original comment by krussell...@gmail.com on 25 Mar 2010 at 4:25

[GoogleCodeExporter]

Are we differentiating between betting-enabled games and games that require an 
initial bet?  Can initial bets be made in all games that are betting-enabled?

Original comment by krussell...@gmail.com on 25 Mar 2010 at 4:26

[GoogleCodeExporter]

I don't think we need to do that.  If someone is at a table that requires an 
initial 
bet and they are unable to make the bet then they simply do not participate in 
the 
game.  Having betting enabled simply requires someone to put some money onto 
the table 
because there may be an initial bet and we don't want people joining just to 
take up 
space.

So to answer your question, CardWeb does not care.

Original comment by jjhatf02 on 25 Mar 2010 at 5:08

[GoogleCodeExporter]

I think my terminology is wrong.  A better term for this would be "Intial 
Stake" 
(assuming our engine only supports open stake playing rules).

http://en.wikipedia.org/wiki/Ante_(poker)#Open_stakes

The initial stake would just allow for that player's initialization of their 
magic 
tabl bank.  Initial bet implies that game play has already started.  Betting 
should 
only be managed by the table.  If someone can't make an "initial bet", the 
table 
should be responsible for kicking them out.  Thoughts?

Original comment by krussell...@gmail.com on 25 Mar 2010 at 5:27

[GoogleCodeExporter]

I'm still thinking this is all theoretical because CardWeb has no knowledge of 
Blackjack.  We should not code Game to fit the needs of Blackjack.  We might 
want to 
sit down and rethink the structure of the information that can be stored by a 
Game 
that describes the betting in a generalized way.

I still feel that the biggest problem is that the WebView does not know about 
those 
rules until the Seat password is verified.  The easiest solution for this would 
be to 
add an additional phase to sitting at the seat.  The first verifies the 
password and 
the second handles all of the monetary concerns and actually sits the person 
down in 
their seat.

Original comment by jjhatf02 on 25 Mar 2010 at 5:33

[GoogleCodeExporter]

Began work in r149.  See revision comments for incompletes preventing this 
issue 
from being closed.  Basic functionality has been provided by r149.

Original comment by krussell...@gmail.com on 26 Mar 2010 at 1:20

• Changed state: Started

[GoogleCodeExporter]

What you have so far looks good to me.  You might want to add a "nevermind" 
button on 
the page where you enter in the amount to transfer to the table so the user can 
go back 
without joining the game.

Original comment by jjhatf02 on 26 Mar 2010 at 2:55

[GoogleCodeExporter]

Original comment by krussell...@gmail.com on 1 Apr 2010 at 8:57

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Can this issue be closed now?

Original comment by jjhatf02 on 12 Apr 2010 at 2:53

[GoogleCodeExporter]

No, I'm not yet verifying that the user actually has the money in their account.

Original comment by krussell...@gmail.com on 12 Apr 2010 at 1:58

[GoogleCodeExporter]

Oh, that small detail, why would we ever want to do that. ;)

Original comment by jjhatf02 on 12 Apr 2010 at 2:22

[GoogleCodeExporter]

You're right.  In the grand scheme of things, it is but a trifle; an 
insignificance 
that hardly merits a persistently open issue.  What's one conditional line out 
of 
11,000 others?  Nevertheless, we should probably wait for Issue 66 to be 
resolved 
before completing this one.

Original comment by krussell...@gmail.com on 12 Apr 2010 at 2:30

[GoogleCodeExporter]

This issue was closed by revision r378.

Original comment by krussell...@gmail.com on 22 Apr 2010 at 9:32

• Changed state: Fixed