On 12/16/05, Paul Benedict <[EMAIL PROTECTED]> wrote:
>
> Rick,
>
> Do you control the requirements? It's going to be an ugly screen with that
> :)


Agreed. For that example it was more so to exaggerate a problem that does
come up when dealing with more specific situations.

 In regard to the solution it seems like you were suggesting, it would
involve not only creating duplicate beans (not even ActionForms) simply to
meet the String only requirement. Populating these lists of lists of back
and forth doing domain POJO to yourStringsPOJOs would be very cumbersome
even if using BeanUtils.

While driving into work, I was thinking of how badly I got beat in my
fantasy football game this past weekend which got me thinking of another
typical example of having to use nested beans.

If you've played fantasy football before, or if you could just consider
being the manager of any sport's team, you might have to submit a weekly
lineup which involves looking at all your players and marking them 'active'
or 'bench' (real life more status' of course).

So let's imagine you were first tasked at the beginning of the season to
help out an NFL team. They needed a way to enter in their player data.
Backend returns a "Player":

Player object:
   String name
   Integer playingStatus;  //0 - bench  1 - active. DB holds Integer

(Again in real life I'd actually probably have a nested Status object here
which would give me more info on the status, such as Integer statusCode,
String statusName)

Now we need our ActionForm to enter this data:

PlayerActionForm
    String name;
    *String* playingStatus

Things are fine so far. Happy developers working for the NFL team.

Next we realize that we need to create a "Weekly Team Roster" screen where
the Manager can go and set his players as 'active' or 'inactive.' He likes
to do this by just entering in a 0 or 1, doesn't want to use a drop down
list.

So we want to see...

My Team

name                     status
----                     -------
John Doe                   1
Fred Guy                   0
//etc

Also imagine of course much more data, position, player address etc.  So the
question in scenario two becomes "What are you going to return from your
backend to display on the screen?" Normally I'd like to return a "Team"
object which would have a List of Players nested in it, but lets just make
it more simple and return a List of Employees that we need to update from
our ActionForm. Why would you not get back a List of "Player" objects? It
makes perfect sense - except we have one slight problem - we have that
Integer value for status.

It sounds like to me you are suggesting that we'd create a "brand new"
Player object that had some String properties in it. To me, this goes
against, the whole concept of object oriented programming and code reuse.
You are creating an identical object to the exisiting POJO where the only
difference is changing a few of the property types (ie number or date to
String).

Reply via email to