You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jonathan O'Connor <Jo...@xcom.de> on 2005/02/11 11:39:23 UTC
Best Practices: was "XDoclet " [auf Viren geprueft]
Erik,
You wrote:
In fact, I've been
using get/setProperty() exclusively lately and not doing the 'abstract'
thing.
But, you still have to supply the name of the property as a param for
get/setProperty, and I, for one, think it is easier to have IDE support
and strong typing.
What happens when you mistype the property name? How quickly does the
error show up? I suppose you get more NPEs at runtime.
Can you give a list of advantages/disadvantages of your technique?
Ciao,
Jonathan O'Connor
XCOM Dublin
*** Aktuelle Veranstaltungen der XCOM AG ***
XCOM laedt ein zur IBM Workplace Roadshow in Frankfurt (16.02.2005), Duesseldorf (23.02.2005) und Berlin (02.03.2005)
Anmeldung und Information unter http://lotus.xcom.de/events
Workshop-Reihe "Mobilisierung von Lotus Notes Applikationen" in Frankfurt (17.02.2005), Duesseldorf (24.02.2005) und Berlin (05.03.2005)
Anmeldung und Information unter http://lotus.xcom.de/events
*** XCOM AG Legal Disclaimer ***
Diese E-Mail einschliesslich ihrer Anhaenge ist vertraulich und ist allein fur den Gebrauch durch den vorgesehenen Empfaenger bestimmt. Dritten ist das Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten, eine fehlgeleitete E-Mail unverzueglich vollstaendig zu loeschen und uns eine Nachricht zukommen zu lassen.
This email may contain material that is confidential and for the sole use of the intended recipient. Any review, distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
property keyword
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
I think that C# implementation of the feature is plain
UGLY! I was really amazed why the same guy who did
ObjectPascal(Delphi) allowed such ugly syntax.
--- Kevin Menard <ni...@negativetwenty.net> wrote:
>
> On Feb 11, 2005, at 10:20 AM, Jamie Orchard-Hays
> wrote:
>
> > Yeah, Ruby has something like this as well. You
> declare a property
> > with whatever access you want to it--not this
> get/set crap. That would
> > have been a nice feature to put in Java 5. Ach.
>
> Getting even closer to Java, C# has this feature. I
> don't know if this
> has something to do with it. Right now, most people
> think C# is a Java
> clone, not vice versa.
>
> --
> Kevin
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
=====
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Kevin Menard <ni...@negativetwenty.net>.
On Feb 11, 2005, at 10:20 AM, Jamie Orchard-Hays wrote:
> Yeah, Ruby has something like this as well. You declare a property
> with whatever access you want to it--not this get/set crap. That would
> have been a nice feature to put in Java 5. Ach.
Getting even closer to Java, C# has this feature. I don't know if this
has something to do with it. Right now, most people think C# is a Java
clone, not vice versa.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Yeah, Ruby has something like this as well. You declare a property with
whatever access you want to it--not this get/set crap. That would have been
a nice feature to put in Java 5. Ach.
----- Original Message -----
From: "Konstantin Iignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, February 11, 2005 9:53 AM
Subject: Re: Best Practices: was "XDoclet " [auf Viren geprueft]
> Just a rant:
>
> Why the hell Java does not have "property" keyword with ObjectPaskal
> syntax?!?!
>
> property myField; [read readMyPropertyMethod;] [write mySetterMethod;]
>
> That would solve this abstraction problem and resolve all that get/set
> mess and ambiguity....
>
> Maybe we should lobby Sun somehow?
>
>
>
> PLEASE keep page fields strongly typed,
>
>
> Howard Lewis Ship wrote:
>
>>So, if we move properties (including parameters) into the component,
>>we can get rid of a lot of enhancement. But we have to use untyped
>>collections (Maps), and we seperate the logic (in listener methods)
>>from the data (in the component). And we still haven't figured out
>>how the peer learns of the component (which would be injection).
>>
>>For my mind, if even one property has to be abstract, then there's no
>>additional dissadvantage to them all being abstract, and keeping
>>more-or-less the status quo (with respect to abstract classes .... but
>>I'm very committed to removing the necessity of extending Tapestry
>>classes).
>>
>>Please take these thoughts for what they are ... off the top of my head.
>>
>>
>
> --
> Thanks,
>
> Konstantin Ignatyev
>
> http://www.kgionline.com
>
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil,
> add 2.700 tons of CFCs to the stratosphere, and increase their population
> by 263.000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools. New York:
> State University of New York Press, 1997: (4) (5) (p.206)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Just a rant:
Why the hell Java does not have "property" keyword with ObjectPaskal
syntax?!?!
property myField; [read readMyPropertyMethod;] [write mySetterMethod;]
That would solve this abstraction problem and resolve all that get/set
mess and ambiguity....
Maybe we should lobby Sun somehow?
PLEASE keep page fields strongly typed,
Howard Lewis Ship wrote:
>So, if we move properties (including parameters) into the component,
>we can get rid of a lot of enhancement. But we have to use untyped
>collections (Maps), and we seperate the logic (in listener methods)
>from the data (in the component). And we still haven't figured out
>how the peer learns of the component (which would be injection).
>
>For my mind, if even one property has to be abstract, then there's no
>additional dissadvantage to them all being abstract, and keeping
>more-or-less the status quo (with respect to abstract classes .... but
>I'm very committed to removing the necessity of extending Tapestry
>classes).
>
>Please take these thoughts for what they are ... off the top of my head.
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been giving serious thought to how to get rid of the
"abstractness" of Tapestry, but the ideas really are not backwards
compatible to 3.x. It will be part of Tapestry 4.0, it it ever
happens.
First off, we'd need a 1-1 relationship between components (including
pages) and Java classes. This is necessary, because the loading of
each component will need to be intercepted at the class loader level,
and instance variables will need to be stripped out and replaced ...
the same kind of enhancements that occur today.
This does raise the issue that what you test is not quite what you run
... but that's true today, if you use the Creator on your abstract
classes.
This introduced some new problems ... such as the desire to have much
more dynamically generated pages and components. It's conceptually
possible to fabricate the specification in 3.x, but you'd have to
fabricate entire classes in 4.0.
.... or wecould go in an entirely different direction, where we
seperate back out the logic (in a POJO) from state. So instead of
seeing properties and parameters as JavaBeans properties, we see them
as untyped objects stored in a peer component.
Background: My vision for Tapestry 4.0 is that your pages and
components will be POJOs that will have. Most of the strunctural and
behavioral things we associate with components today would be the
responsibility of the component, whose implementaiton would be private
to Tapestry, exposed only through a (streamline) Component interface.
Your code would write the peer, which is the container for business
logic, listener methods, and so forth.
My current thinking is that the peer would be enhanced, to inject a
component property, plus anything else you direct to be injected (as
in 3.1 today). The peer would still be abstract, with abstract
accessors ... it just wouldn't need to extend from a Tapestry class,
or even implement a Tapestry interface.
So, if we move properties (including parameters) into the component,
we can get rid of a lot of enhancement. But we have to use untyped
collections (Maps), and we seperate the logic (in listener methods)
from the data (in the component). And we still haven't figured out
how the peer learns of the component (which would be injection).
For my mind, if even one property has to be abstract, then there's no
additional dissadvantage to them all being abstract, and keeping
more-or-less the status quo (with respect to abstract classes .... but
I'm very committed to removing the necessity of extending Tapestry
classes).
Please take these thoughts for what they are ... off the top of my head.
On Fri, 11 Feb 2005 08:39:38 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> If I remember correctly, Howard said that in 3.1 you would only need to
> declare a property in the page spec *or* an abstract getter/setter in
> the java file, but not both: DRY.
>
>
> On Feb 11, 2005, at 8:28 AM, Erik Hatcher wrote:
>
> >
> > There are no substantial advantages or disadvantages. It's more a
> > matter of taste. The 'abstract' thing bothers me... and I believe 3.1
> > will solve a lot of this by making it unnecessary to have them
> > (Howard??). Having true getters/setters for information going into or
> > out of a page is what I'd like to see, without having the state
> > management worries that we currently have in 3.0.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Jamie Orchard-Hays <ja...@dang.com>.
If I remember correctly, Howard said that in 3.1 you would only need to
declare a property in the page spec *or* an abstract getter/setter in
the java file, but not both: DRY.
On Feb 11, 2005, at 8:28 AM, Erik Hatcher wrote:
>
> There are no substantial advantages or disadvantages. It's more a
> matter of taste. The 'abstract' thing bothers me... and I believe 3.1
> will solve a lot of this by making it unnecessary to have them
> (Howard??). Having true getters/setters for information going into or
> out of a page is what I'd like to see, without having the state
> management worries that we currently have in 3.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 11, 2005, at 5:39 AM, Jonathan O'Connor wrote:
> Erik,
> You wrote:
> In fact, I've been
> using get/setProperty() exclusively lately and not doing the 'abstract'
> thing.
>
> But, you still have to supply the name of the property as a param for
> get/setProperty, and I, for one, think it is easier to have IDE support
> and strong typing.
No argument there. I still get strong typing by casting, of course.
By declaring types in the page specification, you're losing type
checking in the IDE and with OGNL expressions you have no IDE type
checking either. So being loose with types at some levels is something
we need to get used to.
> What happens when you mistype the property name? How quickly does the
> error show up? I suppose you get more NPEs at runtime.
I bet I get less NPE's at runtime than most :)
But sure, mistyping causes errors. What happens if you mistype the
class name in a page specification? Or mistype an OGNL expression?
> Can you give a list of advantages/disadvantages of your technique?
There are no substantial advantages or disadvantages. It's more a
matter of taste. The 'abstract' thing bothers me... and I believe 3.1
will solve a lot of this by making it unnecessary to have them
(Howard??). Having true getters/setters for information going into or
out of a page is what I'd like to see, without having the state
management worries that we currently have in 3.0.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org