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 Lewis Ship <hl...@gmail.com> on 2010/01/19 20:03:47 UTC
Thought experiment: shared pages/components
I'm doing some interesting work with changes to
ComponentClassTransformer right now; part of what I'm doing is to set
the stage for moving away from Javassist in the future.
Increasingly, I'm building up new APIs that allow the transformations
on the component class to be expressed in terms of interfaces and
callbacks, and I'm decreasing the amount of "Javassist-psuedocode"
that gets written.
I'll have some checkins to 5.2 in a few more days.
One idea that's occured to me is that, in addition to instrumenting
injected fields and parameter fields, we could use the same trick for
ordinary fields, holding transient per-request data. Effectively, the
page would contain no mutable state, all mutable state for the page
would be shunted off into a per-request HashMap.
There'd be some overhead to that (reading or updating a field would
turn into several method calls), but if done properly, it means we
would only need ONE instance of a page (per locale).
I wonder if this is worth pursuing; it's a lot of work. Done a
reduction in memory overhead and some of the other aspects (such as
page pool maintenance) justify the overhead for field access? Plus
there are some areas I'm not sure how to handle.
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Jan 20, 2010 at 2:28 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
>> ... while this feels like a derivation from a jure-language...
>
> It really feels like some dynamic languages such as Javascript.
>
> Jure language???
Yep... Coljure, dynamic and with immutable state.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 19 Jan 2010 19:26:52 -0200, Massimo Lusetti <ml...@gmail.com>
wrote:
>> One idea that's occured to me is that, in addition to instrumenting
>> injected fields and parameter fields, we could use the same trick for
>> ordinary fields, holding transient per-request data. Effectively, the
>> page would contain no mutable state, all mutable state for the page
>> would be shunted off into a per-request HashMap.
>
> ... while this feels like a derivation from a jure-language...
It really feels like some dynamic languages such as Javascript.
Jure language???
> Well field access is quite common so putting an overhead on that are
> doesn't sounds so appealing
Thinking about it, non-annotated fields are not used that much except in
pages with loops or grids.
> That said we already have have an application server to run T5 that
> holds a various types of pools and threads so i see simplifications of
> the "T5 page" mechanism as a great plus,
Making Tapestry page instances stateless would make they seem a little
like servlets and the fields as type-safe attributes in the request scope.
:)
What about component fields? Would they be stored by complete id? And
mixin fields?
> having one instance of a page
> instead of a pool to serve requests is by definition a good thing
> while i'm not sure to follow you where you want to "store" the map
> holding the "request states"
The map could be stored in a ThreadLocal in even in the HttpServletRequest.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, Jan 19, 2010 at 8:03 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm doing some interesting work with changes to
> ComponentClassTransformer right now; part of what I'm doing is to set
> the stage for moving away from Javassist in the future.
>
> Increasingly, I'm building up new APIs that allow the transformations
> on the component class to be expressed in terms of interfaces and
> callbacks, and I'm decreasing the amount of "Javassist-psuedocode"
> that gets written.
Reducing the generated code feels like a step in the right
direction... in any way...
> I'll have some checkins to 5.2 in a few more days.
>
> One idea that's occured to me is that, in addition to instrumenting
> injected fields and parameter fields, we could use the same trick for
> ordinary fields, holding transient per-request data. Effectively, the
> page would contain no mutable state, all mutable state for the page
> would be shunted off into a per-request HashMap.
... while this feels like a derivation from a jure-language...
> There'd be some overhead to that (reading or updating a field would
> turn into several method calls), but if done properly, it means we
> would only need ONE instance of a page (per locale).
>
> I wonder if this is worth pursuing; it's a lot of work. Done a
> reduction in memory overhead and some of the other aspects (such as
> page pool maintenance) justify the overhead for field access? Plus
> there are some areas I'm not sure how to handle.
Well field access is quite common so putting an overhead on that are
doesn't sounds so appealing while on the other hand if that overhead
is limited to the call to n-methods that simply do lookups (maybe to
the mentioned map) and doesn't move things around, well, could not be
bad.
That said we already have have an application server to run T5 that
holds a various types of pools and threads so i see simplifications of
the "T5 page" mechanism as a great plus, having one instance of a page
instead of a pool to serve requests is by definition a good thing
while i'm not sure to follow you where you want to "store" the map
holding the "request states"
Anyway i must admin that my experience with T5 is with complex web
applications with not so many pages but with pages with a lot of
states and complex structure so I'm not so incline to have trouble
with the current default pages-pool system.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 20 Jan 2010 11:16:54 -0200, Kristian Marinkovic
<kr...@porsche.co.at> wrote:
> but would a change, as proposed by howard, change the performance
> characteristics as described by
> http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/?
That comparison is not fair to Tapestry, as it was implemented in a
Seam-ish way instead of a Tapestry-ish way. The Tapestry implementation of
that project puts a lot of info in the session, *including search
results". That's plainly wrong, maybe even evil for a comparison. See
http://code.google.com/p/perfbench/source/browse/trunk/perfbench/tapestry-jpa/src/main/java/tapestryjpa/web/BookingSession.java,
an object put in the session through @SessionState.
How can Tapestry, that doesn't use the session itself, could have the same
memory usage than Wicket, that puts component (page) trees in the session?
That's simply wrong. There was a discussion about it in this same list
some time ago.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
i agree with you on the CDI topic.
but would a change, as proposed by howard, change the performance
characteristics as described by
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/?
would the benchmark be improved? i'd expect, that at least the memory
consumption
would decrease.
especially when comparing with wicket, i'd like to have a unique selling
proposition.
before the benchmark i was always arguing - as documented - that Tapestry
5 would
achieve better performance (speed, memory) characteristics because of its
"static
structure - dynamic behaviour" paradigm. now after the benchmark i don't
see this
argument hold anymore. (or maybe s
so again, would such a change improve T5 in such a way we could outperform
any
other web framework in a certain area?
g,
kris
"Thiago H. de Paula Figueiredo" <th...@gmail.com>
20.01.2010 13:55
Bitte antworten an
"Tapestry development" <de...@tapestry.apache.org>
An
"Tapestry development" <de...@tapestry.apache.org>
Kopie
Thema
Re: Thought experiment: shared pages/components
On Wed, 20 Jan 2010 10:21:35 -0200, Piero Sartini <li...@pierosartini.de>
wrote:
> I think making tapestry-ioc a portable extension is the way to go.
I agree. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 20 Jan 2010 10:21:35 -0200, Piero Sartini <li...@pierosartini.de>
wrote:
> I think making tapestry-ioc a portable extension is the way to go.
I agree. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Piero Sartini <li...@pierosartini.de>.
> It would be really nice to integrate with CDI. There are two ways of doing
> that: making Tapestry-IoC implement CDI (harder, more interesting) or making
> Tapestry-IoC a portable extension to CDI (easier, less interesting, but
> still interesting)
> (http://docs.jboss.org/weld/reference/1.0.0/en-US/html/extend.html).
I think making tapestry-ioc a portable extension is the way to go.
Think about scenarios where I want to use EJB and CDI beans in the
backend, while tapestry and tapestry-ioc is sitting in the frontend.
Just like people are already doing with spring now.
If we would implement the CDI specification with tapestry-ioc, we end
up rebuilding most of what the application server already provides us
for free. Also we then have 2 implementations in place: tapestry-ioc
as well as the application server. For me, Integrating is alway better
than (re-)implementing. But thats just my oppinion of course.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 20 Jan 2010 09:49:12 -0200, Piero Sartini <li...@pierosartini.de>
wrote:
> Totally agree on this.
> +1 for JEE6 support (aka CDI integration)
It would be really nice to integrate with CDI. There are two ways of doing
that: making Tapestry-IoC implement CDI (harder, more interesting) or
making Tapestry-IoC a portable extension to CDI (easier, less interesting,
but still interesting)
(http://docs.jboss.org/weld/reference/1.0.0/en-US/html/extend.html).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Piero Sartini <li...@pierosartini.de>.
>> Another thing is the integration of JEE6 specs. I believe it is
>> strategically important to label Tapestry as "JEE 6 compliant" framework.
>> There are still too much developers who care about the standards.
>
> You're still right Igor. As i see not only developers are interested
> in standards but also a lot (all?) managers do.
>
> T5 is by far superior to a lot of (all?) frameworks to build web app
> (and not only web app) and that would be a great plus for it's wide
> spreading...
Totally agree on this.
+1 for JEE6 support (aka CDI integration)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Jan 20, 2010 at 8:08 AM, Igor Drobiazko
<ig...@gmail.com> wrote:
> still don't have a solution for the asset protection, two releases have been
> canceled.
Completely agree and that still a shame...
> Another thing is the integration of JEE6 specs. I believe it is
> strategically important to label Tapestry as "JEE 6 compliant" framework.
> There are still too much developers who care about the standards.
You're still right Igor. As i see not only developers are interested
in standards but also a lot (all?) managers do.
T5 is by far superior to a lot of (all?) frameworks to build web app
(and not only web app) and that would be a great plus for it's wide
spreading...
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Thought experiment: shared pages/components
Posted by Igor Drobiazko <ig...@gmail.com>.
I agree with Thiago that the suggested feature is a nice to have and should
be on the roadmap. The migration from Javassist doesn't provide a direct
added value to the users and I think Tapestry would profit more if you would
spend your time in other areas. Do we really need this feature is 5.2
release? I think there are some more important things to do. For example we
still don't have a solution for the asset protection, two releases have been
canceled.
Another thing is the integration of JEE6 specs. I believe it is
strategically important to label Tapestry as "JEE 6 compliant" framework.
There are still too much developers who care about the standards.
Just my 2 cents.
On Wed, Jan 20, 2010 at 2:21 AM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
>
> I suggest putting this suggestion in the roadmap for some not yet defined
> future Tapestry releas
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
Re: Thought experiment: shared pages/components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 19 Jan 2010 17:03:47 -0200, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I'm doing some interesting work with changes to
> ComponentClassTransformer right now; part of what I'm doing is to set
> the stage for moving away from Javassist in the future.
Nice!
> Increasingly, I'm building up new APIs that allow the transformations
> on the component class to be expressed in terms of interfaces and
> callbacks, and I'm decreasing the amount of "Javassist-psuedocode"
> that gets written.
I have some experience in code generation (that's what I did in my
master's course) and I think you're in the right path: keep the generated
code to a minimum. Just glue code being generated, just link
PropertyConduitSource does. I guess this approach could also be used to
improve proxy generation, including annotations in service implementation
methods.
> I wonder if this is worth pursuing; it's a lot of work. Done a
> reduction in memory overhead and some of the other aspects (such as
> page pool maintenance) justify the overhead for field access? Plus
> there are some areas I'm not sure how to handle.
Tapestry doesn't use much memory nor CPU now. Considering it would take a
lot of time to be implemented, I think your time would be better spent in
other areas, even considering your idea something very interesting. I
don't think the method call overhead would be significant.
I suggest putting this suggestion in the roadmap for some not yet defined
future Tapestry release.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org