You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship" <hl...@attbi.com> on 2003/01/24 02:56:47 UTC
Declarative Properties are IN !!!!!!
I've been home and on a roll today!
I've put together declarative properties over the last 30 hours. What are they? It's a radical improvement to Tapestry.
You may now declare your transient and persistent properties. Tapestry will take care of the rest. This includes instance variables, accessor methods, initialization, and end-of-request cleanup.
<property-specification name="foo" type="int" persistent="yes" initial-value="100"/>
What Tapestry does is use BCEL to create a subclass of the page or component class you specify (or don't specify, in which case a default is used). It creates the fields and accessor methods and creates additional objects to re-initialize the property at the end of the request cycle.
If you want, you can declare your class abstract, and provide abstract accessor methods. That way you can read and update properties, in a typesafe manner, from your listener methods.
This stuff is just plain magic! It also helps me because I don't have to discuss the gory details of initialize() or finishLoad(), at least not right off the bat. It also means that, even more often, you can create a very functional page without creating a subclass of BasePage.
And in case you missed it ... this works on components as well as pages.
What's the cost? Well, we now have bcel-5.0.jar in the classpath. When a particlar page or component is first created, Tapestry has to create the enhanced subclass. That seems to take about 2ms or so (on my laptop) for each enhanced property. Again, that cost is paid once, the first time a particular page or component is instantiated.
It's all in, it's all documented (in the new User's Guide), and the new code has about 98% code coverage in the JUnit test suite.
----
Howard Lewis Ship
hlship@attbi.com
http://jakarta.apache.org/proposals/tapestry
Re: Declarative Properties are IN !!!!!!
Posted by Viktor Szathmary <ph...@imapmail.org>.
hi,
On Thu, 23 Jan 2003 20:56:47 -0500, "Howard M. Lewis Ship"
<hl...@attbi.com> said:
> I've put together declarative properties over the last 30 hours. What
> are they? It's a radical improvement to Tapestry.
It seems to me, that the most error-prone part (especially initially) of
using tapestry is the pooling behavior, and it is certainly good to see
some improvement in this area... and i'm sure writing byte-code tricks is
a lot of fun too :)
However, i'm still not convinced, that a simple java solution would not
be feasible, and in fact a lot simpler (which imo is always a good
thing)... you wrote in one of your emails previously, that over time you
came to appreciate delegation over inheritance. i think the headaches of
detach() are a sideeffect of inheriting all the pooling behavior of a
component/page. you're also taking extra performance hits by having to
deepcopy persitent properties, since people ran into problems with
calling clear() on a Map in detach() etc... Now think about this for a
second: as far as developer experience is concerned, a straightforward
way to do things would be:
class FooPage extends BasePage {
private int foo = 100;
public int getFoo() { return foo; }
public void setFoo(int foo) {
this.foo=foo;
fireObservedChange("foo",foo);
}
}
... and just expect tapestry to construct your component every time (no
more implements IPageDetachListener either). I don't see why you couldn't
do this with some refactoring of the Tapestry internals (which imo would
probably be less code than all the BCEL+cloning stuff that went in for
2.4). eg. if you need to keep certain heavyweight data related to a page,
fine, pool it, but don't make this implementation detail (a performance
optimization) affect ease of use. use delegation instead of inheritance
for this: move this behavior out from the base page/component hierarchy.
what do you think? am i oversimplifying things? did i overlook something
obvious?
best regards,
viktor
--
phraktle@imapmail.org
--
http://fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
Re: Declarative Properties are IN !!!!!!
Posted by Viktor Szathmary <ph...@imapmail.org>.
hi,
On Thu, 23 Jan 2003 20:56:47 -0500, "Howard M. Lewis Ship"
<hl...@attbi.com> said:
> I've put together declarative properties over the last 30 hours. What
> are they? It's a radical improvement to Tapestry.
It seems to me, that the most error-prone part (especially initially) of
using tapestry is the pooling behavior, and it is certainly good to see
some improvement in this area... and i'm sure writing byte-code tricks is
a lot of fun too :)
However, i'm still not convinced, that a simple java solution would not
be feasible, and in fact a lot simpler (which imo is always a good
thing)... you wrote in one of your emails previously, that over time you
came to appreciate delegation over inheritance. i think the headaches of
detach() are a sideeffect of inheriting all the pooling behavior of a
component/page. you're also taking extra performance hits by having to
deepcopy persitent properties, since people ran into problems with
calling clear() on a Map in detach() etc... Now think about this for a
second: as far as developer experience is concerned, a straightforward
way to do things would be:
class FooPage extends BasePage {
private int foo = 100;
public int getFoo() { return foo; }
public void setFoo(int foo) {
this.foo=foo;
fireObservedChange("foo",foo);
}
}
... and just expect tapestry to construct your component every time (no
more implements IPageDetachListener either). I don't see why you couldn't
do this with some refactoring of the Tapestry internals (which imo would
probably be less code than all the BCEL+cloning stuff that went in for
2.4). eg. if you need to keep certain heavyweight data related to a page,
fine, pool it, but don't make this implementation detail (a performance
optimization) affect ease of use. use delegation instead of inheritance
for this: move this behavior out from the base page/component hierarchy.
what do you think? am i oversimplifying things? did i overlook something
obvious?
best regards,
viktor
--
phraktle@imapmail.org
--
http://fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
Re: Declarative Properties are IN !!!!!!
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
I may find time to look at the patch in th enext week or so. I'm in
bandwidth overload!
----- Original Message -----
From: "David Solis" <ds...@legosoft.com.mx>
To: "'Tapestry-User'" <ta...@jakarta.apache.org>
Cc: "'Howard M. Lewis Ship'" <hl...@attbi.com>
Sent: Thursday, January 23, 2003 9:03 PM
Subject: RE: Declarative Properties are IN !!!!!!
> Wow! This was my most wanted feature.
>
> BTW, did you receive my email about the wml patch?
>
> Regards
>
> David
>
> > -----Original Message-----
> > From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
> > Sent: Thursday, January 23, 2003 7:57 PM
> > To: Tapestry-Dev
> > Cc: Tapestry-User
> > Subject: Declarative Properties are IN !!!!!!
> >
> > I've been home and on a roll today!
> >
> > I've put together declarative properties over the last 30 hours. What
> are
> > they? It's a radical improvement to Tapestry.
> >
> > You may now declare your transient and persistent properties.
> Tapestry
> > will take care of the rest. This includes instance variables,
> accessor
> > methods, initialization, and end-of-request cleanup.
> >
> > <property-specification name="foo" type="int" persistent="yes"
> initial-
> > value="100"/>
> >
> > What Tapestry does is use BCEL to create a subclass of the page or
> > component class you specify (or don't specify, in which case a default
> is
> > used). It creates the fields and accessor methods and creates
> additional
> > objects to re-initialize the property at the end of the request cycle.
> >
> > If you want, you can declare your class abstract, and provide abstract
> > accessor methods. That way you can read and update properties, in a
> > typesafe manner, from your listener methods.
> >
> > This stuff is just plain magic! It also helps me because I don't have
> to
> > discuss the gory details of initialize() or finishLoad(), at least not
> > right off the bat. It also means that, even more often, you can
> create a
> > very functional page without creating a subclass of BasePage.
> >
> > And in case you missed it ... this works on components as well as
> pages.
> >
> > What's the cost? Well, we now have bcel-5.0.jar in the classpath.
> When a
> > particlar page or component is first created, Tapestry has to create
> the
> > enhanced subclass. That seems to take about 2ms or so (on my laptop)
> for
> > each enhanced property. Again, that cost is paid once, the first time
> a
> > particular page or component is instantiated.
> >
> > It's all in, it's all documented (in the new User's Guide), and the
> new
> > code has about 98% code coverage in the JUnit test suite.
> >
> > ----
> > Howard Lewis Ship
> > hlship@attbi.com
> > http://jakarta.apache.org/proposals/tapestry
>
>
RE: Declarative Properties are IN !!!!!!
Posted by David Solis <ds...@legosoft.com.mx>.
Wow! This was my most wanted feature.
BTW, did you receive my email about the wml patch?
Regards
David
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
> Sent: Thursday, January 23, 2003 7:57 PM
> To: Tapestry-Dev
> Cc: Tapestry-User
> Subject: Declarative Properties are IN !!!!!!
>
> I've been home and on a roll today!
>
> I've put together declarative properties over the last 30 hours. What
are
> they? It's a radical improvement to Tapestry.
>
> You may now declare your transient and persistent properties.
Tapestry
> will take care of the rest. This includes instance variables,
accessor
> methods, initialization, and end-of-request cleanup.
>
> <property-specification name="foo" type="int" persistent="yes"
initial-
> value="100"/>
>
> What Tapestry does is use BCEL to create a subclass of the page or
> component class you specify (or don't specify, in which case a default
is
> used). It creates the fields and accessor methods and creates
additional
> objects to re-initialize the property at the end of the request cycle.
>
> If you want, you can declare your class abstract, and provide abstract
> accessor methods. That way you can read and update properties, in a
> typesafe manner, from your listener methods.
>
> This stuff is just plain magic! It also helps me because I don't have
to
> discuss the gory details of initialize() or finishLoad(), at least not
> right off the bat. It also means that, even more often, you can
create a
> very functional page without creating a subclass of BasePage.
>
> And in case you missed it ... this works on components as well as
pages.
>
> What's the cost? Well, we now have bcel-5.0.jar in the classpath.
When a
> particlar page or component is first created, Tapestry has to create
the
> enhanced subclass. That seems to take about 2ms or so (on my laptop)
for
> each enhanced property. Again, that cost is paid once, the first time
a
> particular page or component is instantiated.
>
> It's all in, it's all documented (in the new User's Guide), and the
new
> code has about 98% code coverage in the JUnit test suite.
>
> ----
> Howard Lewis Ship
> hlship@attbi.com
> http://jakarta.apache.org/proposals/tapestry
Re: Declarative Properties are IN !!!!!!
Posted by Eric Everman <ev...@precedadesign.com>.
Very Nice-
I can't wait to try this! Another plus is that it makes it easier for a
non-coder to create a page - always a good thing.
Eric Everman
At 1/23/2003, you wrote:
>I've been home and on a roll today!
>
>I've put together declarative properties over the last 30 hours. What are
>they? It's a radical improvement to Tapestry.
>
>You may now declare your transient and persistent properties. Tapestry
>will take care of the rest. This includes instance variables, accessor
>methods, initialization, and end-of-request cleanup.
>
><property-specification name="foo" type="int" persistent="yes"
>initial-value="100"/>
>
>What Tapestry does is use BCEL to create a subclass of the page or
>component class you specify (or don't specify, in which case a default is
>used). It creates the fields and accessor methods and creates additional
>objects to re-initialize the property at the end of the request cycle.
>
>If you want, you can declare your class abstract, and provide abstract
>accessor methods. That way you can read and update properties, in a
>typesafe manner, from your listener methods.
>
>This stuff is just plain magic! It also helps me because I don't have to
>discuss the gory details of initialize() or finishLoad(), at least not
>right off the bat. It also means that, even more often, you can create a
>very functional page without creating a subclass of BasePage.
>
>And in case you missed it ... this works on components as well as pages.
>
>What's the cost? Well, we now have bcel-5.0.jar in the classpath. When a
>particlar page or component is first created, Tapestry has to create the
>enhanced subclass. That seems to take about 2ms or so (on my laptop) for
>each enhanced property. Again, that cost is paid once, the first time a
>particular page or component is instantiated.
>
>It's all in, it's all documented (in the new User's Guide), and the new
>code has about 98% code coverage in the JUnit test suite.
>
>----
>Howard Lewis Ship
>hlship@attbi.com
>http://jakarta.apache.org/proposals/tapestry