You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by captain_rhino <gr...@axa-travel-insurance.com> on 2012/01/17 10:59:08 UTC
Creating Model objects
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)? Is there good technical reasons to do
it one way or does it come down to personal preference? Thx in advance.
//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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Creating Model objects
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
I'd like to add that Object-Oriented Programming is about objects, of
course. :) It's about creating data structures to organize and model the
data you have, plus the methods that work on them. Anyway, creating a
class is such a quick thing that I can't see any reason to use lots of
primitive variables.
On Tue, 17 Jan 2012 09:25:42 -0200, Lance Java <la...@googlemail.com>
wrote:
> 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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Creating Model objects
Posted by Lance Java <la...@googlemail.com>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Creating Model objects
Posted by Chris Mylonas <ch...@opencsta.org>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org