You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2023/02/16 04:04:00 UTC

[jira] [Commented] (TAP5-2742) Smarter page cache invalidation

    [ https://issues.apache.org/jira/browse/TAP5-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689492#comment-17689492 ] 

ASF subversion and git services commented on TAP5-2742:
-------------------------------------------------------

Commit 52113b4ca244f8f8acac6447d5c10b2b49b3b07c in tapestry-5's branch refs/heads/better-page-invalidation from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=52113b4ca ]

TAP5-2742: first pass at multiple classloader support

for live class reloading

> Smarter page cache invalidation
> -------------------------------
>
>                 Key: TAP5-2742
>                 URL: https://issues.apache.org/jira/browse/TAP5-2742
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>            Reporter: Thiago Henrique De Paula Figueiredo
>            Assignee: Thiago Henrique De Paula Figueiredo
>            Priority: Major
>
> Since Tapestry 5's inception, it throws the whole set of assembled page instances when anything related is changed, be it the class itself, its template and maybe also associated messages and assets. In very large projects with large pages, this can reach a point it slows down the user (programmer) productivity, forced to wait for unchanged pages to be reassambled. 
> Tapestry should provide some way for users to segment page, component, mixin and base classes to separate regions, one for each classloader, to avoid clearing out cached page instances that don't have themselves or the classes they use changed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)