Re: Clear PersistentFieldConduit cached value

[David Diaz]

Figured it out. You can invoke the conduit_set_[fieldname] method using
reflection (declared, not regular) and this will reflect the value in the
PerthreadMap. This function takes a singular argument with the type of the
field.

Cheers

On Mon, Dec 12, 2016 at 5:45 PM, David Diaz  wrote:

> Hi all,
>
> I am trying to set a persistent value of a field in my application on a
> XHR request. I am using tynamo's tapestry-conversation and I want to copy
> the old conversation's values to the new conversation. I am iterating
> through each field in the old conversation and setting the value for the
> new conversation like so:
>
>> Session session = request.getSession(false);
>> for (String name : session.getAttributeNames(oldConversationPrefix))
>>session.setAttribute(name.replace(oldConversationPrefix,
> newConversationPrefix), session.getAttribute(name)
>
> However once the XHR request completes the changes aren't shown in the
> render. If I update the XHR again after this has been done with another
> request (i.e click on something on the page) then the values are actually
> updated and I see what I expect.
>
> I looked into why this is happening and it seems like whenever a field is
> accessed it goes into the PerthreadMap for the specific field and grabs the
> value that was generated when the page was first rendered. Since it only
> does it at the start of the render any changes to the field don't seem to
> be reflected until the next render.
>
> I've tried:
>   * Setting the field using reflection
>   * Using InternalComponentResourcesImpl.persistFieldChange
>   * Trying to find a way to run the conduit_get_[fieldname] method to
> modify the PersistentFieldConduit value, but I couldn't figure this out
>
> Any help would be appreciated... this has stumped me! I'm sure I'm just
> doing something wrong and I've been missing something that's obvious.
>
> Thanks,
> David
>

Clear PersistentFieldConduit cached value

[David Diaz]

Hi all,

I am trying to set a persistent value of a field in my application on a XHR
request. I am using tynamo's tapestry-conversation and I want to copy the
old conversation's values to the new conversation. I am iterating through
each field in the old conversation and setting the value for the new
conversation like so:

   > Session session = request.getSession(false);
   > for (String name : session.getAttributeNames(oldConversationPrefix))
   >session.setAttribute(name.replace(oldConversationPrefix,
newConversationPrefix), session.getAttribute(name)

However once the XHR request completes the changes aren't shown in the
render. If I update the XHR again after this has been done with another
request (i.e click on something on the page) then the values are actually
updated and I see what I expect.

I looked into why this is happening and it seems like whenever a field is
accessed it goes into the PerthreadMap for the specific field and grabs the
value that was generated when the page was first rendered. Since it only
does it at the start of the render any changes to the field don't seem to
be reflected until the next render.

I've tried:
  * Setting the field using reflection
  * Using InternalComponentResourcesImpl.persistFieldChange
  * Trying to find a way to run the conduit_get_[fieldname] method to
modify the PersistentFieldConduit value, but I couldn't figure this out

Any help would be appreciated... this has stumped me! I'm sure I'm just
doing something wrong and I've been missing something that's obvious.

Thanks,
David

@Cached

[John]

does @Cached work in only pages, or should it work in components too?

Re: @Cached

[Dusko Jovanovski]

It works both in pages and components.


On Fri, Dec 6, 2013 at 2:20 PM, John j...@quivinco.com wrote:

 does @Cached work in only pages, or should it work in components too?

Re: @Cached

[Thiago H de Paula Figueiredo]

On Fri, 06 Dec 2013 11:33:05 -0200, Dusko Jovanovski dusk...@gmail.com  
wrote:



It works both in pages and components.


Just remember that @Cached only caches method return values during a  
request, but not between requests. I'm planning to do provide some caching  
(not just in a single thread) in for Tapestry-IoC and Tapestry someday  
next year.


Pages, for the most part, *are* components, but with just few differences:

* You cannot use a page inside another page, while components can be used  
inside other components.

* Pages have URLs, components don't.
* Components have parameters, pages don't.
* Pages have activation context, components don't.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
Help me spend a whole month working on Tapestry bug fixes and  
improvements: http://igg.me/at/t5month


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Page is getting cached in Tapestry 5.0.18

[Thiago H. de Paula Figueiredo]

On Sat, 15 Oct 2011 07:54:18 -0300, ManuPK manupk.t...@gmail.com wrote:

I am using tapestry version 5.0.18. In my application the tapestry pages  
are getting cached. ie, when I hit the  URL to load the page the request  
is not reaching the server. I need to press ctrl+F5 to get the valid  
page.

Is it because of the page pooling?


No. This is browser behavior.

Or how can I make sure always the request is reached the server and the  
fresh data is loaded to the page.


There's no 100% guaranteed way, but you can use Wulf's suggestions.

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Page is getting cached in Tapestry 5.0.18

[ManuPK]

Thanks Thiago and Wulf's for helping.

I don't get this issue every time but happens too-often in some machines and
pages. Is there any settings possible in  browser?

If I use the no-cache attributes even t he images will not be cached? Will
it create any performance issue?


-
Thanks,
Manu PK
--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4910658.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Page is getting cached in Tapestry 5.0.18

[ManuPK]

I am using tapestry version 5.0.18. In my application the tapestry pages are
getting cached. ie, when I hit the  URL to load the page the request is not
reaching the server. I need to press ctrl+F5 to get the valid page. 

Is it because of the page pooling? Or how can I make sure always the request
is reached the server and the fresh data is loaded to the page.

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Page is getting cached in Tapestry 5.0.18

[Muhammad Gelbana]

If the request isn't initiated by the browser to the server, then shouldn't
this be a browser issue ?

On Sat, Oct 15, 2011 at 12:54 PM, ManuPK manupk.t...@gmail.com wrote:

 I am using tapestry version 5.0.18. In my application the tapestry pages
 are
 getting cached. ie, when I hit the  URL to load the page the request is not
 reaching the server. I need to press ctrl+F5 to get the valid page.

 Is it because of the page pooling? Or how can I make sure always the
 request
 is reached the server and the fresh data is loaded to the page.

 --
 View this message in context:
 http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html
 Sent from the Tapestry - User mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org




-- 
*Regards,*
*Muhammad Gelbana
Java Developer*

RE: Page is getting cached in Tapestry 5.0.18

[Wechsung, Wulf]

Hi Manu,

It helps to set the following meta tags:

meta content=NO-CACHE http-equiv=CACHE-CONTROL
meta content=NO-CACHE http-equiv=PRAGMA
META HTTP-EQUIV=Expires CONTENT=-1


Kind Regards,
Wulf

-Original Message-
From: ManuPK [mailto:manupk.t...@gmail.com] 
Sent: Samstag, 15. Oktober 2011 12:54
To: users@tapestry.apache.org
Subject: Page is getting cached in Tapestry 5.0.18

I am using tapestry version 5.0.18. In my application the tapestry pages are
getting cached. ie, when I hit the  URL to load the page the request is not
reaching the server. I need to press ctrl+F5 to get the valid page. 

Is it because of the page pooling? Or how can I make sure always the request
is reached the server and the fresh data is loaded to the page.

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

T5: @Cached(watch) parameter requires public property

[Adam Zimowski]

Hi Again -

Is there a specific reason why watch parameter for @Cached annotation
requires public property when using default prop binding? This is an
inconvenient limitation IMO, as I don't necessarily want to expose my
watch property publicly. For example, my watch on getShoppingCart may
be something like this:

@Cached(watch=cartWatch)
public ShoppingCartBean getShoppingCart() {

Long userId = getUserId();
Long cartId = getCartId();
log.debug(cartId: {}, userId: {}, cartId, userId);

return cartService.findShoppingCart(cartId, userId);
}

private long getCartWatch() {
Long userId = getUserId();
Long cartId = getCartId();
if(userId == null) userId = 0L;
if(cartId == null) cartId = 0L;

return userId + cartId;
}

Minor issue, but unless there is a strict reason behind it, I thing
watch should allow any scope.

Adam

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: T5: @Cached(watch) parameter requires public property

[Thiago H. de Paula Figueiredo]

On Thu, 28 Apr 2011 17:38:01 -0300, Adam Zimowski zimowsk...@gmail.com  
wrote:



Hi Again -


Hi!


Is there a specific reason why watch parameter for @Cached annotation
requires public property when using default prop binding?


I'd guess the JVM bytecode verifier would complain about invalid access,  
as the prop binding generates its classes outside the page class.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

@Cached method called multiple times

[Tobias Marx]

Hello everyone!

I am using Tapestry 5.1.5 and I noticed that a method annotated as @Cached is 
executed several times for a single pageview.

I am using a BaseComponent class that contains this method. It is called from 
component that extends this.

Or is it possible @Cached is not working when debugging with Jetty?

Thanks!

Tobias


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: @Cached method called multiple times

[Thiago H. de Paula Figueiredo]

On Mon, 04 Oct 2010 14:18:19 -0300, Tobias Marx tmar...@gmx.de wrote:


Hello everyone!


Hi!

I am using Tapestry 5.1.5 and I noticed that a method annotated as  
@Cached is executed several times for a single pageview.
I am using a BaseComponent class that contains this method. It is  
called from component that extends this.


I guess you have more than one BaseComponent subclass instance in your  
page. If so, you're seeing the expected behavior.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

How to flush cached pages for a user when locale is changed

[N T R PHANI KUMAR]

hi
I want to flush the cached pages when i change the locale for the user.
how can i do that?

thanks

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: How to flush cached pages for a user when locale is changed

[Juan E. Maya]

What r u trying to accomplish?

If u want the pages to see the new locale u can use LocalizationSetter
service. Normally what i do is to add a PageRenderRequestFilter that obtains
the user locale (from database or cookie) and then u just need to call
 localizationSetter.setLocaleFromLocaleName(locale); This will assure that
ur messages will be resolved correctly.  I don't think that messing with the
page pool is ment for typical use cases but well, maybe u r tying to do
something different.

I hope it helps.


On Tue, Feb 9, 2010 at 3:34 PM, N T R PHANI KUMAR phan...@imaginea.comwrote:

 hi
 I want to flush the cached pages when i change the locale for the user.
 how can i do that?

 thanks

 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org

where would I start if I wanted to add support for cached javascript minification?

[Josh Long]

Where would I start if I wanted to add support for cached javascript
minification a la JAWR? I know that Tapestry 5.1 ships with intrinsic
support for combined JS files. Does that combination happen on each
request? Or is it cached? What of the gzip support? Cached or not
cached in memory? Finally, what about taking it one step further --
what if I wanted to use the Yahoo YUI minification routine (opt-in) to
then minify and condense these combined javascript files? Where in the
user-land sections of the Tapestry framework would I make this
contribution? Or, where in Tapestry proper would somebody endeavor to
write a patch to add this sort of functionality? I've not done too
much spelunking and so I'm really looking for any exploratory
information here. Any one else do anything like this?

Thanks,
Joshua Long
http://www.joshlong.com/

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: where would I start if I wanted to add support for cached javascript minification?

[Andreas Andreou]

No real answers, but if you want to run jawr 'offline' check out
http://github.com/andyhot/maven-jawr-plugin/
or this thread in jawr ML
http://markmail.org/message/ef4vtu7xl75fe3ra

On Thu, Jun 4, 2009 at 5:56 AM, Josh Long starbux...@gmail.com wrote:
 Where would I start if I wanted to add support for cached javascript
 minification a la JAWR? I know that Tapestry 5.1 ships with intrinsic
 support for combined JS files. Does that combination happen on each
 request? Or is it cached? What of the gzip support? Cached or not
 cached in memory? Finally, what about taking it one step further --
 what if I wanted to use the Yahoo YUI minification routine (opt-in) to
 then minify and condense these combined javascript files? Where in the
 user-land sections of the Tapestry framework would I make this
 contribution? Or, where in Tapestry proper would somebody endeavor to
 write a patch to add this sort of functionality? I've not done too
 much spelunking and so I'm really looking for any exploratory
 information here. Any one else do anything like this?

 Thanks,
 Joshua Long
 http://www.joshlong.com/

 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org





-- 
Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Cached and Self-Calls

[Geoffrey Wiseman]

Does tapestry manipulate the page class enough that @Cached affects
self-calls?

That is, if I wrote this code:

@Cached
List? getSomeExpensiveResult() { ... }

String getSummary() {
  if( getSomeExpensiveResult().isEmpty() )
  return nothing;
  else {
String summary = ;
for( Object item : getSomeExpensiveResult() ) {
  summary += item.toString();
}
  }
}

Would getSummary() call getSomeExpensiveResult() twice (as it would if the
internals weren't manipulated in some way), or does Tapestry manipulate the
class enough that even that kind of use is cached?  I've always got
@SetupRender as an alternative for calculating something expensive, from
what I can tell.

  - Geoffrey
-- 
Geoffrey Wiseman
http://www.geoffreywiseman.ca/

Re: Cached and Self-Calls

[Howard Lewis Ship]

I believe self-calls are handled; you can use @Cached on non-public
methods as well.

On Thu, Mar 26, 2009 at 12:54 PM, Geoffrey Wiseman
geoffrey.wise...@gmail.com wrote:
 Does tapestry manipulate the page class enough that @Cached affects
 self-calls?

 That is, if I wrote this code:

 @Cached
 List? getSomeExpensiveResult() { ... }

 String getSummary() {
  if( getSomeExpensiveResult().isEmpty() )
  return nothing;
  else {
    String summary = ;
    for( Object item : getSomeExpensiveResult() ) {
      summary += item.toString();
    }
  }
 }

 Would getSummary() call getSomeExpensiveResult() twice (as it would if the
 internals weren't manipulated in some way), or does Tapestry manipulate the
 class enough that even that kind of use is cached?  I've always got
 @SetupRender as an alternative for calculating something expensive, from
 what I can tell.

  - Geoffrey
 --
 Geoffrey Wiseman
 http://www.geoffreywiseman.ca/




-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Cached Annotation watch property seems to use '==' instead of 'equals'

[Doug Hauge]

I'm trying to use the '@Cached' annotation with a watch expression
to cache results of methods in a form contained within a loop. For
some watch expressions, I construct a string, so the code basically
looks like

@Cached(watch=watchKey)
Object getData() {
   // return data;
}

String getWatchKey() {
   return a.toString() + : + b.toString();
}

When I do this, though, the cached annotation does not seem to work
properly, in that the 'getData()' method is called multiple times
in a request. The problem seems to be that '==' is used instead of
'equals' in the code 'CachedWorker' generates to compare the result
of the watch expression. Is this intentional, so we need to make sure
the watch expression returns the exact same object if we want to use
a cached value? Or should it be changed to use 'equals'?

Doug


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Cached Annotation watch property seems to use '==' instead of 'equals'

[Howard Lewis Ship]

Looks like an oversight to me ... using equals() would make more sense
to me as well.  It is intended primarily for Hibernate entities, but
equals() works there as well, as Hibernate ensures that primary key
identity is the same as object identity with a context.

Perhaps Dan can shed some light?  @Cached was written by Dan Adams.

On Mon, Dec 22, 2008 at 4:44 PM, Doug Hauge doug.ha...@lithium.com wrote:
 I'm trying to use the '@Cached' annotation with a watch expression
 to cache results of methods in a form contained within a loop. For
 some watch expressions, I construct a string, so the code basically
 looks like

 @Cached(watch=watchKey)
 Object getData() {
   // return data;
 }

 String getWatchKey() {
   return a.toString() + : + b.toString();
 }

 When I do this, though, the cached annotation does not seem to work
 properly, in that the 'getData()' method is called multiple times
 in a request. The problem seems to be that '==' is used instead of
 'equals' in the code 'CachedWorker' generates to compare the result
 of the watch expression. Is this intentional, so we need to make sure
 the watch expression returns the exact same object if we want to use
 a cached value? Or should it be changed to use 'equals'?

 Doug


 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org





-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: tacos @Cached in t4

[michael lim]

i tried this. whenever i press f5, pagebeginrender will still be called and db
will be hit


@Persist(session)
public abstract Collection getPersistThisOne();
public abstract void setPersistThisOne(Collection persistThisOne); 

 public  void pageBeginRender(PageEvent event) {
 System.out.println(pageBeginRender..);
 
setPersistThisOne( dao.getFromDB());

  
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tacos @Cached in t4

[Filip S. Adamsen]

I'm sorry, but what do you expect Tapestry to do about that? You're 
explicity setting the property each time the page is loaded. @Persist 
doesn't change that.


You'll need to check whether or not persistThisOne is not null before 
assigning to it for this to work.


-Filip

On 2008-09-07 08:39, michael lim wrote:

i tried this. whenever i press f5, pagebeginrender will still be called and db
will be hit


@Persist(session)
public abstract Collection getPersistThisOne();
public abstract void setPersistThisOne(Collection persistThisOne); 


 public  void pageBeginRender(PageEvent event) {
 System.out.println(pageBeginRender..);
 
setPersistThisOne( dao.getFromDB());


  
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

tacos @Cached in t4

[michael lim]

in my page, i do like below, but when i press refresh F5 on page, i keep on
getting database hit.  when using cached, aren't it not suppose to call
getFromDB() for subsequent call ?


@Cached
  public String getGenerateMenuCached() {
 

return dao.getFromDb();
}




//in my dao
public String getFromDB(){

  System.out.println(hit db);
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tacos @Cached in t4

[michael lim]

my .application look like this

 library id=tacos specification-path=/net/sf/tacos/Tacos.library/
  library id=dojo specification-path=/net/sf/tacos/Dojo.library/
  library id=comet specification-path=/net/sf/tacos/cometd/Cometd.library/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tacos @Cached in t4

[Kalle Korhonen]

You've misunderstood the purpose of @Cached. The documentation (
http://tacos.sourceforge.net/tacos4.1/tacos-annotations/index.html) says:
The Cached
http://tacos.sourceforge.net/tacos4.1/apidocs/net/sf/tacos/annotations/Cached.htmlannotation
allows you to cache the results of a pag/component method for the
lifetime of a single request. It can be attached to any non-private,
non-abstract method:. When you press F5 you are creating a new request. You
might be looking for @Persist instead; you use it with an abstract property
that you populate somewhere else, for example in pageBeginRender.

Kalle


On Sat, Sep 6, 2008 at 10:03 AM, michael lim [EMAIL PROTECTED] wrote:

 in my page, i do like below, but when i press refresh F5 on page, i keep on
 getting database hit.  when using cached, aren't it not suppose to call
 getFromDB() for subsequent call ?


 @Cached
  public String getGenerateMenuCached() {


return dao.getFromDb();
}




 //in my dao
 public String getFromDB(){

  System.out.println(hit db);
 }


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Tables being cached by IE

[Moritz Gmelin]

Hi,

one of our clients has noticed, that when he accesses a simple page  
with a grid through IE7, hitting the Pagers on the grid does not show  
the requested Grid-Page but still the old one. Refreshing the page  
thereafter show the right grid-page.
I can imagine that IE is doing some caching here because the URL looks  
the same after paging through the grid.
Is this a known problem with IE? I cannot reproduce this with IE here  
on my PC though.

The Grid is not an inPlace grid.


Would it be the right solution to add some HTTP-EQUIV header to tell  
the browser not to do any caching with that page? For every page  
containing a grid?



M.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Francois Armand]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[superoverdrive]

Yes, you are right. But loops are usually inside of components and pages 
contain those componentsbut 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 [EMAIL PROTECTED]
 An: Tapestry users users@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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Francois Armand]

[EMAIL PROTECTED] wrote:

Yes, you are right. But loops are usually inside of components and pages contain those 
componentsbut 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Davor Hrg]

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 [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
   Yes, you are right. But loops are usually inside of components and pages 
 contain those componentsbut 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: @Cached and caching in general

[Martin Kersten]

 ...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:[EMAIL PROTECTED] 
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
 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:[EMAIL PROTECTED] 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

Re: AW: @Cached and caching in general

[Andreas Andreou]

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
 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 themthis 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

Re: AW: @Cached and caching in general

[Davor Hrg]

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
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
  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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
 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

@Cached and caching in general

[Tobias Marx]

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 themthis 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Davor Hrg]

@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Adam Zimowski]

@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Tobias Marx]

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 [EMAIL PROTECTED]
 An: Tapestry users users@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: @Cached and caching in general

[Martin Kersten]

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
   pMy 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:[EMAIL PROTECTED] 
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 [EMAIL PROTECTED]
 An: Tapestry users users@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 [EMAIL PROTECTED] 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 themthis 
 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: @Cached and caching in general

[Tobias Marx]

My theory is that such a disk-caching behaviour could speed up Tapestry 
applications by factor 100although 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 [EMAIL PROTECTED]
 An: Tapestry users users@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:[EMAIL PROTECTED] 
 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 themthis 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Filip S. Adamsen]

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 [EMAIL PROTECTED]
An: Tapestry users users@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Filip S. Adamsen]

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 100although 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 [EMAIL PROTECTED]
An: Tapestry users users@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:[EMAIL PROTECTED] 
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 themthis 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: @Cached and caching in general

[Tobias Marx]

 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Tobias Marx]

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 [EMAIL PROTECTED]
 An: Tapestry users users@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 100although 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 [EMAIL PROTECTED]
  An: Tapestry users users@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:[EMAIL PROTECTED] 
  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 themthis 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED

AW: @Cached and caching in general

[Martin Kersten]

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:[EMAIL PROTECTED] 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Filip S. Adamsen]

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 [EMAIL PROTECTED]
An: Tapestry users users@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 100although 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 [EMAIL PROTECTED]
An: Tapestry users users@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:[EMAIL PROTECTED] 
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 themthis 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e

AW: @Cached and caching in general

[Martin Kersten]

@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:[EMAIL PROTECTED] 
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 themthis 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: @Cached and caching in general

[Tobias Marx]

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 [EMAIL PROTECTED]
 An: Tapestry users users@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: @Cached and caching in general

[Tobias Marx]

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 queriesone 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 [EMAIL PROTECTED]
 An: Tapestry users users@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:[EMAIL PROTECTED] 
 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Davor Hrg]

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
   An: Tapestry users users@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 100although 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 [EMAIL PROTECTED]
   An: Tapestry users users@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:[EMAIL PROTECTED]
   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 themthis 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

RE: @Cached and caching in general

[Jonathan Barker]

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:[EMAIL PROTECTED]
 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 queriesone 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 [EMAIL PROTECTED]
  An: Tapestry users users@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:[EMAIL PROTECTED]
  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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Fernando Padilla]

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:[EMAIL PROTECTED] 
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 themthis 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Andreas Andreou]

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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
   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 themthis 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Davor Hrg]

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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
   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 themthis 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Davor Hrg]

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
 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:[EMAIL PROTECTED]
 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

Re: @Cached and caching in general

[Howard Lewis Ship]

Nope.  It's dangerous stuff that should be used with care.

On Tue, Mar 18, 2008 at 10:01 AM, Tobias Marx [EMAIL PROTECTED] 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 [EMAIL PROTECTED]

  An: Tapestry users users@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 [EMAIL PROTECTED] 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 themthis 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: @Cached and caching in general

[Howard Lewis Ship]

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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
   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 themthis 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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Howard M. Lewis Ship

Creator

Re: AW: @Cached and caching in general

[Fernando Padilla]

:)

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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
  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 themthis 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

##T4##Is tapestry service cached?!

[Oliver Lee]

i wrote my own service,but i found that when i request a service from one 
window only first time,i can debug,then every time request the service from the 
same window will response directly,i cant stop at the 
break point,the situation like serivice is cached,so ,i want ask does the 
service i wrote will cached if i dont open a new IE window?if it is , how to 
disable the cache??thanks a lot!




Oliver Lee
2008-03-02

RE: propertyselection not cached

[Ken nashua]

Thanks James,

That seems like a viable concern (parameter names versus component id's). I 
segregated them by postpending PARM to all my parameter names. No relief so 
I am kinda stuck.

form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit
div jwcid=[EMAIL PROTECTED] 
block=ognl:components.autoPagingContent/
div jwcid=@RenderBlock block=ognl:components.collectionContent/
div jwcid=[EMAIL PROTECTED] 
block=ognl:components.autoPagingContent/
/form

My headerSelect's select component gets changed but clobbered by my 
footerSelect's select component.

And my footerSelect's select component clobbers my headerSelect's component 
when their id's are different according to the markup.

So I am wondering if it is a tapestry bug. In general I would like to find out 
how one can update an identical another component on the same page. I could 
then force this thing to behave correctly.

Best regards
Ken in nashua

From: [EMAIL PROTECTED]
To: users@tapestry.apache.org
Subject: propertyselection not cached
Date: Tue, 9 Oct 2007 15:48:22 -0400








Folks,

I have a propertyselection component rigged with 1,2,3,4,5...

Everytime I select from my propertyselection... the this.form.submit() listener 
gets called... but my property gets reset. Nothing sticks...

Gallery.JAVA
public IPage onFormSubmit (IRequestCycle cycle) {
IPage page = cycle.getPage();
return page;
}

Any ideas? My rendering is fine...Template follows:

Best regards
Ken in nashua

span jwcid=$content$

span jwcid=[EMAIL PROTECTED]
table width=100% border=1
tr
td width=25% align=left NOWRAP
span jwcid=@Insert value=Table Size/
select jwcid=@PropertySelection model=ognl:@[EMAIL 
PROTECTED] value=ognl:tableSize 
onchange=javascript:this.form.submit();/select
span jwcid=@Insert value=Paging Span/
select jwcid=@PropertySelection model=ognl:@[EMAIL 
PROTECTED] value=ognl:pagingSpan 
onchange=javascript:this.form.submit();/select
/td
td align=left NOWRAP
a jwcid=@DirectLink listener=listener:onBegin 
style=fontSize:15px; span jwcid=@Insert value=/ /a
a jwcid=@DirectLink listener=listener:onPrev span 
jwcid=@Insert value=/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a
a jwcid=@DirectLink listener=listener:onNext span 
jwcid=@Insert value=/  /a
a jwcid=@DirectLink listener=listener:onEnd span 
jwcid=@Insert value=/ /a
/td
/tr
/table
/span

span jwcid=[EMAIL PROTECTED]
table width=100%
tr
span jwcid=[EMAIL PROTECTED] source=ognl:collection 
value=ognl:currentObject index=ognl:index
span jwcid=@If condition=ognl:(index % tableSize) == 0
span jwcid=@Insert value=/trtr raw=true/
/span
td
a jwcid=[EMAIL PROTECTED] listener=listener:edit 
parameters=ognl:currentObject
img jwcid=@Image
 image=ognl:photoAsset
 alt=ognl:currentObject.demographics.city
 title=ognl:currentObject.demographics.city 
width=160 height=110
 /
/a
/td
/span
/tr
/table
/span

form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit
div jwcid=@RenderBlock block=ognl:components.autoPagingContent/
div jwcid=@RenderBlock block=ognl:components.collectionContent/
div jwcid=@RenderBlock block=ognl:components.autoPagingContent/
/form

Help yourself to FREE treats served up daily at the Messenger Café. Stop by 
today!

_
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

propertyselection not cached

[Ken nashua]

Folks,

I have a propertyselection component rigged with 1,2,3,4,5...

Everytime I select from my propertyselection... the this.form.submit() listener 
gets called... but my property gets reset. Nothing sticks...

Gallery.JAVA
public IPage onFormSubmit (IRequestCycle cycle) {
IPage page = cycle.getPage();
return page;
}

Any ideas? My rendering is fine...Template follows:

Best regards
Ken in nashua

span jwcid=$content$

span jwcid=[EMAIL PROTECTED]
table width=100% border=1
tr
td width=25% align=left NOWRAP
span jwcid=@Insert value=Table Size/
select jwcid=@PropertySelection model=ognl:@[EMAIL 
PROTECTED] value=ognl:tableSize 
onchange=javascript:this.form.submit();/select
span jwcid=@Insert value=Paging Span/
select jwcid=@PropertySelection model=ognl:@[EMAIL 
PROTECTED] value=ognl:pagingSpan 
onchange=javascript:this.form.submit();/select
/td
td align=left NOWRAP
a jwcid=@DirectLink listener=listener:onBegin 
style=fontSize:15px; span jwcid=@Insert value=/ /a
a jwcid=@DirectLink listener=listener:onPrev span 
jwcid=@Insert value=/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a
a jwcid=@DirectLink listener=listener:onPage 
parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a
a jwcid=@DirectLink listener=listener:onNext span 
jwcid=@Insert value=/  /a
a jwcid=@DirectLink listener=listener:onEnd span 
jwcid=@Insert value=/ /a
/td
/tr
/table
/span

span jwcid=[EMAIL PROTECTED]
table width=100%
tr
span jwcid=[EMAIL PROTECTED] source=ognl:collection 
value=ognl:currentObject index=ognl:index
span jwcid=@If condition=ognl:(index % tableSize) == 0
span jwcid=@Insert value=/trtr raw=true/
/span
td
a jwcid=[EMAIL PROTECTED] listener=listener:edit 
parameters=ognl:currentObject
img jwcid=@Image
 image=ognl:photoAsset
 alt=ognl:currentObject.demographics.city
 title=ognl:currentObject.demographics.city 
width=160 height=110
 /
/a
/td
/span
/tr
/table
/span

form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit
div jwcid=@RenderBlock block=ognl:components.autoPagingContent/
div jwcid=@RenderBlock block=ognl:components.collectionContent/
div jwcid=@RenderBlock block=ognl:components.autoPagingContent/
/form

_
Help yourself to FREE treats served up daily at the Messenger Café. Stop by 
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

RE: propertyselection not cached

[Jonathan Barker]

I'm assuming this is related to your later post:

is not bound and can not be updated or BINDINGEXCEPTION ?

Play it safe and choose names for the persistent page parameters for your
select values that are different from the parameters used for components on
the page - at least until you can understand what's happening.

Then wire the component parameter to the persistent page property. I've hit
odd stuff before when I've had the same page property name as component
parameter name.


Jon




 -Original Message-
 From: Ken nashua [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 09, 2007 3:48 PM
 To: users@tapestry.apache.org
 Subject: propertyselection not cached
 
 
 Folks,
 
 I have a propertyselection component rigged with 1,2,3,4,5...
 
 Everytime I select from my propertyselection... the this.form.submit()
 listener gets called... but my property gets reset. Nothing sticks...
 
 Gallery.JAVA
 public IPage onFormSubmit (IRequestCycle cycle) {
 IPage page = cycle.getPage();
 return page;
 }
 
 Any ideas? My rendering is fine...Template follows:
 
 Best regards
 Ken in nashua
 
 span jwcid=$content$
 
 span jwcid=[EMAIL PROTECTED]
 table width=100% border=1
 tr
 td width=25% align=left NOWRAP
 span jwcid=@Insert value=Table Size/
 select jwcid=@PropertySelection
 model=ognl:@[EMAIL PROTECTED]
 value=ognl:tableSize onchange=javascript:this.form.submit();/select
 span jwcid=@Insert value=Paging Span/
 select jwcid=@PropertySelection
 model=ognl:@[EMAIL PROTECTED]
 value=ognl:pagingSpan
 onchange=javascript:this.form.submit();/select
 /td
 td align=left NOWRAP
 a jwcid=@DirectLink listener=listener:onBegin
 style=fontSize:15px; span jwcid=@Insert value=/ /a
 a jwcid=@DirectLink listener=listener:onPrev
 span jwcid=@Insert value=/ /a
 a jwcid=@DirectLink listener=listener:onPage
 parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a
 a jwcid=@DirectLink listener=listener:onPage
 parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a
 a jwcid=@DirectLink listener=listener:onPage
 parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a
 a jwcid=@DirectLink listener=listener:onPage
 parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a
 a jwcid=@DirectLink listener=listener:onPage
 parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a
 a jwcid=@DirectLink listener=listener:onNext
 span jwcid=@Insert value=/  /a
 a jwcid=@DirectLink listener=listener:onEnd
 span jwcid=@Insert value=/ /a
 /td
 /tr
 /table
 /span
 
 span jwcid=[EMAIL PROTECTED]
 table width=100%
 tr
 span jwcid=[EMAIL PROTECTED] source=ognl:collection
 value=ognl:currentObject index=ognl:index
 span jwcid=@If condition=ognl:(index % tableSize)
 == 0
 span jwcid=@Insert value=/trtr
 raw=true/
 /span
 td
 a jwcid=[EMAIL PROTECTED]
 listener=listener:edit parameters=ognl:currentObject
 img jwcid=@Image
  image=ognl:photoAsset
  alt=ognl:currentObject.demographics.city
  title=ognl:currentObject.demographics.city
 width=160 height=110
  /
 /a
 /td
 /span
 /tr
 /table
 /span
 
 form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit
 div jwcid=@RenderBlock
 block=ognl:components.autoPagingContent/
 div jwcid=@RenderBlock
 block=ognl:components.collectionContent/
 div jwcid=@RenderBlock
 block=ognl:components.autoPagingContent/
 /form
 
 _
 Help yourself to FREE treats served up daily at the Messenger Café. Stop
 by today.
 http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_Oct
 WLtagline


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dojo error on Yahoo search or Live search cached pages

[andyhot]

Christian Dutaret wrote:

Should I file a JIRA issue for this?


Go ahead... did you get to the source of it?



2007/2/1, andyhot [EMAIL PROTECTED]:


Yea, you're right.

Just did a yahoo search for opencomponentry demo
and the first result (the tacos demo) has the same issue...


http://216.109.125.130/search/cache?p=opencomponentry+demoei=UTF-8fr=yfp-t-501x=wrtu=opencomponentry.com:8080/tacos/appw=opencomponentry+demod=Tt4hHexsOKoEicp=1.intl=us 



Same thing happens (for that page) on the google cache as well.

http://216.239.59.104/search?q=cache:hENlXPtmM3UJ:opencomponentry.com:8080/tacos/+opencomponentry+demohl=engl=grct=clnkcd=1client=firefox-a 



We'll need to do some js debugging to figure out this...



Christian Dutaret wrote:
 Hi all,

 I deployed a brand new web site which is based on T4.1.1 last week.
 It has just began to be indexed on Yahoo search and Live search.

 On both these search engines, whenever I request the cached page from
the
 search results, an alert box tells me Permission refused to obtain 
the

 Window.dojo property (freely translated from French actually).
 I understand that the search engine cache is trying to execute some
 remote
 js on my page, which it is not allowed to, but is there any workaround
to
 this?

 I don't know about google's cache behavior, since we're not yet
 indexed on
 google (thanks to the #$@§#§!£ google sandbox).

 Thx for any hint
 Ch.



--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dojo error on Yahoo search or Live search cached pages

[Christian Dutaret]

Hi all,

I deployed a brand new web site which is based on T4.1.1 last week.
It has just began to be indexed on Yahoo search and Live search.

On both these search engines, whenever I request the cached page from the
search results, an alert box tells me Permission refused to obtain the
Window.dojo property (freely translated from French actually).
I understand that the search engine cache is trying to execute some remote
js on my page, which it is not allowed to, but is there any workaround to
this?

I don't know about google's cache behavior, since we're not yet indexed on
google (thanks to the #$@§#§!£ google sandbox).

Thx for any hint
Ch.

Re: Dojo error on Yahoo search or Live search cached pages

[andyhot]

Yea, you're right.

Just did a yahoo search for opencomponentry demo
and the first result (the tacos demo) has the same issue...

http://216.109.125.130/search/cache?p=opencomponentry+demoei=UTF-8fr=yfp-t-501x=wrtu=opencomponentry.com:8080/tacos/appw=opencomponentry+demod=Tt4hHexsOKoEicp=1.intl=us

Same thing happens (for that page) on the google cache as well.
http://216.239.59.104/search?q=cache:hENlXPtmM3UJ:opencomponentry.com:8080/tacos/+opencomponentry+demohl=engl=grct=clnkcd=1client=firefox-a

We'll need to do some js debugging to figure out this...



Christian Dutaret wrote:

Hi all,

I deployed a brand new web site which is based on T4.1.1 last week.
It has just began to be indexed on Yahoo search and Live search.

On both these search engines, whenever I request the cached page from the
search results, an alert box tells me Permission refused to obtain the
Window.dojo property (freely translated from French actually).
I understand that the search engine cache is trying to execute some 
remote

js on my page, which it is not allowed to, but is there any workaround to
this?

I don't know about google's cache behavior, since we're not yet 
indexed on

google (thanks to the #$@§#§!£ google sandbox).

Thx for any hint
Ch.




--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parameter values are cached?

[Kevin Menard]

Have you looked at the source for the For component?  If that can do it,  
you should be able to with your While.


--
Kevin

On Tue, 20 Jun 2006 14:15:08 -0400, Dan Adams [EMAIL PROTECTED] wrote:


I want to write a @While component that takes a condition just like @If
does. The problem is that you can't give an ognl expression for the
condition and have it evaluated each time I call getCondition(). Anyone
know a way to do this?





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parameter values are cached?

[Dan Adams]

It was a dumb question on my part. I should have replied when I saw it.
@Parameter has a 'cache' parameter. duh. :)

On Tue, 2006-06-20 at 14:30 -0400, Kevin Menard wrote:
 Have you looked at the source for the For component?  If that can do it,  
 you should be able to with your While.
 
-- 
Dan Adams
Software Engineer
Interactive Factory
617.235.5857


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]