You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Rob Smeets <rb...@gmail.com> on 2008/03/18 15:44:58 UTC
Tapestry at my company
Hi All,
Tomorrow is our last day of debate at my work about which framework to
choose for our upcoming huge project.
Its seems Wicket is winning the race for it's innovativeness, finess and
excellent support, they claim, unfortunately. Most on my team members are
concerned about the radically incompatible versions Tapestry has. And many
say Tapestry 5 is over engineerd and has already lost the webframework
battle and are concerned of it's future, in terms of upgrade and support.
Could someone here offer me some killer arguments to counterfight these FUDs
of my team?
Regards,
Rob
Re: Tapestry at my company
Posted by Francois Armand <fa...@linagora.com>.
Rob Smeets wrote:
> Hi All,
>
> [....]
I really really hope that no Wicket's dev are aware of that continuous fud.
And I really really hope that no Tapestry user is doing the same thing
on Wicket's list (or anywhere else, for the matter).
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Tapestry already does some caching on invariant properties, and when it
doesn't the overhead of actually reading the property again is
negligible unless it result in a database query etc. Also, I have plenty
of pages where properties change while rendering the page.
So, no. It wouldn't be useful.
-Filip
On 2008-03-18 18:01, Tobias Marx wrote:
> Wouldn't it be useful to make the @Cache annotation the default annotation
> for all methods?
>
> I can not imagine a case where it would make sense that during the rendering of a page returns different results...
>
> -------- Original-Nachricht --------
>> Datum: Tue, 18 Mar 2008 11:53:09 -0500
>> Von: "Adam Zimowski" <zi...@gmail.com>
>> An: "Tapestry users" <us...@tapestry.apache.org>
>> Betreff: Re: @Cached and caching in general
>
>> @Cache works on per request basis, so that anything you return from a
>> method which has @Cache annotation will get actually "built" or
>> "retrieved" only once - but only once per http request. So if you're
>> building an expensive HTML fragment:
>>
>> @Cached
>> public String buildExpensiveHtmlFragment() {
>> //.........
>> }
>>
>> during a request of a single thread you can call
>> buildExpensiveHtmlFragment() as many times as you want with a full
>> confidence that the work to build it would be performed only once.
>> When you refresh the page, the build will be invoked once again (but
>> once only).
>>
>> -adam
>>
>> On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx <tm...@gmx.de> wrote:
>>> I have not used T5 yet, but would @Cached use the file system for
>> caching HTML fragments similiar to caching mechanisms in some php frameworks?
>>> Or is this a pure memory-based cache?
>>>
>>> I am thinking about migrating an old PHP application to T5 - it has
>> really a lot of traffic and any users are logged in at the same time.
>>> It is quite a low-level application that is still quite fast due to
>> cron jobs in the background that generate HTML fragments that are included to
>> reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
>> huge tables).
>>> Somehow I don't trust Hibernate for high-performance database queries
>> on huge tables .... as I think if tables are huge and many people access it,
>> it will always lead to problems...no matter how good the queries are and
>> how well you have splitted the data across several tables.
>>> So I think the best solution is always to generate HTML fragments in
>> the background that take a long time and simple "include" them....this is
>> even quicker then parsing templates when the data is cached. So you save the
>> time necessary for querying the database plus the time necessary for
>> processing the templates that are involved.
>>> Currently the setup on this application uses one-way database
>> replication and the cron jobs access the the huge data table on the replicated
>> database and generate those HTML fragments without disturbing the
>> web-applications performance. So the main application simply includes those HTML
>> fragments within milliseconds.
>>> But maybe the T5 caching mechanism would make all of those low-level
>> tricks redundant?
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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: @Cached and caching in general
Posted by Howard Lewis Ship <hl...@gmail.com>.
Nope. It's dangerous stuff that should be used with care.
On Tue, Mar 18, 2008 at 10:01 AM, Tobias Marx <mu...@fantasymail.de> wrote:
> Wouldn't it be useful to make the @Cache annotation the default annotation
> for all methods?
>
> I can not imagine a case where it would make sense that during the rendering of a page returns different results...
>
> -------- Original-Nachricht --------
> > Datum: Tue, 18 Mar 2008 11:53:09 -0500
> > Von: "Adam Zimowski" <zi...@gmail.com>
>
> > An: "Tapestry users" <us...@tapestry.apache.org>
> > Betreff: Re: @Cached and caching in general
>
>
>
> > @Cache works on per request basis, so that anything you return from a
> > method which has @Cache annotation will get actually "built" or
> > "retrieved" only once - but only once per http request. So if you're
> > building an expensive HTML fragment:
> >
> > @Cached
> > public String buildExpensiveHtmlFragment() {
> > //.........
> > }
> >
> > during a request of a single thread you can call
> > buildExpensiveHtmlFragment() as many times as you want with a full
> > confidence that the work to build it would be performed only once.
> > When you refresh the page, the build will be invoked once again (but
> > once only).
> >
> > -adam
> >
> > On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx <tm...@gmx.de> wrote:
> > > I have not used T5 yet, but would @Cached use the file system for
> > caching HTML fragments similiar to caching mechanisms in some php frameworks?
> > >
> > > Or is this a pure memory-based cache?
> > >
> > > I am thinking about migrating an old PHP application to T5 - it has
> > really a lot of traffic and any users are logged in at the same time.
> > >
> > > It is quite a low-level application that is still quite fast due to
> > cron jobs in the background that generate HTML fragments that are included to
> > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
> > huge tables).
> > >
> > > Somehow I don't trust Hibernate for high-performance database queries
> > on huge tables .... as I think if tables are huge and many people access it,
> > it will always lead to problems...no matter how good the queries are and
> > how well you have splitted the data across several tables.
> > >
> > > So I think the best solution is always to generate HTML fragments in
> > the background that take a long time and simple "include" them....this is
> > even quicker then parsing templates when the data is cached. So you save the
> > time necessary for querying the database plus the time necessary for
> > processing the templates that are involved.
> > >
> > > Currently the setup on this application uses one-way database
> > replication and the cron jobs access the the huge data table on the replicated
> > database and generate those HTML fragments without disturbing the
> > web-applications performance. So the main application simply includes those HTML
> > fragments within milliseconds.
> > >
> > > But maybe the T5 caching mechanism would make all of those low-level
> > tricks redundant?
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
caching every method by default is definitely too error prone,
and unexpected for most people.
On Tue, Mar 25, 2008 at 3:23 PM, Francois Armand <fa...@linagora.com> wrote:
> superoverdrive@gmx.de wrote:
> > Yes, you are right. But loops are usually inside of components and pages contain those components....but all methods in the page itself could be @Cache methods in my opinion if you do a "component based approach" and always package logical widgets into a component.
> >
> That means that if forbid the use of loop in page (for example, a loop
> through all the high-level widgets of the page) , or at least that the
> default behaviour for component's or for page's method is not the
> same... In my opinion, it looks like to be very error prone, with things
> that just don't work as expected.
>
>
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org
> FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> 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: @Cached and caching in general
Posted by Francois Armand <fa...@linagora.com>.
superoverdrive@gmx.de wrote:
> Yes, you are right. But loops are usually inside of components and pages contain those components....but all methods in the page itself could be @Cache methods in my opinion if you do a "component based approach" and always package logical widgets into a component.
>
That means that if forbid the use of loop in page (for example, a loop
through all the high-level widgets of the page) , or at least that the
default behaviour for component's or for page's method is not the
same... In my opinion, it looks like to be very error prone, with things
that just don't work as expected.
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by su...@gmx.de.
Yes, you are right. But loops are usually inside of components and pages contain those components....but all methods in the page itself could be @Cache methods in my opinion if you do a "component based approach" and always package logical widgets into a component.
-------- Original-Nachricht --------
> Datum: Tue, 25 Mar 2008 13:33:19 +0100
> Von: Francois Armand <fa...@linagora.com>
> An: Tapestry users <us...@tapestry.apache.org>
> Betreff: Re: @Cached and caching in general
> Tobias Marx wrote:
> > Wouldn't it be useful to make the @Cache annotation the default
> annotation
> > for all methods?
> >
> > I can not imagine a case where it would make sense that during the
> rendering of a page returns different results...
> >
> Just an example : you are in a loop (or grid or a beaneditor any other
> looping component) and you get the current value of an object, for the
> current iteration.
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org
> FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> 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: @Cached and caching in general
Posted by Francois Armand <fa...@linagora.com>.
Tobias Marx wrote:
> Wouldn't it be useful to make the @Cache annotation the default annotation
> for all methods?
>
> I can not imagine a case where it would make sense that during the rendering of a page returns different results...
>
Just an example : you are in a loop (or grid or a beaneditor any other
looping component) and you get the current value of an object, for the
current iteration.
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by Tobias Marx <mu...@fantasymail.de>.
Wouldn't it be useful to make the @Cache annotation the default annotation
for all methods?
I can not imagine a case where it would make sense that during the rendering of a page returns different results...
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 11:53:09 -0500
> Von: "Adam Zimowski" <zi...@gmail.com>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: Re: @Cached and caching in general
> @Cache works on per request basis, so that anything you return from a
> method which has @Cache annotation will get actually "built" or
> "retrieved" only once - but only once per http request. So if you're
> building an expensive HTML fragment:
>
> @Cached
> public String buildExpensiveHtmlFragment() {
> //.........
> }
>
> during a request of a single thread you can call
> buildExpensiveHtmlFragment() as many times as you want with a full
> confidence that the work to build it would be performed only once.
> When you refresh the page, the build will be invoked once again (but
> once only).
>
> -adam
>
> On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx <tm...@gmx.de> wrote:
> > I have not used T5 yet, but would @Cached use the file system for
> caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has
> really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to
> cron jobs in the background that generate HTML fragments that are included to
> reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
> huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database queries
> on huge tables .... as I think if tables are huge and many people access it,
> it will always lead to problems...no matter how good the queries are and
> how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments in
> the background that take a long time and simple "include" them....this is
> even quicker then parsing templates when the data is cached. So you save the
> time necessary for querying the database plus the time necessary for
> processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database
> replication and the cron jobs access the the huge data table on the replicated
> database and generate those HTML fragments without disturbing the
> web-applications performance. So the main application simply includes those HTML
> fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those low-level
> tricks redundant?
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by Adam Zimowski <zi...@gmail.com>.
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually "built" or
"retrieved" only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.........
}
during a request of a single thread you can call
buildExpensiveHtmlFragment() as many times as you want with a full
confidence that the work to build it would be performed only once.
When you refresh the page, the build will be invoked once again (but
once only).
-adam
On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx <tm...@gmx.de> wrote:
> I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
>
> Or is this a pure memory-based cache?
>
> I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
>
> It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
>
> Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
>
> So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
>
> Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
>
> But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
>
> ---------------------------------------------------------------------
> 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: AW: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
thanks :)
It's 00:46 here, I'll try it out in the morning,
If I make it work I'll create a wiki page for it...
Davor Hrg
On Wed, Mar 19, 2008 at 12:38 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> here you go :)
>
> Should be able to drop these into your project.
>
> The Buffer.java is the component ( so somewhere under components package
> ), and the BufferServices needs to go somewhere where Tapestry will not
> enhance it, so I put it under the services package. ). :) Sorry, but
> the "cacheKey/Extra" stuff is a little confusing, but maybe we can start
> a different thread/docs for that, or simplify to make it easier for
> generalization..
>
> The Parameters are:
>
> 1) timeout: String
> a duration in which a cache value will be valid; format: "hh:mm:ss"
> if you want a one hour timeout: "01:00:00".
> if you want a 30 min timeout: "00:30:00"
>
> 2) lastUpdated: Date
> it output this parameter (if bound), to let you know when the contents
> of the Buffer were last updated. So you can print out a small message
> "Last Updated ######"
>
>
> 3) cacheKey: String
> 4) cacehKeyExtra: String
>
> here is where it might get a little confusing.. it generates a key
> into the cache using the request server/port/context/path and cacheKey
> and cacheKeyExtra. So it focuses the cache onto the current server
> and webapp ( since we used a shared memcache this avoids developers
> and production webapps stepping on each others toes ). It then
> adds cacheKey (which defaults to the component's extendedId), and
> cacheKeyExtra (which defaults to empty).
>
> So by default just wrapping your stuff with <buffer timeout> will just
> work since the key will be something like
> "server:port/context_PageName:buffer_#".
>
> You would set cacheKey if you wanted to generalize the contents of the
> buffer ( have the same Buffer component shared across pages ).
>
> You would set cacheKeyExtra if you wanted to specialize the contents of
> the buffer ( have the same Buffer component apply to subsets of
> request.. like if it's user specific ).
>
>
>
>
>
>
>
>
>
>
> Davor Hrg wrote:
> > I'm interested in the one for T5 :)
> >
> > if you are not allowed to share source,
> > maybe few hints how to make it
> >
> > Davor Hrg
> >
> > On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> >> We have a component that we call "Buffer" :) it takes a timeout,
> >> optional cachekey, and optional lastmodified (to tell you)
> >>
> >> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> >> liberate it.. you would just have to change the cache hooks to use
> >> whatever cache you want to use...
> >>
> >> The easiest way to add caching to the app. :)
> >>
> >>
> >>
> >> Martin Kersten wrote:
> >> > @Chached is only used during a single page rendering cycle. It would not
> >> > apply to your situation. (as far as I know)
> >> >
> >> > Source:
> >> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >> >
> >> > Your scenario would be implementable using your own component.
> >> > The component would represent a fragment and read the file (even
> >> > use a inmemory cache strategy (soft/weakreferences)) and write
> >> > the ouput directly to stream (or actually the dom tree of your
> >> > document being returned).
> >> >
> >> > Using your own solution enables you to mimic the behavior you talk about.
> >> > Another idea would to write / cache only datas needed to render the tables
> >> > (e.g. cache only content not markup). Never the less I am in doupt,
> >> > if such a solution is necessary (dynamically cache results of
> >> > database queries in memory or on disk).
> >> >
> >> > So after all you might want to port your application. As always use
> >> > the simpliest solution first. So database queries without any caches.
> >> > Once you see any problems (performance is below required) just go for
> >> > optimization. Since you have a fallback solution at hand (cron-jobs +
> >> > disk fragments) you are at the safe side. But I am in doupt if you
> >> > really need the markup being cached. Caching the database results
> >> > and recreate markup sounds more reasonable. You might save you lots
> >> > of seeking time.
> >> >
> >> > But you always know: Only the code / application will tell you!
> >> >
> >> >
> >> > Cheers,
> >> >
> >> > Martin (Kersten)
> >> >
> >> > -----Ursprüngliche Nachricht-----
> >> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> >> > Gesendet: Dienstag, 18. März 2008 17:45
> >> > An: Tapestry users
> >> > Betreff: @Cached and caching in general
> >> >
> >> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >> >
> >> > Or is this a pure memory-based cache?
> >> >
> >> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >> >
> >> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >> >
> >> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >> >
> >> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >> >
> >> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >> >
> >> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
> ---------------------------------------------------------------------
> 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: AW: @Cached and caching in general
Posted by Fernando Padilla <fe...@alum.mit.edu>.
here you go :)
Should be able to drop these into your project.
The Buffer.java is the component ( so somewhere under components package
), and the BufferServices needs to go somewhere where Tapestry will not
enhance it, so I put it under the services package. ). :) Sorry, but
the "cacheKey/Extra" stuff is a little confusing, but maybe we can start
a different thread/docs for that, or simplify to make it easier for
generalization..
The Parameters are:
1) timeout: String
a duration in which a cache value will be valid; format: "hh:mm:ss"
if you want a one hour timeout: "01:00:00".
if you want a 30 min timeout: "00:30:00"
2) lastUpdated: Date
it output this parameter (if bound), to let you know when the contents
of the Buffer were last updated. So you can print out a small message
"Last Updated ######"
3) cacheKey: String
4) cacehKeyExtra: String
here is where it might get a little confusing.. it generates a key
into the cache using the request server/port/context/path and cacheKey
and cacheKeyExtra. So it focuses the cache onto the current server
and webapp ( since we used a shared memcache this avoids developers
and production webapps stepping on each others toes ). It then
adds cacheKey (which defaults to the component's extendedId), and
cacheKeyExtra (which defaults to empty).
So by default just wrapping your stuff with <buffer timeout> will just
work since the key will be something like
"server:port/context_PageName:buffer_#".
You would set cacheKey if you wanted to generalize the contents of the
buffer ( have the same Buffer component shared across pages ).
You would set cacheKeyExtra if you wanted to specialize the contents of
the buffer ( have the same Buffer component apply to subsets of
request.. like if it's user specific ).
Davor Hrg wrote:
> I'm interested in the one for T5 :)
>
> if you are not allowed to share source,
> maybe few hints how to make it
>
> Davor Hrg
>
> On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
>> We have a component that we call "Buffer" :) it takes a timeout,
>> optional cachekey, and optional lastmodified (to tell you)
>>
>> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
>> liberate it.. you would just have to change the cache hooks to use
>> whatever cache you want to use...
>>
>> The easiest way to add caching to the app. :)
>>
>>
>>
>> Martin Kersten wrote:
>> > @Chached is only used during a single page rendering cycle. It would not
>> > apply to your situation. (as far as I know)
>> >
>> > Source:
>> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>> >
>> > Your scenario would be implementable using your own component.
>> > The component would represent a fragment and read the file (even
>> > use a inmemory cache strategy (soft/weakreferences)) and write
>> > the ouput directly to stream (or actually the dom tree of your
>> > document being returned).
>> >
>> > Using your own solution enables you to mimic the behavior you talk about.
>> > Another idea would to write / cache only datas needed to render the tables
>> > (e.g. cache only content not markup). Never the less I am in doupt,
>> > if such a solution is necessary (dynamically cache results of
>> > database queries in memory or on disk).
>> >
>> > So after all you might want to port your application. As always use
>> > the simpliest solution first. So database queries without any caches.
>> > Once you see any problems (performance is below required) just go for
>> > optimization. Since you have a fallback solution at hand (cron-jobs +
>> > disk fragments) you are at the safe side. But I am in doupt if you
>> > really need the markup being cached. Caching the database results
>> > and recreate markup sounds more reasonable. You might save you lots
>> > of seeking time.
>> >
>> > But you always know: Only the code / application will tell you!
>> >
>> >
>> > Cheers,
>> >
>> > Martin (Kersten)
>> >
>> > -----Urspr�ngliche Nachricht-----
>> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
>> > Gesendet: Dienstag, 18. M�rz 2008 17:45
>> > An: Tapestry users
>> > Betreff: @Cached and caching in general
>> >
>> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
>> >
>> > Or is this a pure memory-based cache?
>> >
>> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
>> >
>> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
>> >
>> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
>> >
>> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
>> >
>> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
>> >
>> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>>
>> ---------------------------------------------------------------------
>> 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: AW: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
I'm interested in the one for T5 :)
if you are not allowed to share source,
maybe few hints how to make it
Davor Hrg
On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> We have a component that we call "Buffer" :) it takes a timeout,
> optional cachekey, and optional lastmodified (to tell you)
>
> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> liberate it.. you would just have to change the cache hooks to use
> whatever cache you want to use...
>
> The easiest way to add caching to the app. :)
>
>
>
> Martin Kersten wrote:
> > @Chached is only used during a single page rendering cycle. It would not
> > apply to your situation. (as far as I know)
> >
> > Source:
> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >
> > Your scenario would be implementable using your own component.
> > The component would represent a fragment and read the file (even
> > use a inmemory cache strategy (soft/weakreferences)) and write
> > the ouput directly to stream (or actually the dom tree of your
> > document being returned).
> >
> > Using your own solution enables you to mimic the behavior you talk about.
> > Another idea would to write / cache only datas needed to render the tables
> > (e.g. cache only content not markup). Never the less I am in doupt,
> > if such a solution is necessary (dynamically cache results of
> > database queries in memory or on disk).
> >
> > So after all you might want to port your application. As always use
> > the simpliest solution first. So database queries without any caches.
> > Once you see any problems (performance is below required) just go for
> > optimization. Since you have a fallback solution at hand (cron-jobs +
> > disk fragments) you are at the safe side. But I am in doupt if you
> > really need the markup being cached. Caching the database results
> > and recreate markup sounds more reasonable. You might save you lots
> > of seeking time.
> >
> > But you always know: Only the code / application will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> > Gesendet: Dienstag, 18. März 2008 17:45
> > An: Tapestry users
> > Betreff: @Cached and caching in general
> >
> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> ---------------------------------------------------------------------
> 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: AW: @Cached and caching in general
Posted by Andreas Andreou <an...@gmail.com>.
I had done
http://andyhot.di.uoa.gr/tapfx/app?service=page/Cache
for T3 and T4 @ http://tapfx.sourceforge.net/
but it needed ehcache
Perhaps combine the two (esp. since there's no T5 version) and move to tacos?
On Tue, Mar 18, 2008 at 8:22 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> We have a component that we call "Buffer" :) it takes a timeout,
> optional cachekey, and optional lastmodified (to tell you)
>
> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> liberate it.. you would just have to change the cache hooks to use
> whatever cache you want to use...
>
> The easiest way to add caching to the app. :)
>
>
>
> Martin Kersten wrote:
> > @Chached is only used during a single page rendering cycle. It would not
> > apply to your situation. (as far as I know)
> >
> > Source:
> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >
> > Your scenario would be implementable using your own component.
> > The component would represent a fragment and read the file (even
> > use a inmemory cache strategy (soft/weakreferences)) and write
> > the ouput directly to stream (or actually the dom tree of your
> > document being returned).
> >
> > Using your own solution enables you to mimic the behavior you talk about.
> > Another idea would to write / cache only datas needed to render the tables
> > (e.g. cache only content not markup). Never the less I am in doupt,
> > if such a solution is necessary (dynamically cache results of
> > database queries in memory or on disk).
> >
> > So after all you might want to port your application. As always use
> > the simpliest solution first. So database queries without any caches.
> > Once you see any problems (performance is below required) just go for
> > optimization. Since you have a fallback solution at hand (cron-jobs +
> > disk fragments) you are at the safe side. But I am in doupt if you
> > really need the markup being cached. Caching the database results
> > and recreate markup sounds more reasonable. You might save you lots
> > of seeking time.
> >
> > But you always know: Only the code / application will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> > Gesendet: Dienstag, 18. März 2008 17:45
> > An: Tapestry users
> > Betreff: @Cached and caching in general
> >
> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
I mean exactly that,
I'm comfortable with my html code, css and js
I can inline what I need, I'm not proposing this as a general approach,
but I like doing just that: take part of rendered content and do
something with it.
if something is a compoenent framework, a component should be independant,
even after the html code is rendered.
Davor Hrg
On Wed, Mar 19, 2008 at 10:45 AM, Martin Kersten
<Ma...@mercateo.com> wrote:
> > ...this king of component is useful for capturing output so it can be sent via email for example.
>
> This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... .
>
> -----Ursprüngliche Nachricht-----
> Von: Davor Hrg [mailto:hrgdavor@gmail.com]
> Gesendet: Mittwoch, 19. März 2008 10:42
> An: Tapestry users
> Betreff: Re: AW: @Cached and caching in general
>
>
>
> I agree that this is not something to take on lightly, and data should be cached, and rendering left as is.
> but besides caching this king of component is useful for capturing output so it can be sent via email for example.
>
> I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks.
>
> Davor Hrg
>
> On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> > :)
> >
> > True. I definitely won't say that this will solve all cases 100%.
> > But for basic rendering.. this allows you to essentially set
> > "expires" for fragments of the page. And yes it caches all
> > operations that go through PageRenderSupport. And if I could take
> > over the markupWriter properly, I would have cached and replayed
> > those already.. but i couldn't easily do that.. But on second
> > thought, you're right, maybe I should have cached a DOM tree.. since
> > it would have a much better guarantees for replaying.
> >
> > But on most cases, this component works pretty darn good, and we love it.
> >
> > Of course trying to do evict cache on particular events is hard.. but
> > if you are alright with "updates within 30hr" sort of cases. this is
> > a good start.
> >
> >
> >
> >
> >
> > Howard Lewis Ship wrote:
> > > I'm generally against these approached.
> > >
> > > Cache the data, make it fast to access.
> > >
> > > Let Tapestry do a full render every time.
> > >
> > > You'll end up with confusing, unforseen consequences.
> > >
> > > Rendering is increasingly a complex dance between components.
> > That's > the power and the penalty of Tapestry. Components inside
> > that cached > zone are not just rendering a character stream, they
> > are generating > JavaScript, assigning unique ids (via
> > PageRenderSupport) interacting > with an enclosing Form components,
> > and doing other user-specific > things.
> > >
> > > I would always look elsewhere first for places that need
> > optimization, > and I'd start with database access and queries.
> > >
> > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> > >> We have a component that we call "Buffer" :) it takes a timeout,
> > >> optional cachekey, and optional lastmodified (to tell you) >> >>
> > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> > >> liberate it.. you would just have to change the cache hooks to use
> > >> whatever cache you want to use...
> > >>
> > >> The easiest way to add caching to the app. :) >> >> >> >>
> > Martin Kersten wrote:
> > >> > @Chached is only used during a single page rendering cycle. It
> > would not >> > apply to your situation. (as far as I know) >> >
> > >> > Source:
> > >> >
> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> > >> >
> > >> > Your scenario would be implementable using your own component.
> > >> > The component would represent a fragment and read the file
> > (even >> > use a inmemory cache strategy (soft/weakreferences)) and
> > write >> > the ouput directly to stream (or actually the dom tree of
> > your >> > document being returned).
> > >> >
> > >> > Using your own solution enables you to mimic the behavior you talk about.
> > >> > Another idea would to write / cache only datas needed to render
> > the tables >> > (e.g. cache only content not markup). Never the less
> > I am in doupt, >> > if such a solution is necessary (dynamically
> > cache results of >> > database queries in memory or on disk).
> > >> >
> > >> > So after all you might want to port your application. As always
> > use >> > the simpliest solution first. So database queries without any caches.
> > >> > Once you see any problems (performance is below required) just
> > go for >> > optimization. Since you have a fallback solution at hand
> > (cron-jobs + >> > disk fragments) you are at the safe side. But I am
> > in doupt if you >> > really need the markup being cached. Caching
> > the database results >> > and recreate markup sounds more
> > reasonable. You might save you lots >> > of seeking time.
> > >> >
> > >> > But you always know: Only the code / application will tell you!
> > >> >
> > >> >
> > >> > Cheers,
> > >> >
> > >> > Martin (Kersten)
> > >> >
> > >> > -----Ursprüngliche Nachricht----- >> > Von: Tobias Marx
> > [mailto:tmarx78@gmx.de] >> > Gesendet: Dienstag, 18. März 2008 17:45
> > >> > An: Tapestry users >> > Betreff: @Cached and caching in
> > general >> > >> > I have not used T5 yet, but would @Cached use
> > the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> > >> >
> > >> > Or is this a pure memory-based cache?
> > >> >
> > >> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> > >> >
> > >> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> > >> >
> > >> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> > >> >
> > >> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> > >> >
> > >> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> > >> >
> > >> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> > >> >
> > >> >
> > ---------------------------------------------------------------------
> > >> > 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
> > >> > >> >>
> > ---------------------------------------------------------------------
> > >> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: AW: OnValidate and OnSuccess
Posted by Martin Kersten <Ma...@mercateo.com>.
I allready use it and it is not set.
Give you an idea:
Page {
private String item = "default";
onSuccessFromItemForm() {
print(item) -> "item";
}
onValidateFromItem() throws ValidationException {
print(item) -> "default";
}
}
You see. I would have expected that onValidateFromItem that item is set.
> Yes, I know. And if you use onValidateFromNewItem
> (with newItem the id of the field, not the form) you will see that
> the value of the property is set. Or are you already using the id from the field?
Regards,
Olivier
On Wed, 19 Mar 2008 13:47:37 +0100, "Martin Kersten"
<Ma...@mercateo.com> wrote:
> Hi Oivier,
>
> I actually use onValidateFromComponent. The problem is that the
> property in question was not set to the field value to check.
>
>
> Cheers,
>
> Martin (Kersten)
>
> -----Ursprüngliche Nachricht-----
> Von: Olivier Jacquet [mailto:ojacquet@jax.be]
> Gesendet: Mittwoch, 19. März 2008 12:47
> An: Tapestry users
> Betreff: Re: OnValidate and OnSuccess
>
>
> Hi,
>
>
> I ran into this issue as well. onValidate() is actually called
> multiple times. Try it with onValidateFromNewItem(). I can't check if
> that's how I solved it here.
>
>
> Regards,
> Olivier
>
>
>
>
> On Wed, 19 Mar 2008 11:39:55 +0100, "Martin Kersten"
> <Ma...@mercateo.com> wrote:
>> Having a simple form containing a simple field (TextField) I have
>> problems validating its content.
>>
>> <t:form id="newItemForm">
>> <input t:type="textarea" t:id="newItem" t:value="newItem"/><br/>
>> </t:form>
>>
>>
>> The validation is done using onValidate. The Form is processed using
>> onSuccess. The problem arises that onValidate is invoked *before* the
>> property is updated with the value to validate.
>>
>> Do I have to inject the textarea with the given id?
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: OnValidate and OnSuccess
Posted by Olivier Jacquet <oj...@jax.be>.
Yes, I know. And if you use onValidateFromNewItem (with newItem the id of
the field, not the form) you will see that the value of the property is
set. Or are you already using the id from the field?
Regards,
Olivier
On Wed, 19 Mar 2008 13:47:37 +0100, "Martin Kersten"
<Ma...@mercateo.com> wrote:
> Hi Oivier,
>
> I actually use onValidateFromComponent. The problem is that the
> property
> in question was not set to the field value to check.
>
>
> Cheers,
>
> Martin (Kersten)
>
> -----Ursprüngliche Nachricht-----
> Von: Olivier Jacquet [mailto:ojacquet@jax.be]
> Gesendet: Mittwoch, 19. März 2008 12:47
> An: Tapestry users
> Betreff: Re: OnValidate and OnSuccess
>
>
> Hi,
>
>
> I ran into this issue as well. onValidate() is actually called multiple
> times. Try it with onValidateFromNewItem(). I can't check if that's how I
> solved it here.
>
>
> Regards,
> Olivier
>
>
>
>
> On Wed, 19 Mar 2008 11:39:55 +0100, "Martin Kersten"
> <Ma...@mercateo.com> wrote:
>> Having a simple form containing a simple field (TextField) I have
>> problems validating its content.
>>
>> <t:form id="newItemForm">
>> <input t:type="textarea" t:id="newItem" t:value="newItem"/><br/>
>> </t:form>
>>
>>
>> The validation is done using onValidate. The Form is processed using
>> onSuccess. The problem arises that onValidate is invoked *before* the
>> property is updated with the value to validate.
>>
>> Do I have to inject the textarea with the given id?
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
AW: OnValidate and OnSuccess
Posted by Martin Kersten <Ma...@mercateo.com>.
Hi Oivier,
I actually use onValidateFromComponent. The problem is that the property
in question was not set to the field value to check.
Cheers,
Martin (Kersten)
-----Ursprüngliche Nachricht-----
Von: Olivier Jacquet [mailto:ojacquet@jax.be]
Gesendet: Mittwoch, 19. März 2008 12:47
An: Tapestry users
Betreff: Re: OnValidate and OnSuccess
Hi,
I ran into this issue as well. onValidate() is actually called multiple times. Try it with onValidateFromNewItem(). I can't check if that's how I solved it here.
Regards,
Olivier
On Wed, 19 Mar 2008 11:39:55 +0100, "Martin Kersten"
<Ma...@mercateo.com> wrote:
> Having a simple form containing a simple field (TextField) I have
> problems validating its content.
>
> <t:form id="newItemForm">
> <input t:type="textarea" t:id="newItem" t:value="newItem"/><br/>
> </t:form>
>
>
> The validation is done using onValidate. The Form is processed using
> onSuccess. The problem arises that onValidate is invoked *before* the
> property is updated with the value to validate.
>
> Do I have to inject the textarea with the given id?
>
>
> Cheers,
>
> Martin (Kersten)
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: OnValidate and OnSuccess
Posted by Olivier Jacquet <oj...@jax.be>.
Hi,
I ran into this issue as well. onValidate() is actually called multiple
times. Try it with onValidateFromNewItem(). I can't check if that's how I
solved it here.
Regards,
Olivier
On Wed, 19 Mar 2008 11:39:55 +0100, "Martin Kersten"
<Ma...@mercateo.com> wrote:
> Having a simple form containing a simple field (TextField) I have
> problems validating
> its content.
>
> <t:form id="newItemForm">
> <input t:type="textarea" t:id="newItem" t:value="newItem"/><br/>
> </t:form>
>
>
> The validation is done using onValidate. The Form is
> processed using onSuccess. The problem arises that onValidate is
> invoked *before* the property is updated with the value to validate.
>
> Do I have to inject the textarea with the given id?
>
>
> Cheers,
>
> Martin (Kersten)
>
> ---------------------------------------------------------------------
> 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: OnValidate and OnSuccess
Posted by Martin Kersten <Ma...@mercateo.com>.
Praise Tapestry! I guessed the solution just by intuition.
To retrieve the new value you just need to introduce a parameter.
Field validation is done before setting actual properties.
I read the documentation but I missed the parameter of onValidate.
http://tapestry.apache.org/tapestry5/tapestry-core/guide/validation.html
(At bottom)
so correct would be:
onValidateFromNewItem(String newItemValue) throws ValidationException { }
-----Ursprüngliche Nachricht-----
Von: Martin Kersten [mailto:Martin.Kersten@mercateo.com]
Gesendet: Mittwoch, 19. März 2008 11:40
An: Tapestry users
Betreff: OnValidate and OnSuccess
Having a simple form containing a simple field (TextField) I have problems validating its content.
<t:form id="newItemForm">
<input t:type="textarea" t:id="newItem" t:value="newItem"/><br/> </t:form>
The validation is done using onValidate. The Form is processed using onSuccess. The problem arises that onValidate is invoked *before* the property is updated with the value to validate.
Do I have to inject the textarea with the given id?
Cheers,
Martin (Kersten)
---------------------------------------------------------------------
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
OnValidate and OnSuccess
Posted by Martin Kersten <Ma...@mercateo.com>.
Having a simple form containing a simple field (TextField) I have
problems validating
its content.
<t:form id="newItemForm">
<input t:type="textarea" t:id="newItem" t:value="newItem"/><br/>
</t:form>
The validation is done using onValidate. The Form is
processed using onSuccess. The problem arises that onValidate is
invoked *before* the property is updated with the value to validate.
Do I have to inject the textarea with the given id?
Cheers,
Martin (Kersten)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: AW: @Cached and caching in general
Posted by Martin Kersten <Ma...@mercateo.com>.
> ...this king of component is useful for capturing output so it can be sent via email for example.
This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... .
-----Ursprüngliche Nachricht-----
Von: Davor Hrg [mailto:hrgdavor@gmail.com]
Gesendet: Mittwoch, 19. März 2008 10:42
An: Tapestry users
Betreff: Re: AW: @Cached and caching in general
I agree that this is not something to take on lightly, and data should be cached, and rendering left as is.
but besides caching this king of component is useful for capturing output so it can be sent via email for example.
I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks.
Davor Hrg
On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> :)
>
> True. I definitely won't say that this will solve all cases 100%.
> But for basic rendering.. this allows you to essentially set
> "expires" for fragments of the page. And yes it caches all
> operations that go through PageRenderSupport. And if I could take
> over the markupWriter properly, I would have cached and replayed
> those already.. but i couldn't easily do that.. But on second
> thought, you're right, maybe I should have cached a DOM tree.. since
> it would have a much better guarantees for replaying.
>
> But on most cases, this component works pretty darn good, and we love it.
>
> Of course trying to do evict cache on particular events is hard.. but
> if you are alright with "updates within 30hr" sort of cases. this is
> a good start.
>
>
>
>
>
> Howard Lewis Ship wrote:
> > I'm generally against these approached.
> >
> > Cache the data, make it fast to access.
> >
> > Let Tapestry do a full render every time.
> >
> > You'll end up with confusing, unforseen consequences.
> >
> > Rendering is increasingly a complex dance between components.
> That's > the power and the penalty of Tapestry. Components inside
> that cached > zone are not just rendering a character stream, they
> are generating > JavaScript, assigning unique ids (via
> PageRenderSupport) interacting > with an enclosing Form components,
> and doing other user-specific > things.
> >
> > I would always look elsewhere first for places that need
> optimization, > and I'd start with database access and queries.
> >
> > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> >> We have a component that we call "Buffer" :) it takes a timeout,
> >> optional cachekey, and optional lastmodified (to tell you) >> >>
> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> >> liberate it.. you would just have to change the cache hooks to use
> >> whatever cache you want to use...
> >>
> >> The easiest way to add caching to the app. :) >> >> >> >>
> Martin Kersten wrote:
> >> > @Chached is only used during a single page rendering cycle. It
> would not >> > apply to your situation. (as far as I know) >> >
> >> > Source:
> >> >
> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >> >
> >> > Your scenario would be implementable using your own component.
> >> > The component would represent a fragment and read the file
> (even >> > use a inmemory cache strategy (soft/weakreferences)) and
> write >> > the ouput directly to stream (or actually the dom tree of
> your >> > document being returned).
> >> >
> >> > Using your own solution enables you to mimic the behavior you talk about.
> >> > Another idea would to write / cache only datas needed to render
> the tables >> > (e.g. cache only content not markup). Never the less
> I am in doupt, >> > if such a solution is necessary (dynamically
> cache results of >> > database queries in memory or on disk).
> >> >
> >> > So after all you might want to port your application. As always
> use >> > the simpliest solution first. So database queries without any caches.
> >> > Once you see any problems (performance is below required) just
> go for >> > optimization. Since you have a fallback solution at hand
> (cron-jobs + >> > disk fragments) you are at the safe side. But I am
> in doupt if you >> > really need the markup being cached. Caching
> the database results >> > and recreate markup sounds more
> reasonable. You might save you lots >> > of seeking time.
> >> >
> >> > But you always know: Only the code / application will tell you!
> >> >
> >> >
> >> > Cheers,
> >> >
> >> > Martin (Kersten)
> >> >
> >> > -----Ursprüngliche Nachricht----- >> > Von: Tobias Marx
> [mailto:tmarx78@gmx.de] >> > Gesendet: Dienstag, 18. März 2008 17:45
> >> > An: Tapestry users >> > Betreff: @Cached and caching in
> general >> > >> > I have not used T5 yet, but would @Cached use
> the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >> >
> >> > Or is this a pure memory-based cache?
> >> >
> >> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >> >
> >> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >> >
> >> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >> >
> >> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >> >
> >> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >> >
> >> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >> >
> >> >
> ---------------------------------------------------------------------
> >> > 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
> >> > >> >>
> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
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: AW: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
I agree that this is not something to take on lightly,
and data should be cached, and rendering left as is.
but besides caching this king of component is useful
for capturing output so it can be sent via email for example.
I like to keep most things stateless (only dependant on parameters),
so from time to time I can use some of these nasty tricks.
Davor Hrg
On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> :)
>
> True. I definitely won't say that this will solve all cases 100%. But
> for basic rendering.. this allows you to essentially set "expires" for
> fragments of the page. And yes it caches all operations that go through
> PageRenderSupport. And if I could take over the markupWriter properly,
> I would have cached and replayed those already.. but i couldn't easily
> do that.. But on second thought, you're right, maybe I should have
> cached a DOM tree.. since it would have a much better guarantees for
> replaying.
>
> But on most cases, this component works pretty darn good, and we love it.
>
> Of course trying to do evict cache on particular events is hard.. but if
> you are alright with "updates within 30hr" sort of cases. this is a good
> start.
>
>
>
>
>
> Howard Lewis Ship wrote:
> > I'm generally against these approached.
> >
> > Cache the data, make it fast to access.
> >
> > Let Tapestry do a full render every time.
> >
> > You'll end up with confusing, unforseen consequences.
> >
> > Rendering is increasingly a complex dance between components. That's
> > the power and the penalty of Tapestry. Components inside that cached
> > zone are not just rendering a character stream, they are generating
> > JavaScript, assigning unique ids (via PageRenderSupport) interacting
> > with an enclosing Form components, and doing other user-specific
> > things.
> >
> > I would always look elsewhere first for places that need optimization,
> > and I'd start with database access and queries.
> >
> > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> >> We have a component that we call "Buffer" :) it takes a timeout,
> >> optional cachekey, and optional lastmodified (to tell you)
> >>
> >> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> >> liberate it.. you would just have to change the cache hooks to use
> >> whatever cache you want to use...
> >>
> >> The easiest way to add caching to the app. :)
> >>
> >>
> >>
> >> Martin Kersten wrote:
> >> > @Chached is only used during a single page rendering cycle. It would not
> >> > apply to your situation. (as far as I know)
> >> >
> >> > Source:
> >> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >> >
> >> > Your scenario would be implementable using your own component.
> >> > The component would represent a fragment and read the file (even
> >> > use a inmemory cache strategy (soft/weakreferences)) and write
> >> > the ouput directly to stream (or actually the dom tree of your
> >> > document being returned).
> >> >
> >> > Using your own solution enables you to mimic the behavior you talk about.
> >> > Another idea would to write / cache only datas needed to render the tables
> >> > (e.g. cache only content not markup). Never the less I am in doupt,
> >> > if such a solution is necessary (dynamically cache results of
> >> > database queries in memory or on disk).
> >> >
> >> > So after all you might want to port your application. As always use
> >> > the simpliest solution first. So database queries without any caches.
> >> > Once you see any problems (performance is below required) just go for
> >> > optimization. Since you have a fallback solution at hand (cron-jobs +
> >> > disk fragments) you are at the safe side. But I am in doupt if you
> >> > really need the markup being cached. Caching the database results
> >> > and recreate markup sounds more reasonable. You might save you lots
> >> > of seeking time.
> >> >
> >> > But you always know: Only the code / application will tell you!
> >> >
> >> >
> >> > Cheers,
> >> >
> >> > Martin (Kersten)
> >> >
> >> > -----Ursprüngliche Nachricht-----
> >> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> >> > Gesendet: Dienstag, 18. März 2008 17:45
> >> > An: Tapestry users
> >> > Betreff: @Cached and caching in general
> >> >
> >> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >> >
> >> > Or is this a pure memory-based cache?
> >> >
> >> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >> >
> >> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >> >
> >> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >> >
> >> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >> >
> >> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >> >
> >> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by Fernando Padilla <fe...@alum.mit.edu>.
:)
True. I definitely won't say that this will solve all cases 100%. But
for basic rendering.. this allows you to essentially set "expires" for
fragments of the page. And yes it caches all operations that go through
PageRenderSupport. And if I could take over the markupWriter properly,
I would have cached and replayed those already.. but i couldn't easily
do that.. But on second thought, you're right, maybe I should have
cached a DOM tree.. since it would have a much better guarantees for
replaying.
But on most cases, this component works pretty darn good, and we love it.
Of course trying to do evict cache on particular events is hard.. but if
you are alright with "updates within 30hr" sort of cases. this is a good
start.
Howard Lewis Ship wrote:
> I'm generally against these approached.
>
> Cache the data, make it fast to access.
>
> Let Tapestry do a full render every time.
>
> You'll end up with confusing, unforseen consequences.
>
> Rendering is increasingly a complex dance between components. That's
> the power and the penalty of Tapestry. Components inside that cached
> zone are not just rendering a character stream, they are generating
> JavaScript, assigning unique ids (via PageRenderSupport) interacting
> with an enclosing Form components, and doing other user-specific
> things.
>
> I would always look elsewhere first for places that need optimization,
> and I'd start with database access and queries.
>
> On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
>> We have a component that we call "Buffer" :) it takes a timeout,
>> optional cachekey, and optional lastmodified (to tell you)
>>
>> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
>> liberate it.. you would just have to change the cache hooks to use
>> whatever cache you want to use...
>>
>> The easiest way to add caching to the app. :)
>>
>>
>>
>> Martin Kersten wrote:
>> > @Chached is only used during a single page rendering cycle. It would not
>> > apply to your situation. (as far as I know)
>> >
>> > Source:
>> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>> >
>> > Your scenario would be implementable using your own component.
>> > The component would represent a fragment and read the file (even
>> > use a inmemory cache strategy (soft/weakreferences)) and write
>> > the ouput directly to stream (or actually the dom tree of your
>> > document being returned).
>> >
>> > Using your own solution enables you to mimic the behavior you talk about.
>> > Another idea would to write / cache only datas needed to render the tables
>> > (e.g. cache only content not markup). Never the less I am in doupt,
>> > if such a solution is necessary (dynamically cache results of
>> > database queries in memory or on disk).
>> >
>> > So after all you might want to port your application. As always use
>> > the simpliest solution first. So database queries without any caches.
>> > Once you see any problems (performance is below required) just go for
>> > optimization. Since you have a fallback solution at hand (cron-jobs +
>> > disk fragments) you are at the safe side. But I am in doupt if you
>> > really need the markup being cached. Caching the database results
>> > and recreate markup sounds more reasonable. You might save you lots
>> > of seeking time.
>> >
>> > But you always know: Only the code / application will tell you!
>> >
>> >
>> > Cheers,
>> >
>> > Martin (Kersten)
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
>> > Gesendet: Dienstag, 18. März 2008 17:45
>> > An: Tapestry users
>> > Betreff: @Cached and caching in general
>> >
>> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
>> >
>> > Or is this a pure memory-based cache?
>> >
>> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
>> >
>> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
>> >
>> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
>> >
>> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
>> >
>> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
>> >
>> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>>
>> ---------------------------------------------------------------------
>> 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: AW: @Cached and caching in general
Posted by Andreas Andreou <an...@gmail.com>.
Well, i believe if someone is aware of these issues, there's nothing
wrong with using
this solution - I've had some cases where data access is fast but data
processing
(in order to present) was quite complex, so this really helped.
For reference, another not-yet-mentioned problem of this kind of cache
is the jsessionid
parameter that may be cached in url (though we / many people
completely remove them
nowadays)
On Wed, Mar 19, 2008 at 1:55 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm generally against these approached.
>
> Cache the data, make it fast to access.
>
> Let Tapestry do a full render every time.
>
> You'll end up with confusing, unforseen consequences.
>
> Rendering is increasingly a complex dance between components. That's
> the power and the penalty of Tapestry. Components inside that cached
> zone are not just rendering a character stream, they are generating
> JavaScript, assigning unique ids (via PageRenderSupport) interacting
> with an enclosing Form components, and doing other user-specific
> things.
>
> I would always look elsewhere first for places that need optimization,
> and I'd start with database access and queries.
>
>
>
> On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> > We have a component that we call "Buffer" :) it takes a timeout,
> > optional cachekey, and optional lastmodified (to tell you)
> >
> > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> > liberate it.. you would just have to change the cache hooks to use
> > whatever cache you want to use...
> >
> > The easiest way to add caching to the app. :)
> >
> >
> >
> > Martin Kersten wrote:
> > > @Chached is only used during a single page rendering cycle. It would not
> > > apply to your situation. (as far as I know)
> > >
> > > Source:
> > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> > >
> > > Your scenario would be implementable using your own component.
> > > The component would represent a fragment and read the file (even
> > > use a inmemory cache strategy (soft/weakreferences)) and write
> > > the ouput directly to stream (or actually the dom tree of your
> > > document being returned).
> > >
> > > Using your own solution enables you to mimic the behavior you talk about.
> > > Another idea would to write / cache only datas needed to render the tables
> > > (e.g. cache only content not markup). Never the less I am in doupt,
> > > if such a solution is necessary (dynamically cache results of
> > > database queries in memory or on disk).
> > >
> > > So after all you might want to port your application. As always use
> > > the simpliest solution first. So database queries without any caches.
> > > Once you see any problems (performance is below required) just go for
> > > optimization. Since you have a fallback solution at hand (cron-jobs +
> > > disk fragments) you are at the safe side. But I am in doupt if you
> > > really need the markup being cached. Caching the database results
> > > and recreate markup sounds more reasonable. You might save you lots
> > > of seeking time.
> > >
> > > But you always know: Only the code / application will tell you!
> > >
> > >
> > > Cheers,
> > >
> > > Martin (Kersten)
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> > > Gesendet: Dienstag, 18. März 2008 17:45
> > > An: Tapestry users
> > > Betreff: @Cached and caching in general
> > >
> > > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> > >
> > > Or is this a pure memory-based cache?
> > >
> > > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> > >
> > > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> > >
> > > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> > >
> > > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> > >
> > > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> > >
> > > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm generally against these approached.
Cache the data, make it fast to access.
Let Tapestry do a full render every time.
You'll end up with confusing, unforseen consequences.
Rendering is increasingly a complex dance between components. That's
the power and the penalty of Tapestry. Components inside that cached
zone are not just rendering a character stream, they are generating
JavaScript, assigning unique ids (via PageRenderSupport) interacting
with an enclosing Form components, and doing other user-specific
things.
I would always look elsewhere first for places that need optimization,
and I'd start with database access and queries.
On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> We have a component that we call "Buffer" :) it takes a timeout,
> optional cachekey, and optional lastmodified (to tell you)
>
> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
> liberate it.. you would just have to change the cache hooks to use
> whatever cache you want to use...
>
> The easiest way to add caching to the app. :)
>
>
>
> Martin Kersten wrote:
> > @Chached is only used during a single page rendering cycle. It would not
> > apply to your situation. (as far as I know)
> >
> > Source:
> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >
> > Your scenario would be implementable using your own component.
> > The component would represent a fragment and read the file (even
> > use a inmemory cache strategy (soft/weakreferences)) and write
> > the ouput directly to stream (or actually the dom tree of your
> > document being returned).
> >
> > Using your own solution enables you to mimic the behavior you talk about.
> > Another idea would to write / cache only datas needed to render the tables
> > (e.g. cache only content not markup). Never the less I am in doupt,
> > if such a solution is necessary (dynamically cache results of
> > database queries in memory or on disk).
> >
> > So after all you might want to port your application. As always use
> > the simpliest solution first. So database queries without any caches.
> > Once you see any problems (performance is below required) just go for
> > optimization. Since you have a fallback solution at hand (cron-jobs +
> > disk fragments) you are at the safe side. But I am in doupt if you
> > really need the markup being cached. Caching the database results
> > and recreate markup sounds more reasonable. You might save you lots
> > of seeking time.
> >
> > But you always know: Only the code / application will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tobias Marx [mailto:tmarx78@gmx.de]
> > Gesendet: Dienstag, 18. März 2008 17:45
> > An: Tapestry users
> > Betreff: @Cached and caching in general
> >
> > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by Fernando Padilla <fe...@alum.mit.edu>.
We have a component that we call "Buffer" :) it takes a timeout,
optional cachekey, and optional lastmodified (to tell you)
We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
liberate it.. you would just have to change the cache hooks to use
whatever cache you want to use...
The easiest way to add caching to the app. :)
Martin Kersten wrote:
> @Chached is only used during a single page rendering cycle. It would not
> apply to your situation. (as far as I know)
>
> Source:
> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>
> Your scenario would be implementable using your own component.
> The component would represent a fragment and read the file (even
> use a inmemory cache strategy (soft/weakreferences)) and write
> the ouput directly to stream (or actually the dom tree of your
> document being returned).
>
> Using your own solution enables you to mimic the behavior you talk about.
> Another idea would to write / cache only datas needed to render the tables
> (e.g. cache only content not markup). Never the less I am in doupt,
> if such a solution is necessary (dynamically cache results of
> database queries in memory or on disk).
>
> So after all you might want to port your application. As always use
> the simpliest solution first. So database queries without any caches.
> Once you see any problems (performance is below required) just go for
> optimization. Since you have a fallback solution at hand (cron-jobs +
> disk fragments) you are at the safe side. But I am in doupt if you
> really need the markup being cached. Caching the database results
> and recreate markup sounds more reasonable. You might save you lots
> of seeking time.
>
> But you always know: Only the code / application will tell you!
>
>
> Cheers,
>
> Martin (Kersten)
>
> -----Ursprüngliche Nachricht-----
> Von: Tobias Marx [mailto:tmarx78@gmx.de]
> Gesendet: Dienstag, 18. März 2008 17:45
> An: Tapestry users
> Betreff: @Cached and caching in general
>
> I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
>
> Or is this a pure memory-based cache?
>
> I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
>
> It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
>
> Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
>
> So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
>
> Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
>
> But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
Tobias is right to ask about his,
I'm usin php for a long time now and output_buffer functions "ob_*"
are great for simplifying complex pages, adding caching without interferring
with internal code....
people have asked about getting html output of page and etc.
if framework would allow access to markup on afterRenderTemplate
and if markup could be forced to serialize all HTML of the current element
it would allow creating a simple component that can wrap a part of
(processor heavy) code and catch the rendered markup. Then it would
allow it self to be rendered normaly only in some intervals and produce
cached raw output otherwise.
this would be very similar to output_buffer tricks in php.
Davor Hrg
On Tue, Mar 18, 2008 at 6:25 PM, Filip S. Adamsen <fs...@fsadev.com> wrote:
> That's a special case, really. Do what you want.
>
> -Filip
>
>
>
> On 2008-03-18 18:20, Tobias Marx wrote:
> > Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables).
> >
> > -------- Original-Nachricht --------
> >> Datum: Tue, 18 Mar 2008 18:14:28 +0100
> >> Von: "Filip S. Adamsen" <fs...@fsadev.com>
> >> An: Tapestry users <us...@tapestry.apache.org>
> >> Betreff: Re: AW: @Cached and caching in general
> >
> >> A factor 100?? C'mon. If, and I stress IF, your application would
> >> benefit that much from this, fine. But Tapestry 5 applications in
> >> general would - I guarantee you - not see such an improvement.
> >>
> >> -Filip
> >>
> >> On 2008-03-18 18:07, Tobias Marx wrote:
> >>> My theory is that such a disk-caching behaviour could speed up Tapestry
> >> applications by factor 100....although Tapestry 5 is quite fast.
> >>> The template parsing is still quite slow because it uses Velocity and
> >> everything that avoids template parsing would increase the speed a lot.
> >>>
> >>> -------- Original-Nachricht --------
> >>>> Datum: Tue, 18 Mar 2008 18:01:40 +0100
> >>>> Von: "Martin Kersten" <Ma...@mercateo.com>
> >>>> An: "Tapestry users" <us...@tapestry.apache.org>
> >>>> Betreff: AW: @Cached and caching in general
> >>>> @Chached is only used during a single page rendering cycle. It would
> >> not
> >>>> apply to your situation. (as far as I know)
> >>>>
> >>>> Source:
> >>>> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >>>>
> >>>> Your scenario would be implementable using your own component.
> >>>> The component would represent a fragment and read the file (even
> >>>> use a inmemory cache strategy (soft/weakreferences)) and write
> >>>> the ouput directly to stream (or actually the dom tree of your
> >>>> document being returned).
> >>>>
> >>>> Using your own solution enables you to mimic the behavior you talk
> >> about.
> >>>> Another idea would to write / cache only datas needed to render the
> >> tables
> >>>> (e.g. cache only content not markup). Never the less I am in doupt,
> >>>> if such a solution is necessary (dynamically cache results of
> >>>> database queries in memory or on disk).
> >>>>
> >>>> So after all you might want to port your application. As always use
> >>>> the simpliest solution first. So database queries without any caches.
> >>>> Once you see any problems (performance is below required) just go for
> >>>> optimization. Since you have a fallback solution at hand (cron-jobs +
> >>>> disk fragments) you are at the safe side. But I am in doupt if you
> >>>> really need the markup being cached. Caching the database results
> >>>> and recreate markup sounds more reasonable. You might save you lots
> >>>> of seeking time.
> >>>>
> >>>> But you always know: Only the code / application will tell you!
> >>>>
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Martin (Kersten)
> >>>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Tobias Marx [mailto:tmarx78@gmx.de]
> >>>> Gesendet: Dienstag, 18. März 2008 17:45
> >>>> An: Tapestry users
> >>>> Betreff: @Cached and caching in general
> >>>>
> >>>> I have not used T5 yet, but would @Cached use the file system for
> >> caching
> >>>> HTML fragments similiar to caching mechanisms in some php frameworks?
> >>>>
> >>>> Or is this a pure memory-based cache?
> >>>>
> >>>> I am thinking about migrating an old PHP application to T5 - it has
> >> really
> >>>> a lot of traffic and any users are logged in at the same time.
> >>>>
> >>>> It is quite a low-level application that is still quite fast due to
> >> cron
> >>>> jobs in the background that generate HTML fragments that are included
> >> to
> >>>> reduce the database-query bottleneck (e.g. grouping/ordering and
> >> sorting of
> >>>> huge tables).
> >>>>
> >>>> Somehow I don't trust Hibernate for high-performance database queries
> >> on
> >>>> huge tables .... as I think if tables are huge and many people access
> >> it, it
> >>>> will always lead to problems...no matter how good the queries are and
> >> how
> >>>> well you have splitted the data across several tables.
> >>>>
> >>>> So I think the best solution is always to generate HTML fragments in
> >> the
> >>>> background that take a long time and simple "include" them....this is
> >> even
> >>>> quicker then parsing templates when the data is cached. So you save the
> >> time
> >>>> necessary for querying the database plus the time necessary for
> >> processing
> >>>> the templates that are involved.
> >>>>
> >>>> Currently the setup on this application uses one-way database
> >> replication
> >>>> and the cron jobs access the the huge data table on the replicated
> >> database
> >>>> and generate those HTML fragments without disturbing the
> >> web-applications
> >>>> performance. So the main application simply includes those HTML
> >> fragments
> >>>> within milliseconds.
> >>>>
> >>>> But maybe the T5 caching mechanism would make all of those low-level
> >>>> tricks redundant?
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
That's a special case, really. Do what you want.
-Filip
On 2008-03-18 18:20, Tobias Marx wrote:
> Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables).
>
> -------- Original-Nachricht --------
>> Datum: Tue, 18 Mar 2008 18:14:28 +0100
>> Von: "Filip S. Adamsen" <fs...@fsadev.com>
>> An: Tapestry users <us...@tapestry.apache.org>
>> Betreff: Re: AW: @Cached and caching in general
>
>> A factor 100?? C'mon. If, and I stress IF, your application would
>> benefit that much from this, fine. But Tapestry 5 applications in
>> general would - I guarantee you - not see such an improvement.
>>
>> -Filip
>>
>> On 2008-03-18 18:07, Tobias Marx wrote:
>>> My theory is that such a disk-caching behaviour could speed up Tapestry
>> applications by factor 100....although Tapestry 5 is quite fast.
>>> The template parsing is still quite slow because it uses Velocity and
>> everything that avoids template parsing would increase the speed a lot.
>>>
>>> -------- Original-Nachricht --------
>>>> Datum: Tue, 18 Mar 2008 18:01:40 +0100
>>>> Von: "Martin Kersten" <Ma...@mercateo.com>
>>>> An: "Tapestry users" <us...@tapestry.apache.org>
>>>> Betreff: AW: @Cached and caching in general
>>>> @Chached is only used during a single page rendering cycle. It would
>> not
>>>> apply to your situation. (as far as I know)
>>>>
>>>> Source:
>>>> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>>>>
>>>> Your scenario would be implementable using your own component.
>>>> The component would represent a fragment and read the file (even
>>>> use a inmemory cache strategy (soft/weakreferences)) and write
>>>> the ouput directly to stream (or actually the dom tree of your
>>>> document being returned).
>>>>
>>>> Using your own solution enables you to mimic the behavior you talk
>> about.
>>>> Another idea would to write / cache only datas needed to render the
>> tables
>>>> (e.g. cache only content not markup). Never the less I am in doupt,
>>>> if such a solution is necessary (dynamically cache results of
>>>> database queries in memory or on disk).
>>>>
>>>> So after all you might want to port your application. As always use
>>>> the simpliest solution first. So database queries without any caches.
>>>> Once you see any problems (performance is below required) just go for
>>>> optimization. Since you have a fallback solution at hand (cron-jobs +
>>>> disk fragments) you are at the safe side. But I am in doupt if you
>>>> really need the markup being cached. Caching the database results
>>>> and recreate markup sounds more reasonable. You might save you lots
>>>> of seeking time.
>>>>
>>>> But you always know: Only the code / application will tell you!
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Martin (Kersten)
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Tobias Marx [mailto:tmarx78@gmx.de]
>>>> Gesendet: Dienstag, 18. März 2008 17:45
>>>> An: Tapestry users
>>>> Betreff: @Cached and caching in general
>>>>
>>>> I have not used T5 yet, but would @Cached use the file system for
>> caching
>>>> HTML fragments similiar to caching mechanisms in some php frameworks?
>>>>
>>>> Or is this a pure memory-based cache?
>>>>
>>>> I am thinking about migrating an old PHP application to T5 - it has
>> really
>>>> a lot of traffic and any users are logged in at the same time.
>>>>
>>>> It is quite a low-level application that is still quite fast due to
>> cron
>>>> jobs in the background that generate HTML fragments that are included
>> to
>>>> reduce the database-query bottleneck (e.g. grouping/ordering and
>> sorting of
>>>> huge tables).
>>>>
>>>> Somehow I don't trust Hibernate for high-performance database queries
>> on
>>>> huge tables .... as I think if tables are huge and many people access
>> it, it
>>>> will always lead to problems...no matter how good the queries are and
>> how
>>>> well you have splitted the data across several tables.
>>>>
>>>> So I think the best solution is always to generate HTML fragments in
>> the
>>>> background that take a long time and simple "include" them....this is
>> even
>>>> quicker then parsing templates when the data is cached. So you save the
>> time
>>>> necessary for querying the database plus the time necessary for
>> processing
>>>> the templates that are involved.
>>>>
>>>> Currently the setup on this application uses one-way database
>> replication
>>>> and the cron jobs access the the huge data table on the replicated
>> database
>>>> and generate those HTML fragments without disturbing the
>> web-applications
>>>> performance. So the main application simply includes those HTML
>> fragments
>>>> within milliseconds.
>>>>
>>>> But maybe the T5 caching mechanism would make all of those low-level
>>>> tricks redundant?
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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: AW: @Cached and caching in general
Posted by Tobias Marx <tm...@gmx.de>.
Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables).
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 18:14:28 +0100
> Von: "Filip S. Adamsen" <fs...@fsadev.com>
> An: Tapestry users <us...@tapestry.apache.org>
> Betreff: Re: AW: @Cached and caching in general
> A factor 100?? C'mon. If, and I stress IF, your application would
> benefit that much from this, fine. But Tapestry 5 applications in
> general would - I guarantee you - not see such an improvement.
>
> -Filip
>
> On 2008-03-18 18:07, Tobias Marx wrote:
> > My theory is that such a disk-caching behaviour could speed up Tapestry
> applications by factor 100....although Tapestry 5 is quite fast.
> >
> > The template parsing is still quite slow because it uses Velocity and
> everything that avoids template parsing would increase the speed a lot.
> >
> >
> > -------- Original-Nachricht --------
> >> Datum: Tue, 18 Mar 2008 18:01:40 +0100
> >> Von: "Martin Kersten" <Ma...@mercateo.com>
> >> An: "Tapestry users" <us...@tapestry.apache.org>
> >> Betreff: AW: @Cached and caching in general
> >
> >> @Chached is only used during a single page rendering cycle. It would
> not
> >> apply to your situation. (as far as I know)
> >>
> >> Source:
> >> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
> >>
> >> Your scenario would be implementable using your own component.
> >> The component would represent a fragment and read the file (even
> >> use a inmemory cache strategy (soft/weakreferences)) and write
> >> the ouput directly to stream (or actually the dom tree of your
> >> document being returned).
> >>
> >> Using your own solution enables you to mimic the behavior you talk
> about.
> >> Another idea would to write / cache only datas needed to render the
> tables
> >> (e.g. cache only content not markup). Never the less I am in doupt,
> >> if such a solution is necessary (dynamically cache results of
> >> database queries in memory or on disk).
> >>
> >> So after all you might want to port your application. As always use
> >> the simpliest solution first. So database queries without any caches.
> >> Once you see any problems (performance is below required) just go for
> >> optimization. Since you have a fallback solution at hand (cron-jobs +
> >> disk fragments) you are at the safe side. But I am in doupt if you
> >> really need the markup being cached. Caching the database results
> >> and recreate markup sounds more reasonable. You might save you lots
> >> of seeking time.
> >>
> >> But you always know: Only the code / application will tell you!
> >>
> >>
> >> Cheers,
> >>
> >> Martin (Kersten)
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Tobias Marx [mailto:tmarx78@gmx.de]
> >> Gesendet: Dienstag, 18. März 2008 17:45
> >> An: Tapestry users
> >> Betreff: @Cached and caching in general
> >>
> >> I have not used T5 yet, but would @Cached use the file system for
> caching
> >> HTML fragments similiar to caching mechanisms in some php frameworks?
> >>
> >> Or is this a pure memory-based cache?
> >>
> >> I am thinking about migrating an old PHP application to T5 - it has
> really
> >> a lot of traffic and any users are logged in at the same time.
> >>
> >> It is quite a low-level application that is still quite fast due to
> cron
> >> jobs in the background that generate HTML fragments that are included
> to
> >> reduce the database-query bottleneck (e.g. grouping/ordering and
> sorting of
> >> huge tables).
> >>
> >> Somehow I don't trust Hibernate for high-performance database queries
> on
> >> huge tables .... as I think if tables are huge and many people access
> it, it
> >> will always lead to problems...no matter how good the queries are and
> how
> >> well you have splitted the data across several tables.
> >>
> >> So I think the best solution is always to generate HTML fragments in
> the
> >> background that take a long time and simple "include" them....this is
> even
> >> quicker then parsing templates when the data is cached. So you save the
> time
> >> necessary for querying the database plus the time necessary for
> processing
> >> the templates that are involved.
> >>
> >> Currently the setup on this application uses one-way database
> replication
> >> and the cron jobs access the the huge data table on the replicated
> database
> >> and generate those HTML fragments without disturbing the
> web-applications
> >> performance. So the main application simply includes those HTML
> fragments
> >> within milliseconds.
> >>
> >> But maybe the T5 caching mechanism would make all of those low-level
> >> tricks redundant?
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: @Cached and caching in general
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
A factor 100?? C'mon. If, and I stress IF, your application would
benefit that much from this, fine. But Tapestry 5 applications in
general would - I guarantee you - not see such an improvement.
-Filip
On 2008-03-18 18:07, Tobias Marx wrote:
> My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100....although Tapestry 5 is quite fast.
>
> The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot.
>
>
> -------- Original-Nachricht --------
>> Datum: Tue, 18 Mar 2008 18:01:40 +0100
>> Von: "Martin Kersten" <Ma...@mercateo.com>
>> An: "Tapestry users" <us...@tapestry.apache.org>
>> Betreff: AW: @Cached and caching in general
>
>> @Chached is only used during a single page rendering cycle. It would not
>> apply to your situation. (as far as I know)
>>
>> Source:
>> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>>
>> Your scenario would be implementable using your own component.
>> The component would represent a fragment and read the file (even
>> use a inmemory cache strategy (soft/weakreferences)) and write
>> the ouput directly to stream (or actually the dom tree of your
>> document being returned).
>>
>> Using your own solution enables you to mimic the behavior you talk about.
>> Another idea would to write / cache only datas needed to render the tables
>> (e.g. cache only content not markup). Never the less I am in doupt,
>> if such a solution is necessary (dynamically cache results of
>> database queries in memory or on disk).
>>
>> So after all you might want to port your application. As always use
>> the simpliest solution first. So database queries without any caches.
>> Once you see any problems (performance is below required) just go for
>> optimization. Since you have a fallback solution at hand (cron-jobs +
>> disk fragments) you are at the safe side. But I am in doupt if you
>> really need the markup being cached. Caching the database results
>> and recreate markup sounds more reasonable. You might save you lots
>> of seeking time.
>>
>> But you always know: Only the code / application will tell you!
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Tobias Marx [mailto:tmarx78@gmx.de]
>> Gesendet: Dienstag, 18. März 2008 17:45
>> An: Tapestry users
>> Betreff: @Cached and caching in general
>>
>> I have not used T5 yet, but would @Cached use the file system for caching
>> HTML fragments similiar to caching mechanisms in some php frameworks?
>>
>> Or is this a pure memory-based cache?
>>
>> I am thinking about migrating an old PHP application to T5 - it has really
>> a lot of traffic and any users are logged in at the same time.
>>
>> It is quite a low-level application that is still quite fast due to cron
>> jobs in the background that generate HTML fragments that are included to
>> reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
>> huge tables).
>>
>> Somehow I don't trust Hibernate for high-performance database queries on
>> huge tables .... as I think if tables are huge and many people access it, it
>> will always lead to problems...no matter how good the queries are and how
>> well you have splitted the data across several tables.
>>
>> So I think the best solution is always to generate HTML fragments in the
>> background that take a long time and simple "include" them....this is even
>> quicker then parsing templates when the data is cached. So you save the time
>> necessary for querying the database plus the time necessary for processing
>> the templates that are involved.
>>
>> Currently the setup on this application uses one-way database replication
>> and the cron jobs access the the huge data table on the replicated database
>> and generate those HTML fragments without disturbing the web-applications
>> performance. So the main application simply includes those HTML fragments
>> within milliseconds.
>>
>> But maybe the T5 caching mechanism would make all of those low-level
>> tricks redundant?
>>
>> ---------------------------------------------------------------------
>> 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
>
> ---------------------------------------------------------------------
> 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
AW: @Cached and caching in general
Posted by Tobias Marx <tm...@gmx.de>.
My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100....although Tapestry 5 is quite fast.
The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot.
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 18:01:40 +0100
> Von: "Martin Kersten" <Ma...@mercateo.com>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: AW: @Cached and caching in general
> @Chached is only used during a single page rendering cycle. It would not
> apply to your situation. (as far as I know)
>
> Source:
> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
>
> Your scenario would be implementable using your own component.
> The component would represent a fragment and read the file (even
> use a inmemory cache strategy (soft/weakreferences)) and write
> the ouput directly to stream (or actually the dom tree of your
> document being returned).
>
> Using your own solution enables you to mimic the behavior you talk about.
> Another idea would to write / cache only datas needed to render the tables
> (e.g. cache only content not markup). Never the less I am in doupt,
> if such a solution is necessary (dynamically cache results of
> database queries in memory or on disk).
>
> So after all you might want to port your application. As always use
> the simpliest solution first. So database queries without any caches.
> Once you see any problems (performance is below required) just go for
> optimization. Since you have a fallback solution at hand (cron-jobs +
> disk fragments) you are at the safe side. But I am in doupt if you
> really need the markup being cached. Caching the database results
> and recreate markup sounds more reasonable. You might save you lots
> of seeking time.
>
> But you always know: Only the code / application will tell you!
>
>
> Cheers,
>
> Martin (Kersten)
>
> -----Ursprüngliche Nachricht-----
> Von: Tobias Marx [mailto:tmarx78@gmx.de]
> Gesendet: Dienstag, 18. März 2008 17:45
> An: Tapestry users
> Betreff: @Cached and caching in general
>
> I have not used T5 yet, but would @Cached use the file system for caching
> HTML fragments similiar to caching mechanisms in some php frameworks?
>
> Or is this a pure memory-based cache?
>
> I am thinking about migrating an old PHP application to T5 - it has really
> a lot of traffic and any users are logged in at the same time.
>
> It is quite a low-level application that is still quite fast due to cron
> jobs in the background that generate HTML fragments that are included to
> reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
> huge tables).
>
> Somehow I don't trust Hibernate for high-performance database queries on
> huge tables .... as I think if tables are huge and many people access it, it
> will always lead to problems...no matter how good the queries are and how
> well you have splitted the data across several tables.
>
> So I think the best solution is always to generate HTML fragments in the
> background that take a long time and simple "include" them....this is even
> quicker then parsing templates when the data is cached. So you save the time
> necessary for querying the database plus the time necessary for processing
> the templates that are involved.
>
> Currently the setup on this application uses one-way database replication
> and the cron jobs access the the huge data table on the replicated database
> and generate those HTML fragments without disturbing the web-applications
> performance. So the main application simply includes those HTML fragments
> within milliseconds.
>
> But maybe the T5 caching mechanism would make all of those low-level
> tricks redundant?
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: @Cached and caching in general
Posted by Martin Kersten <Ma...@mercateo.com>.
@Chached is only used during a single page rendering cycle. It would not
apply to your situation. (as far as I know)
Source:
http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
Your scenario would be implementable using your own component.
The component would represent a fragment and read the file (even
use a inmemory cache strategy (soft/weakreferences)) and write
the ouput directly to stream (or actually the dom tree of your
document being returned).
Using your own solution enables you to mimic the behavior you talk about.
Another idea would to write / cache only datas needed to render the tables
(e.g. cache only content not markup). Never the less I am in doupt,
if such a solution is necessary (dynamically cache results of
database queries in memory or on disk).
So after all you might want to port your application. As always use
the simpliest solution first. So database queries without any caches.
Once you see any problems (performance is below required) just go for
optimization. Since you have a fallback solution at hand (cron-jobs +
disk fragments) you are at the safe side. But I am in doupt if you
really need the markup being cached. Caching the database results
and recreate markup sounds more reasonable. You might save you lots
of seeking time.
But you always know: Only the code / application will tell you!
Cheers,
Martin (Kersten)
-----Ursprüngliche Nachricht-----
Von: Tobias Marx [mailto:tmarx78@gmx.de]
Gesendet: Dienstag, 18. März 2008 17:45
An: Tapestry users
Betreff: @Cached and caching in general
I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
Or is this a pure memory-based cache?
I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
---------------------------------------------------------------------
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: @Cached and caching in general
Posted by Jonathan Barker <jo...@gmail.com>.
Hibernate makes it easy to do some really interesting things without a great
deal of thought.
Any time you start working with large data sets you have to think carefully
about what Hibernate is doing on your behalf - like the inner loop example.
For some reporting tasks, you might want to use Hibernate to generate a
recordset from raw SQL. For other cases, changing a fetch strategy from
LAZY to EAGER will address the performance issues.
A substitute for your existing caching, depending on memory requirements,
might be to implement a results-cache as a service within your Tapestry app.
Mimic what is done currently, but perhaps schedule refreshes with Quartz and
keep it within the same app.
Jonathan
> -----Original Message-----
> From: Tobias Marx [mailto:munich@fantasymail.de]
> Sent: Tuesday, March 18, 2008 1:35 PM
> To: Tapestry users
> Subject: AW: @Cached and caching in general
>
> I had the idea while looking at this benchmark here:
>
> http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-
> DynCont/html/throughput.gif
>
> I am currently trying out Resin as it allows to use PHP and Servlets at
> the same time - so you can mix old PHP code with Tapestry on a single
> webserver and replace parts of the web application with PHP or Tapestry
> depending on whats faster in a certain situation.
>
> A typical example I have problems with in Tapestry/Hibernate is the
> following:
>
> - a table that displays an object
> - buttons or additional components on the table cells that depend on other
> objects
>
> In this case you have several database queries....one for the outer loop
> and one for the inner loops.
>
> In theory you could define a virtual new object in Hibernate that does
> some joins or unions that will result in just one query in the outer
> loop...and then it works quite fast.
>
> I like Hibernate as long as you can use your objects directly...but using
> Hibernate for joins and unions is not much fun....
>
> So such a table would benefit a lot if is was cached...even if the
> individual queries would be cached you still had to do all the loops and
> parsing of the templates.
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 18 Mar 2008 18:22:01 +0100
> > Von: "Martin Kersten" <Ma...@mercateo.com>
> > An: "Tapestry users" <us...@tapestry.apache.org>
> > Betreff: AW: @Cached and caching in general
>
> > You might want to know what tapestry does with your templates.
> > Tapestry reads your template and parses it - only once it changes!
> > So generating two pages (even with different content) just results
> > in using a parsed, preprocessed in memory representation of your
> > template. So tapestry strictly avoids disk-access and parsing
> > in production (when processing all templates on startup is
> > enabled).
> >
> > So there is no need for the older cache it hack. As I mentioned
> > it is easy to play with your own cache implementation. But be
> > carefull about the components you place inside your cache. You
> > know context and event handling. But for displaying 'cached' content
> > it might be an option.
> >
> > If you go ahead and try it you may post your benchmarks. I don't
> > know who has stretched it before but I guess caching is always a
> > hot topic so if you can provide new insides your are welcome.
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tobias Marx [mailto:munich@fantasymail.de]
> > Gesendet: Dienstag, 18. März 2008 18:15
> > An: Tapestry users
> > Betreff: AW: @Cached and caching in general
> >
> > > The problem is context I guess. Usally your component depends on lots
> > > of stuff. Parameters, URL, Services, Page-state, component state,
> > > HTTP-Parameters and so on.
> >
> > Yes...but it must be possible somehow as some PHP template engines also
> do
> > it. Isn't there already some mechanism in the internals of Tapestry that
> > keeps track of that even now?
> >
> > ---------------------------------------------------------------------
> > 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
>
> ---------------------------------------------------------------------
> 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
AW: @Cached and caching in general
Posted by Tobias Marx <mu...@fantasymail.de>.
I had the idea while looking at this benchmark here:
http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/throughput.gif
I am currently trying out Resin as it allows to use PHP and Servlets at the same time - so you can mix old PHP code with Tapestry on a single webserver and replace parts of the web application with PHP or Tapestry depending on whats faster in a certain situation.
A typical example I have problems with in Tapestry/Hibernate is the following:
- a table that displays an object
- buttons or additional components on the table cells that depend on other objects
In this case you have several database queries....one for the outer loop and one for the inner loops.
In theory you could define a virtual new object in Hibernate that does some joins or unions that will result in just one query in the outer loop...and then it works quite fast.
I like Hibernate as long as you can use your objects directly...but using Hibernate for joins and unions is not much fun....
So such a table would benefit a lot if is was cached...even if the individual queries would be cached you still had to do all the loops and parsing of the templates.
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 18:22:01 +0100
> Von: "Martin Kersten" <Ma...@mercateo.com>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: AW: @Cached and caching in general
> You might want to know what tapestry does with your templates.
> Tapestry reads your template and parses it - only once it changes!
> So generating two pages (even with different content) just results
> in using a parsed, preprocessed in memory representation of your
> template. So tapestry strictly avoids disk-access and parsing
> in production (when processing all templates on startup is
> enabled).
>
> So there is no need for the older cache it hack. As I mentioned
> it is easy to play with your own cache implementation. But be
> carefull about the components you place inside your cache. You
> know context and event handling. But for displaying 'cached' content
> it might be an option.
>
> If you go ahead and try it you may post your benchmarks. I don't
> know who has stretched it before but I guess caching is always a
> hot topic so if you can provide new insides your are welcome.
>
>
> Cheers,
>
> Martin (Kersten)
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tobias Marx [mailto:munich@fantasymail.de]
> Gesendet: Dienstag, 18. März 2008 18:15
> An: Tapestry users
> Betreff: AW: @Cached and caching in general
>
> > The problem is context I guess. Usally your component depends on lots
> > of stuff. Parameters, URL, Services, Page-state, component state,
> > HTTP-Parameters and so on.
>
> Yes...but it must be possible somehow as some PHP template engines also do
> it. Isn't there already some mechanism in the internals of Tapestry that
> keeps track of that even now?
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: @Cached and caching in general
Posted by Martin Kersten <Ma...@mercateo.com>.
You might want to know what tapestry does with your templates.
Tapestry reads your template and parses it - only once it changes!
So generating two pages (even with different content) just results
in using a parsed, preprocessed in memory representation of your
template. So tapestry strictly avoids disk-access and parsing
in production (when processing all templates on startup is
enabled).
So there is no need for the older cache it hack. As I mentioned
it is easy to play with your own cache implementation. But be
carefull about the components you place inside your cache. You
know context and event handling. But for displaying 'cached' content
it might be an option.
If you go ahead and try it you may post your benchmarks. I don't
know who has stretched it before but I guess caching is always a
hot topic so if you can provide new insides your are welcome.
Cheers,
Martin (Kersten)
-----Ursprüngliche Nachricht-----
Von: Tobias Marx [mailto:munich@fantasymail.de]
Gesendet: Dienstag, 18. März 2008 18:15
An: Tapestry users
Betreff: AW: @Cached and caching in general
> The problem is context I guess. Usally your component depends on lots
> of stuff. Parameters, URL, Services, Page-state, component state,
> HTTP-Parameters and so on.
Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now?
---------------------------------------------------------------------
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
AW: @Cached and caching in general
Posted by Tobias Marx <mu...@fantasymail.de>.
> The problem is context I guess. Usally your component depends on lots
> of stuff. Parameters, URL, Services, Page-state, component state,
> HTTP-Parameters and so on.
Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: @Cached and caching in general
Posted by Martin Kersten <Ma...@mercateo.com>.
The problem is context I guess. Usally your component depends on lots
of stuff. Parameters, URL, Services, Page-state, component state,
HTTP-Parameters and so on. Providing such a low-level cache might
sound reasonable but remembering my own requirements lots of days back
(2001) the cache depended on a flag system being triggered by distributed
actions.
If you need your own cache (being driven that way) you might want to
create your own component (check out the rendering pipe)
<t:cached timeout="360">
<p>My Content to cache</p>
</t:cached>
Please report your findings. But I am in doupt such a general caching
service is needed. But as far as I know Tapestry and its agility, all
you need
-----Ursprüngliche Nachricht-----
Von: Tobias Marx [mailto:tmarx78@gmx.de]
Gesendet: Dienstag, 18. März 2008 17:58
An: Tapestry users
Betreff: Re: @Cached and caching in general
Ok. Thanks...this is what I wanted to know.
What about an annotation for "components"/"pages ?
@CachedOutput (time=3600)
In this case a "component" or "page" would not render itself every time but cache its output to the filesystem (a cache directory).
Every hour it would re-generate/refresh its output and this way save lots of performance.....
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 17:52:11 +0100
> Von: "Davor Hrg" <hr...@gmail.com>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: Re: @Cached and caching in general
> @Cached is an annotation
> that caches method call result per request.
> so while page is rendering if multiple pieces of template require that
> property it gets called only once...
>
> Davor Hrg
>
> On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <tm...@gmx.de> wrote:
> > I have not used T5 yet, but would @Cached use the file system for
> caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has
> really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to
> cron jobs in the background that generate HTML fragments that are
> included to reduce the database-query bottleneck (e.g.
> grouping/ordering and sorting of huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database
> > queries
> on huge tables .... as I think if tables are huge and many people
> access it, it will always lead to problems...no matter how good the
> queries are and how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments
> > in
> the background that take a long time and simple "include" them....this
> is even quicker then parsing templates when the data is cached. So you
> save the time necessary for querying the database plus the time
> necessary for processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database
> replication and the cron jobs access the the huge data table on the
> replicated database and generate those HTML fragments without
> disturbing the web-applications performance. So the main application
> simply includes those HTML fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those
> > low-level
> tricks redundant?
> >
> >
> > --------------------------------------------------------------------
> > - 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
---------------------------------------------------------------------
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: @Cached and caching in general
Posted by Tobias Marx <tm...@gmx.de>.
Ok. Thanks...this is what I wanted to know.
What about an annotation for "components"/"pages ?
@CachedOutput (time=3600)
In this case a "component" or "page" would not render itself every time
but cache its output to the filesystem (a cache directory).
Every hour it would re-generate/refresh its output and this way save lots of performance.....
-------- Original-Nachricht --------
> Datum: Tue, 18 Mar 2008 17:52:11 +0100
> Von: "Davor Hrg" <hr...@gmail.com>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: Re: @Cached and caching in general
> @Cached is an annotation
> that caches method call result per request.
> so while page is rendering if multiple pieces of template
> require that property it gets called only once...
>
> Davor Hrg
>
> On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <tm...@gmx.de> wrote:
> > I have not used T5 yet, but would @Cached use the file system for
> caching HTML fragments similiar to caching mechanisms in some php frameworks?
> >
> > Or is this a pure memory-based cache?
> >
> > I am thinking about migrating an old PHP application to T5 - it has
> really a lot of traffic and any users are logged in at the same time.
> >
> > It is quite a low-level application that is still quite fast due to
> cron jobs in the background that generate HTML fragments that are included to
> reduce the database-query bottleneck (e.g. grouping/ordering and sorting of
> huge tables).
> >
> > Somehow I don't trust Hibernate for high-performance database queries
> on huge tables .... as I think if tables are huge and many people access it,
> it will always lead to problems...no matter how good the queries are and
> how well you have splitted the data across several tables.
> >
> > So I think the best solution is always to generate HTML fragments in
> the background that take a long time and simple "include" them....this is
> even quicker then parsing templates when the data is cached. So you save the
> time necessary for querying the database plus the time necessary for
> processing the templates that are involved.
> >
> > Currently the setup on this application uses one-way database
> replication and the cron jobs access the the huge data table on the replicated
> database and generate those HTML fragments without disturbing the
> web-applications performance. So the main application simply includes those HTML
> fragments within milliseconds.
> >
> > But maybe the T5 caching mechanism would make all of those low-level
> tricks redundant?
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Cached and caching in general
Posted by Davor Hrg <hr...@gmail.com>.
@Cached is an annotation
that caches method call result per request.
so while page is rendering if multiple pieces of template
require that property it gets called only once...
Davor Hrg
On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <tm...@gmx.de> wrote:
> I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
>
> Or is this a pure memory-based cache?
>
> I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
>
> It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
>
> Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
>
> So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
>
> Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
>
> But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
>
> ---------------------------------------------------------------------
> 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
@Cached and caching in general
Posted by Tobias Marx <tm...@gmx.de>.
I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks?
Or is this a pure memory-based cache?
I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time.
It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables).
Somehow I don't trust Hibernate for high-performance database queries on huge tables .... as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables.
So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" them....this is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved.
Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds.
But maybe the T5 caching mechanism would make all of those low-level tricks redundant?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry at my company
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
You forgot "YHBT. YHL."
Now GTFO.
-Filip
On 2008-03-18 17:35, Rob Smeets wrote:
> Guys,
>
> I hoped you would rally behind me and offer some ideas to counterfight my
> colleagues. Rather you are calling me names. I am very dissapointed and hope
> you will all one day grow up. I thought the Tapestry community have nice
> people. You have proved to be very arrogant and bad tempered. I hope to be
> the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> others reading this would all drop off Tapestry like flies.
>
> Have a nice day.
>
> Rob
>
> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> andreas.stroeber@siemens.com> wrote:
>
>> I suggest scheme.
>>
>> The more people grow up, the more they behave childish.
>>
>> -----Ursprüngliche Nachricht-----
>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
>>> ensure maximum pain.
>> Plain servlets and JSPs would be even better!
>>
>> ---------------------------------------------------------------------
>> 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: Tapestry at my company
Posted by Adam Zimowski <zi...@gmail.com>.
Your reply serves only one purpose - to make use look bad when this
thread gets indexed by web crawler, and some wanderer stumbles upon it
thinking you're actually real. Well, every body on the Tapestry list
knows you're the only troll here. You're a big, nasty troll whose
purpose is to waste our valuable time and insult us with your
provocative, nonsense questions decorated as legitimate but in reality
just bunch of FUD. So please please, go away and don't waste our time!
On Tue, Mar 18, 2008 at 11:35 AM, Rob Smeets <rb...@gmail.com> wrote:
> Guys,
>
> I hoped you would rally behind me and offer some ideas to counterfight my
> colleagues. Rather you are calling me names. I am very dissapointed and hope
> you will all one day grow up. I thought the Tapestry community have nice
> people. You have proved to be very arrogant and bad tempered. I hope to be
> the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> others reading this would all drop off Tapestry like flies.
>
> Have a nice day.
>
> Rob
>
>
>
> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> andreas.stroeber@siemens.com> wrote:
>
> > I suggest scheme.
> >
> > The more people grow up, the more they behave childish.
> >
> > -----Ursprüngliche Nachricht-----
> > > For trolls such as yourself... I'd suggest you adopt struts 1 to
> > > ensure maximum pain.
> > Plain servlets and JSPs would be even better!
> >
> > ---------------------------------------------------------------------
> > 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: Tapestry at my company
Posted by Howard Lewis Ship <hl...@gmail.com>.
Nope, just ignore him is the best thing. But even I have trouble
practicing what I preach.
On Tue, Mar 18, 2008 at 10:38 AM, Chris Lewis <ch...@bellsouth.net> wrote:
> Actually I have a different perspective, arguably much less mature but
> certainly more practical. Before I knew who this stain was I wrote a
> message that quite directly confronted and disarmed him, and then I
> realized that he is simply impervious. Really, he is. Every week or so a
> new one will pop up, usually ruffling some feathers, generating some
> 'enlightened' responses, and then leading to a few 'ignore the troll'
> messages. They don't work. So I say we take a stand in the name of
> good'ole immaturity and simply insult this guy with the most asinine
> comments we can muster. Not insults generated by your being angry at
> what he said, but simply for the sake of smearing him. This isn't my
> normal character but I found it fun, and it couldn't possibly be any
> less effective than anything else that's been tried. Who knows, maybe
> we'll come up with a few gems that find themselves on http://bash.org/.
>
> So on that note I'm going to grab a beer, write some code, and drink to
> this poor bastard!
>
>
>
> Darío Vasconcelos wrote:
> > The thing that bothers me is,
> >
> > I'm pretty sure that the Wicket community is misrepresented by this little
> > troll, and he's probably laughing every time he checks this mailing list to
> > see what kind of responses happened as a result to his last dull
> > characterization as a genuine Tapestry user.
> >
> > Nevertheless, whoever this guy is, he's assuming that people will feel
> > offended by Wicket's technical superiorities over Tapestry or that, by
> > getting angry responses, people will fly away from Tap. I'm sure world
> > domination is not in Howard's agenda nor in ours, and proliferation of a
> > framework has never been a consequence of nice and gentle mailing lists
> > (think Hibernate, Rails). We all just want to use a tool that helps us build
> > and maintain better sites with less work.
> >
> > So come on, let this guy write his provocations alone in the desert. The
> > list is meant to help us all understanding better the funcionality and
> > possibilities of Tapestry -and of course, help each other-, not to serve as
> > a PR tool. The Tapestry list has always been full of bright and nice people,
> > that take time from their own schedules to help others, not zealots trying
> > to fight some religious war over their framework of choose.
> >
> > Regards,
> >
> > On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis <ch...@bellsouth.net>
> > wrote:
> >
> >
> >> You were wrong. We are both arrogant and hostile, so piss off and be
> >> gone with ya!
> >>
> >> Rob Smeets wrote:
> >>
> >>> Guys,
> >>>
> >>> I hoped you would rally behind me and offer some ideas to counterfight
> >>>
> >> my
> >>
> >>> colleagues. Rather you are calling me names. I am very dissapointed and
> >>>
> >> hope
> >>
> >>> you will all one day grow up. I thought the Tapestry community have nice
> >>> people. You have proved to be very arrogant and bad tempered. I hope to
> >>>
> >> be
> >>
> >>> the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> >>> others reading this would all drop off Tapestry like flies.
> >>>
> >>> Have a nice day.
> >>>
> >>> Rob
> >>>
> >>> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> >>> andreas.stroeber@siemens.com> wrote:
> >>>
> >>>
> >>>
> >>>> I suggest scheme.
> >>>>
> >>>> The more people grow up, the more they behave childish.
> >>>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>>
> >>>>
> >>>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
> >>>>> ensure maximum pain.
> >>>>>
> >>>>>
> >>>> Plain servlets and JSPs would be even better!
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
> >
> >
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry at my company
Posted by Jonathan Barker <jo...@gmail.com>.
A toast to fools!
But for them, the rest of us would not succeed!
> -----Original Message-----
> From: Chris Lewis [mailto:chris_lewis@bellsouth.net]
> Sent: Tuesday, March 18, 2008 1:39 PM
> To: Tapestry users
> Subject: Re: Tapestry at my company
>
> Actually I have a different perspective, arguably much less mature but
> certainly more practical. Before I knew who this stain was I wrote a
> message that quite directly confronted and disarmed him, and then I
> realized that he is simply impervious. Really, he is. Every week or so a
> new one will pop up, usually ruffling some feathers, generating some
> 'enlightened' responses, and then leading to a few 'ignore the troll'
> messages. They don't work. So I say we take a stand in the name of
> good'ole immaturity and simply insult this guy with the most asinine
> comments we can muster. Not insults generated by your being angry at
> what he said, but simply for the sake of smearing him. This isn't my
> normal character but I found it fun, and it couldn't possibly be any
> less effective than anything else that's been tried. Who knows, maybe
> we'll come up with a few gems that find themselves on http://bash.org/.
>
> So on that note I'm going to grab a beer, write some code, and drink to
> this poor bastard!
>
> Darío Vasconcelos wrote:
> > The thing that bothers me is,
> >
> > I'm pretty sure that the Wicket community is misrepresented by this
> little
> > troll, and he's probably laughing every time he checks this mailing list
> to
> > see what kind of responses happened as a result to his last dull
> > characterization as a genuine Tapestry user.
> >
> > Nevertheless, whoever this guy is, he's assuming that people will feel
> > offended by Wicket's technical superiorities over Tapestry or that, by
> > getting angry responses, people will fly away from Tap. I'm sure world
> > domination is not in Howard's agenda nor in ours, and proliferation of a
> > framework has never been a consequence of nice and gentle mailing lists
> > (think Hibernate, Rails). We all just want to use a tool that helps us
> build
> > and maintain better sites with less work.
> >
> > So come on, let this guy write his provocations alone in the desert. The
> > list is meant to help us all understanding better the funcionality and
> > possibilities of Tapestry -and of course, help each other-, not to serve
> as
> > a PR tool. The Tapestry list has always been full of bright and nice
> people,
> > that take time from their own schedules to help others, not zealots
> trying
> > to fight some religious war over their framework of choose.
> >
> > Regards,
> >
> > On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis
> <ch...@bellsouth.net>
> > wrote:
> >
> >
> >> You were wrong. We are both arrogant and hostile, so piss off and be
> >> gone with ya!
> >>
> >> Rob Smeets wrote:
> >>
> >>> Guys,
> >>>
> >>> I hoped you would rally behind me and offer some ideas to counterfight
> >>>
> >> my
> >>
> >>> colleagues. Rather you are calling me names. I am very dissapointed
> and
> >>>
> >> hope
> >>
> >>> you will all one day grow up. I thought the Tapestry community have
> nice
> >>> people. You have proved to be very arrogant and bad tempered. I hope
> to
> >>>
> >> be
> >>
> >>> the LAST newbie wanting to jump onto the Tapestry bandwagon and that
> the
> >>> others reading this would all drop off Tapestry like flies.
> >>>
> >>> Have a nice day.
> >>>
> >>> Rob
> >>>
> >>> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> >>> andreas.stroeber@siemens.com> wrote:
> >>>
> >>>
> >>>
> >>>> I suggest scheme.
> >>>>
> >>>> The more people grow up, the more they behave childish.
> >>>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>>
> >>>>
> >>>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
> >>>>> ensure maximum pain.
> >>>>>
> >>>>>
> >>>> Plain servlets and JSPs would be even better!
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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: Tapestry at my company
Posted by Chris Lewis <ch...@bellsouth.net>.
Actually I have a different perspective, arguably much less mature but
certainly more practical. Before I knew who this stain was I wrote a
message that quite directly confronted and disarmed him, and then I
realized that he is simply impervious. Really, he is. Every week or so a
new one will pop up, usually ruffling some feathers, generating some
'enlightened' responses, and then leading to a few 'ignore the troll'
messages. They don't work. So I say we take a stand in the name of
good'ole immaturity and simply insult this guy with the most asinine
comments we can muster. Not insults generated by your being angry at
what he said, but simply for the sake of smearing him. This isn't my
normal character but I found it fun, and it couldn't possibly be any
less effective than anything else that's been tried. Who knows, maybe
we'll come up with a few gems that find themselves on http://bash.org/.
So on that note I'm going to grab a beer, write some code, and drink to
this poor bastard!
Darío Vasconcelos wrote:
> The thing that bothers me is,
>
> I'm pretty sure that the Wicket community is misrepresented by this little
> troll, and he's probably laughing every time he checks this mailing list to
> see what kind of responses happened as a result to his last dull
> characterization as a genuine Tapestry user.
>
> Nevertheless, whoever this guy is, he's assuming that people will feel
> offended by Wicket's technical superiorities over Tapestry or that, by
> getting angry responses, people will fly away from Tap. I'm sure world
> domination is not in Howard's agenda nor in ours, and proliferation of a
> framework has never been a consequence of nice and gentle mailing lists
> (think Hibernate, Rails). We all just want to use a tool that helps us build
> and maintain better sites with less work.
>
> So come on, let this guy write his provocations alone in the desert. The
> list is meant to help us all understanding better the funcionality and
> possibilities of Tapestry -and of course, help each other-, not to serve as
> a PR tool. The Tapestry list has always been full of bright and nice people,
> that take time from their own schedules to help others, not zealots trying
> to fight some religious war over their framework of choose.
>
> Regards,
>
> On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis <ch...@bellsouth.net>
> wrote:
>
>
>> You were wrong. We are both arrogant and hostile, so piss off and be
>> gone with ya!
>>
>> Rob Smeets wrote:
>>
>>> Guys,
>>>
>>> I hoped you would rally behind me and offer some ideas to counterfight
>>>
>> my
>>
>>> colleagues. Rather you are calling me names. I am very dissapointed and
>>>
>> hope
>>
>>> you will all one day grow up. I thought the Tapestry community have nice
>>> people. You have proved to be very arrogant and bad tempered. I hope to
>>>
>> be
>>
>>> the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
>>> others reading this would all drop off Tapestry like flies.
>>>
>>> Have a nice day.
>>>
>>> Rob
>>>
>>> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
>>> andreas.stroeber@siemens.com> wrote:
>>>
>>>
>>>
>>>> I suggest scheme.
>>>>
>>>> The more people grow up, the more they behave childish.
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>>
>>>>
>>>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
>>>>> ensure maximum pain.
>>>>>
>>>>>
>>>> Plain servlets and JSPs would be even better!
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
AW: Tapestry at my company
Posted by Martin Kersten <Ma...@mercateo.com>.
> There's a spectrum of frameworks out there. I think Tapestry 5
> scores high marks across the board, from tiny to giant projects
> and the notes I've been collecting form users back that up.
> I can't quite see writing GMail in Tapestry 5 (but then again,
> GMail isn't written in GWT either).
Tapestry 5 + GWT is quite a very good team. Using Tapestry 5 to provide
the server side and use several GWT components (some spanning
a full page) for the view part is a way to go for productivity.
Even using a single page to provide all GWT-RPC services in a
per service rather than a per servlet fashion plays very well.
> And past a certain point, I think no HTML app, no matter how much
> Ajax pixie dust has been sprinkled on it, can match against Flex
> in terms of user experience.
Well almost right... :-) If it would be more responsible to user
actions (main critic I guess). Sadly Sun slept and Flash won. Flex
shows what JApplet could have been - just a success story. :-8
-----Ursprüngliche Nachricht-----
Von: Howard Lewis Ship [mailto:hlship@gmail.com]
Gesendet: Dienstag, 18. März 2008 18:40
An: Tapestry users
Betreff: Re: Tapestry at my company
On Tue, Mar 18, 2008 at 10:24 AM, Darío Vasconcelos <da...@gmail.com> wrote:
> The thing that bothers me is,
>
> I'm pretty sure that the Wicket community is misrepresented by this
> little troll, and he's probably laughing every time he checks this
> mailing list to see what kind of responses happened as a result to
> his last dull characterization as a genuine Tapestry user.
>
> Nevertheless, whoever this guy is, he's assuming that people will
> feel offended by Wicket's technical superiorities over Tapestry or
> that, by getting angry responses, people will fly away from Tap. I'm
> sure world domination is not in Howard's agenda nor in ours, and
> proliferation of a
Actually, the name of my corporation is "TWD, Inc." and I'll let you guess what that stands for :-)
> framework has never been a consequence of nice and gentle mailing
> lists (think Hibernate, Rails). We all just want to use a tool that
> helps us build and maintain better sites with less work.
There's a spectrum of frameworks out there. I think Tapestry 5 scores high marks across the board, from tiny to giant projects and the notes I've been collecting form users back that up. I can't quite see writing GMail in Tapestry 5 (but then again, GMail isn't written in GWT either). And past a certain point, I think no HTML app, no matter how much Ajax pixie dust has been sprinkled on it, can match against Flex in terms of user experience.
>
> So come on, let this guy write his provocations alone in the desert.
> The list is meant to help us all understanding better the
> funcionality and possibilities of Tapestry -and of course, help each
> other-, not to serve as a PR tool. The Tapestry list has always been
> full of bright and nice people, that take time from their own
> schedules to help others, not zealots trying to fight some religious war over their framework of choose.
>
> Regards,
>
> On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis
> <ch...@bellsouth.net>
> wrote:
>
>
>
> > You were wrong. We are both arrogant and hostile, so piss off and
> be > gone with ya!
> >
> > Rob Smeets wrote:
> > > Guys,
> > >
> > > I hoped you would rally behind me and offer some ideas to
> counterfight > my > > colleagues. Rather you are calling me names. I
> am very dissapointed and > hope > > you will all one day grow up. I
> thought the Tapestry community have nice > > people. You have proved
> to be very arrogant and bad tempered. I hope to > be > > the LAST
> newbie wanting to jump onto the Tapestry bandwagon and that the > >
> others reading this would all drop off Tapestry like flies.
> > >
> > > Have a nice day.
> > >
> > > Rob
> > >
> > > On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas < > >
> andreas.stroeber@siemens.com> wrote:
> > >
> > >
> > >> I suggest scheme.
> > >>
> > >> The more people grow up, the more they behave childish.
> > >>
> > >> -----Ursprüngliche Nachricht----- > >> > >>> For trolls such
> as yourself... I'd suggest you adopt struts 1 to > >>> ensure maximum
> pain.
> > >>>
> > >> Plain servlets and JSPs would be even better!
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >> > >> > >> > > > > >
>
>
>
> --
> "If you're not part of the solution, you're part of the precipitate."
> Henry J. Tillman
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
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: Tapestry at my company
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Mar 18, 2008 at 10:24 AM, Darío Vasconcelos
<da...@gmail.com> wrote:
> The thing that bothers me is,
>
> I'm pretty sure that the Wicket community is misrepresented by this little
> troll, and he's probably laughing every time he checks this mailing list to
> see what kind of responses happened as a result to his last dull
> characterization as a genuine Tapestry user.
>
> Nevertheless, whoever this guy is, he's assuming that people will feel
> offended by Wicket's technical superiorities over Tapestry or that, by
> getting angry responses, people will fly away from Tap. I'm sure world
> domination is not in Howard's agenda nor in ours, and proliferation of a
Actually, the name of my corporation is "TWD, Inc." and I'll let you
guess what that stands for :-)
> framework has never been a consequence of nice and gentle mailing lists
> (think Hibernate, Rails). We all just want to use a tool that helps us build
> and maintain better sites with less work.
There's a spectrum of frameworks out there. I think Tapestry 5 scores
high marks across the board, from tiny to giant projects and the notes
I've been collecting form users back that up. I can't quite see
writing GMail in Tapestry 5 (but then again, GMail isn't written in
GWT either). And past a certain point, I think no HTML app, no matter
how much Ajax pixie dust has been sprinkled on it, can match against
Flex in terms of user experience.
>
> So come on, let this guy write his provocations alone in the desert. The
> list is meant to help us all understanding better the funcionality and
> possibilities of Tapestry -and of course, help each other-, not to serve as
> a PR tool. The Tapestry list has always been full of bright and nice people,
> that take time from their own schedules to help others, not zealots trying
> to fight some religious war over their framework of choose.
>
> Regards,
>
> On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis <ch...@bellsouth.net>
> wrote:
>
>
>
> > You were wrong. We are both arrogant and hostile, so piss off and be
> > gone with ya!
> >
> > Rob Smeets wrote:
> > > Guys,
> > >
> > > I hoped you would rally behind me and offer some ideas to counterfight
> > my
> > > colleagues. Rather you are calling me names. I am very dissapointed and
> > hope
> > > you will all one day grow up. I thought the Tapestry community have nice
> > > people. You have proved to be very arrogant and bad tempered. I hope to
> > be
> > > the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> > > others reading this would all drop off Tapestry like flies.
> > >
> > > Have a nice day.
> > >
> > > Rob
> > >
> > > On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> > > andreas.stroeber@siemens.com> wrote:
> > >
> > >
> > >> I suggest scheme.
> > >>
> > >> The more people grow up, the more they behave childish.
> > >>
> > >> -----Ursprüngliche Nachricht-----
> > >>
> > >>> For trolls such as yourself... I'd suggest you adopt struts 1 to
> > >>> ensure maximum pain.
> > >>>
> > >> Plain servlets and JSPs would be even better!
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> >
>
>
>
> --
> "If you're not part of the solution, you're part of the precipitate."
> Henry J. Tillman
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry at my company
Posted by Darío Vasconcelos <da...@gmail.com>.
The thing that bothers me is,
I'm pretty sure that the Wicket community is misrepresented by this little
troll, and he's probably laughing every time he checks this mailing list to
see what kind of responses happened as a result to his last dull
characterization as a genuine Tapestry user.
Nevertheless, whoever this guy is, he's assuming that people will feel
offended by Wicket's technical superiorities over Tapestry or that, by
getting angry responses, people will fly away from Tap. I'm sure world
domination is not in Howard's agenda nor in ours, and proliferation of a
framework has never been a consequence of nice and gentle mailing lists
(think Hibernate, Rails). We all just want to use a tool that helps us build
and maintain better sites with less work.
So come on, let this guy write his provocations alone in the desert. The
list is meant to help us all understanding better the funcionality and
possibilities of Tapestry -and of course, help each other-, not to serve as
a PR tool. The Tapestry list has always been full of bright and nice people,
that take time from their own schedules to help others, not zealots trying
to fight some religious war over their framework of choose.
Regards,
On Tue, Mar 18, 2008 at 11:04 AM, Chris Lewis <ch...@bellsouth.net>
wrote:
> You were wrong. We are both arrogant and hostile, so piss off and be
> gone with ya!
>
> Rob Smeets wrote:
> > Guys,
> >
> > I hoped you would rally behind me and offer some ideas to counterfight
> my
> > colleagues. Rather you are calling me names. I am very dissapointed and
> hope
> > you will all one day grow up. I thought the Tapestry community have nice
> > people. You have proved to be very arrogant and bad tempered. I hope to
> be
> > the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> > others reading this would all drop off Tapestry like flies.
> >
> > Have a nice day.
> >
> > Rob
> >
> > On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> > andreas.stroeber@siemens.com> wrote:
> >
> >
> >> I suggest scheme.
> >>
> >> The more people grow up, the more they behave childish.
> >>
> >> -----Ursprüngliche Nachricht-----
> >>
> >>> For trolls such as yourself... I'd suggest you adopt struts 1 to
> >>> ensure maximum pain.
> >>>
> >> Plain servlets and JSPs would be even better!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> >
>
--
"If you're not part of the solution, you're part of the precipitate."
Henry J. Tillman
AW: Tapestry at my company
Posted by Martin Kersten <Ma...@mercateo.com>.
Temper... Temper... Temper...
Even if he makes your blood boiling, just play nice... .
-----Ursprüngliche Nachricht-----
Von: Chris Lewis [mailto:chris_lewis@bellsouth.net]
Gesendet: Dienstag, 18. März 2008 18:05
An: Tapestry users
Betreff: Re: Tapestry at my company
You were wrong. We are both arrogant and hostile, so piss off and be gone with ya!
Rob Smeets wrote:
> Guys,
>
> I hoped you would rally behind me and offer some ideas to counterfight
> my colleagues. Rather you are calling me names. I am very dissapointed
> and hope you will all one day grow up. I thought the Tapestry
> community have nice people. You have proved to be very arrogant and
> bad tempered. I hope to be the LAST newbie wanting to jump onto the
> Tapestry bandwagon and that the others reading this would all drop off Tapestry like flies.
>
> Have a nice day.
>
> Rob
>
> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> andreas.stroeber@siemens.com> wrote:
>
>
>> I suggest scheme.
>>
>> The more people grow up, the more they behave childish.
>>
>> -----Ursprüngliche Nachricht-----
>>
>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
>>> ensure maximum pain.
>>>
>> Plain servlets and JSPs would be even better!
>>
>> ---------------------------------------------------------------------
>> 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: Tapestry at my company
Posted by Chris Lewis <ch...@bellsouth.net>.
You were wrong. We are both arrogant and hostile, so piss off and be
gone with ya!
Rob Smeets wrote:
> Guys,
>
> I hoped you would rally behind me and offer some ideas to counterfight my
> colleagues. Rather you are calling me names. I am very dissapointed and hope
> you will all one day grow up. I thought the Tapestry community have nice
> people. You have proved to be very arrogant and bad tempered. I hope to be
> the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
> others reading this would all drop off Tapestry like flies.
>
> Have a nice day.
>
> Rob
>
> On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
> andreas.stroeber@siemens.com> wrote:
>
>
>> I suggest scheme.
>>
>> The more people grow up, the more they behave childish.
>>
>> -----Ursprüngliche Nachricht-----
>>
>>> For trolls such as yourself... I'd suggest you adopt struts 1 to
>>> ensure maximum pain.
>>>
>> Plain servlets and JSPs would be even better!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
Re: Tapestry at my company
Posted by Rob Smeets <rb...@gmail.com>.
Guys,
I hoped you would rally behind me and offer some ideas to counterfight my
colleagues. Rather you are calling me names. I am very dissapointed and hope
you will all one day grow up. I thought the Tapestry community have nice
people. You have proved to be very arrogant and bad tempered. I hope to be
the LAST newbie wanting to jump onto the Tapestry bandwagon and that the
others reading this would all drop off Tapestry like flies.
Have a nice day.
Rob
On Tue, Mar 18, 2008 at 5:24 PM, Stroeber, Andreas <
andreas.stroeber@siemens.com> wrote:
> I suggest scheme.
>
> The more people grow up, the more they behave childish.
>
> -----Ursprüngliche Nachricht-----
> > For trolls such as yourself... I'd suggest you adopt struts 1 to
> > ensure maximum pain.
> Plain servlets and JSPs would be even better!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
AW: Tapestry at my company
Posted by "Stroeber, Andreas" <an...@siemens.com>.
I suggest scheme.
The more people grow up, the more they behave childish.
-----Ursprüngliche Nachricht-----
> For trolls such as yourself... I'd suggest you adopt struts 1 to
> ensure maximum pain.
Plain servlets and JSPs would be even better!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry at my company
Posted by Gabriel Landais <la...@codelutin.com>.
Lance Java a écrit :
> For trolls such as yourself... I'd suggest you adopt struts 1 to ensure
> maximum pain.
Plain servlets and JSPs would be even better!
--
Gabriel <la...@codelutin.com>
http://www.codelutin.com
tel : 02 40 50 29 28 / fax : 09 59 92 29 28
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry at my company
Posted by Lance Java <la...@googlemail.com>.
For trolls such as yourself... I'd suggest you adopt struts 1 to ensure
maximum pain.
On 18/03/2008, Rob Smeets <rb...@gmail.com> wrote:
>
> Hi All,
>
> Tomorrow is our last day of debate at my work about which framework to
> choose for our upcoming huge project.
> Its seems Wicket is winning the race for it's innovativeness, finess and
> excellent support, they claim, unfortunately. Most on my team members are
> concerned about the radically incompatible versions Tapestry has. And many
> say Tapestry 5 is over engineerd and has already lost the webframework
> battle and are concerned of it's future, in terms of upgrade and support.
> Could someone here offer me some killer arguments to counterfight these
> FUDs
> of my team?
>
> Regards,
>
>
> Rob
>
AW: Tapestry at my company
Posted by "Stroeber, Andreas" <an...@siemens.com>.
Hi,
Why not just simply add a page to the Tapestry homepage with arguments for/against tapestry?
Everyone who really is interested in informations and differences between * and Tapestry could have a look at and anyone who wants to ignore 'trolls' can do so and/or send the url.
Even a link-list with articles about different frameworks would do. Everyone should be able to pick the best framework for his needs. And every troll perhaps answers questions that can be answered by or added to the page/link list.
Last but not least every serious engineer will find arguments for/against tapestry by himself. If he hasn't enough arguments, he should call into question whether Tapestry IS the right framework for what he/she wants to do. A summary page or link-list to articles just could make search/things easier for him. But always he will have to decide himself.
Grz
Andi
-----Ursprüngliche Nachricht-----
Von: Daniel Jue [mailto:teamphy6@gmail.com]
Gesendet: Dienstag, 18. März 2008 19:08
An: Tapestry users
Betreff: Re: Tapestry at my company
I honestly don't know much about Apache Wicket, except that there is a
Wicket user who likes to spread lies, misinformation and FUD on the
Tapestry Users Group because he feels it is the necessary way to
promote Wicket over Tapestry.
He is known by many names, such as Emmanuel Sowah, Francis Amanfo, and
now Rob Smeets. If you are reaching this message from Google, Nabble,
etc, please note that these trolls are the same person trying so
desperately to promote Wicket. He is likely to appear with a new
name. He kind of reminds me of the Iraqi Minister of
(mis-)Information.
http://www.welovetheiraqiinformationminister.com/mss_history.html
http://www.welovetheiraqiinformationminister.com/#quotes
I can imagine "Francis" saying,
"I can say, and I am responsible for what I am saying, that they have
started to commit suicide using CDs of our framework. We
will encourage them to commit more suicides quickly. Apache Wicket's
framework, it's name be praised, has slaughtered the infidel
Tapestry's user base.
Even as we speak Wicket is being promoted as the lead framework for
IBM. These are simple truths, Tapestry is not worth an old shoe."
If the Wicket user base wishes to have a different representative, let
a Wicket user come here and denounce the trolling done in Wicket's
name.
Daniel
On Tue, Mar 18, 2008 at 10:44 AM, Rob Smeets <rb...@gmail.com> wrote:
> Hi All,
>
> Tomorrow is our last day of debate at my work about which framework to
> choose for our upcoming huge project.
> Its seems Wicket is winning the race for it's innovativeness, finess and
> excellent support, they claim, unfortunately. Most on my team members are
> concerned about the radically incompatible versions Tapestry has. And many
> say Tapestry 5 is over engineerd and has already lost the webframework
> battle and are concerned of it's future, in terms of upgrade and support.
> Could someone here offer me some killer arguments to counterfight these FUDs
> of my team?
>
> Regards,
>
> Rob
>
---------------------------------------------------------------------
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: Tapestry at my company
Posted by Daniel Jue <te...@gmail.com>.
I honestly don't know much about Apache Wicket, except that there is a
Wicket user who likes to spread lies, misinformation and FUD on the
Tapestry Users Group because he feels it is the necessary way to
promote Wicket over Tapestry.
He is known by many names, such as Emmanuel Sowah, Francis Amanfo, and
now Rob Smeets. If you are reaching this message from Google, Nabble,
etc, please note that these trolls are the same person trying so
desperately to promote Wicket. He is likely to appear with a new
name. He kind of reminds me of the Iraqi Minister of
(mis-)Information.
http://www.welovetheiraqiinformationminister.com/mss_history.html
http://www.welovetheiraqiinformationminister.com/#quotes
I can imagine "Francis" saying,
"I can say, and I am responsible for what I am saying, that they have
started to commit suicide using CDs of our framework. We
will encourage them to commit more suicides quickly. Apache Wicket's
framework, it's name be praised, has slaughtered the infidel
Tapestry's user base.
Even as we speak Wicket is being promoted as the lead framework for
IBM. These are simple truths, Tapestry is not worth an old shoe."
If the Wicket user base wishes to have a different representative, let
a Wicket user come here and denounce the trolling done in Wicket's
name.
Daniel
On Tue, Mar 18, 2008 at 10:44 AM, Rob Smeets <rb...@gmail.com> wrote:
> Hi All,
>
> Tomorrow is our last day of debate at my work about which framework to
> choose for our upcoming huge project.
> Its seems Wicket is winning the race for it's innovativeness, finess and
> excellent support, they claim, unfortunately. Most on my team members are
> concerned about the radically incompatible versions Tapestry has. And many
> say Tapestry 5 is over engineerd and has already lost the webframework
> battle and are concerned of it's future, in terms of upgrade and support.
> Could someone here offer me some killer arguments to counterfight these FUDs
> of my team?
>
> Regards,
>
> Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry at my company
Posted by Sven Homburg <ho...@googlemail.com>.
forty two
2008/3/18, Rob Smeets <rb...@gmail.com>:
>
> Hi All,
>
> Tomorrow is our last day of debate at my work about which framework to
> choose for our upcoming huge project.
> Its seems Wicket is winning the race for it's innovativeness, finess and
> excellent support, they claim, unfortunately. Most on my team members are
> concerned about the radically incompatible versions Tapestry has. And many
> say Tapestry 5 is over engineerd and has already lost the webframework
> battle and are concerned of it's future, in terms of upgrade and support.
> Could someone here offer me some killer arguments to counterfight these
> FUDs
> of my team?
>
> Regards,
>
>
> Rob
>
--
with regards
Sven Homburg
http://tapestry5-components.googlecode.com
Re: Tapestry at my company
Posted by Adam Zimowski <zi...@gmail.com>.
Oh, shut up already.
On Tue, Mar 18, 2008 at 9:44 AM, Rob Smeets <rb...@gmail.com> wrote:
> Hi All,
>
> Tomorrow is our last day of debate at my work about which framework to
> choose for our upcoming huge project.
> Its seems Wicket is winning the race for it's innovativeness, finess and
> excellent support, they claim, unfortunately. Most on my team members are
> concerned about the radically incompatible versions Tapestry has. And many
> say Tapestry 5 is over engineerd and has already lost the webframework
> battle and are concerned of it's future, in terms of upgrade and support.
> Could someone here offer me some killer arguments to counterfight these FUDs
> of my team?
>
> Regards,
>
> Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org