click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Resolved: (CLK-703) Load pages and templates on demand
Date Fri, 25 Jun 2010 15:58:50 GMT


Bob Schellink resolved CLK-703.

    Resolution: Won't Fix

I've spent some time creating a lazy class loading scheme using various approaches. Couldn't
find an easy way which preserved the simplicity and performance of ConfigService. I'm sure
with enough time and effort the performance and locking issues could be resolved, however
the complexity goes up drastically when dealing with multiple threads. This is especially
true for services dependent on page class metadata such as SpringClickServlet. Under an eager
loading scheme, SpringClickServlet can cache page class metadata (ie page setters) during
the Servlet init() event without concern for synchronization. Under a lazy loading scheme,
metadata has to be obtained at runtime, pushing synchronization handling onto this class.
Not something I'd like to face.

My main motivation for this change was to address an issue with Google App Engine where it
doesn't allow Click to lookup template files under the root ("/") web folder. However it seems
that GAE does allow looking up resources under subfolders of root. By introducing a convention
where pages are located under the 'page' or 'pages' folder, we can again support automapping
in production environments, albeit with a small caveat.

> Load pages and templates on demand
> ----------------------------------
>                 Key: CLK-703
>                 URL:
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>            Reporter: Bob Schellink
>            Assignee: Bob Schellink
>             Fix For: 2.3.0-M1
> At startup time Click eagerly loads templates (and associated page classes) found under
the web folder. 
> The proposed change is to switch to a lazy loading scheme where pages and templates are
only loaded when requested. Scenarios needed to be catered for include:
> - HTTP Request
> - Page.setRedirect
> - Page.setForward
> There is also an outstanding bug which depends on this proposal:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message