On Wed, 02 May 2012 21:28:05 -0300, netdawg <net.d...@yahoo.com> wrote:
OK. Lets leave it at that, I guess. Agree to disagree ;-).
1. Polymorphism is not about implementation at all. It is about
interfaces, which is what Components can aspire to be, sort of. In that
case, components, do not get tied to page properties - they use only
those available - and if not, they behave as if those properties do not
exist.
That is Polymorphism, for me. So a shape would draw only if there was
concrete draw provided, other it would ignore the draw request.
No, this is not the definition of polymorphism in software development.
Quite far from it, actually. You can have polymorphism without interfaces
in Java:
int i = 2;
long x = i;
i is not a long, yet its value still can be assigned to a long. That's a
type of polymorphism called coercion.
Polymorphism is the ability of something to appear in different forms in
different contexts. Example: passing a String to a method that receives an
Object. In this case, String appears as if it was an Object to this
method. This is called inclusion polymorphism.
In addition, the dynamic typed languages are all about polymorphism.
2. This discussion is about expanding horizons of Tapestry...
I don't see it that way. You're asking for Tapestry to have a feature that
goes against its principles. To make things worse, there are way to do
what you want already implemented in the framework.
I didn't want to pull an argument by authority, but I know what I'm
talking about (at least in this case). When doing my master's degree, I
was a TA in Object-Oriented Programming. Later I was the coordinator and
professor of a graduate course on Java. I have more than 4360 posts in the
Tapestry mailing lists. For helping people, I've been voted as a Tapestry
committer and then a member of the Project Management Committee.
not saying
this a "Very Bad Thing etc" or giving up because it is difficult.
I'm not saying this is difficult. I'm saying it's the wrong thing to do.
It goes against the principles of Tapestry, good practices and good
architecture.
3. I see pageName is just another page property...nothing more, nothing
less (or should be, if not). Therefore, all other page properties
should be visible as well. Of course, I have not looked at the code...
No, the page name is not just another page property. That method in
ComponentResources returns the logical name of the page, which is part of
the not a property of your page class. You insist in saying this.
That said, THANKS, I like the idea of
ComponentResources.getPage()...*may*
indeed be the answer I was look for...but I am already on a roll, so
perhaps will look into later and report back
You're welcome!
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
