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).