For me, it's mainly about maintainability
Consider the following
public class ViewPersonPage {
@Property
@Persist
private int dobDay, dobMonth, dobYear;
...
}
public class EditPersonPage {
@Property
@Persist
private int dobDay, dobMonth, dobYear;
...
}
public interface PersonService {
public void createPerson(int dobDay, int dobMonth, int dobYear);
public void updatePerson(int personId, int dobDay, int dobMonth, int
dobYear);
public ? getPerson(int personId); // what do we return here?
public List<?> getAllPersons(); // what is each element in the list?
}
Now consider that you want to add an address to the person... can you see
the maintenance nightmare?
If you encapsulate the fields in a person object, you add the address field
to the person object without needing to change the PersonService interface.
ViewPersonPage and EditPersonPage might not need to change either if it
only requires a change to the .tml
On Tuesday, 17 January 2012, Chris Mylonas <ch...@opencsta.org> wrote:
> hi captain, read my response with a touch of diplomacy.
>
>> I may have missed something here but when dealing with simple pages is it
>> best to simple include the fields in your page objects or group them in
>> 'model' classes (like Person below)?
>
> "best" :)
> if you're going to cut code and you work faster with primitives - cool.
But it's bad practise.
> Not to bag php programmers or js programmers, but you end up with
spaghetti code a lot easier because of those habits.
>
>
>> Is there good technical reasons to do
>> it one way or does it come down to personal preference? Thx in advance.
>
>
> it's good object oriented-ness to use objects rather than primitives like
int.
>
> back when i studied there was a question in an exam like "what are the 4
principles of object oriented programming"
>
> 1. inheritence
> 2. encapsulation
> 3. polymorphism
> 4. .... i can't remember.
>
>
> I'm sure tapestry could be written with a lot less use of objects and
more strings and arrays of strings, and arrays of arrays, but it would not
be the project it is without the use of objects.
>
> You become a better programmer by following good principles.
> Always use objects - you can draw the relationship between your objects..
not so much a handful of ints, chars and booleans thrown together in a
class.
>
>
> And without diplomacy, use objects and not primitives.
>
>
>>
>>
>> //java
>> public class PersonalDetails
>>
>> ///groupd fields
>> @Property
>> @Persist
>> private Person person;
>>
>> OR
>> //single fields
>> @Validate("required")
>> @Property
>> @Persist
>> private int dobDay,dobMonth,dobYear;
>>
>> }
>>
>>
>> public class Person implements Serializable {
>>
>> private int dobMonth;
>>
>> private int dobYear;
>>
>> private int dobDay;
>>
>> }
>>
>>
>> //TML
>> <select t:type="select" t:id="dobDay" t:value="person.dobDay"
>> t:model="days"></select>
>> or
>> <input t:type="textfield" t:id="dobDay"/>
>>
>>
>> --
>> View this message in context:
http://tapestry.1045711.n5.nabble.com/Creating-Model-objects-tp5151141p5151141.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
