One of those things that isn't very well mentioned in the user guides is
getApplication().getStoreSettings().setFileStoreFolder()
Apparently, it seemed Apache Wicket is able to function without it, but
I'd guess if you don't provide a FileStoreFolder(), the page cache would
be only in the Sessions.
I'm not too sure if that is the case. And if the Sessions would bloat
with pages.
After I setup a FileStoreFolder(), when stateful pages are visited,
pages start to accumulate in the FileStoreFolder() and that can be
conveniently checked in the file system. e.g. directory size, du in
Linux etc.
But that after I made my pages all stateless, nothing stores in the
FileStoreFolder() and in addition, I made some utilities to check the
Eclipse Jetty sessions and verified that none is created related to the
page cache.
I think stateless pages is the 'right' way to do so in particular if one
intends to run it in commercial 'cloud' servers/instances e.g. VPS where
quite often the allowable memory is 512MB to 1GB. And that limit is for
both the OS and everything else running in it.
Bots (very often viruses and some malicious port scanners) remain a
threat and the threat landscape is really bad these days on the open
internet. Even if it is not malicious, a web crawler can easily cause
the page cache to bloat and is a non-trival risk.
On 16/04/2025 04:57, Andrea Del Bene wrote:
Thank you for this honest and nice feedback! I'm happy you appreciate the
rational that stays behind the logic of Wicket!
Speaking more about your development experience, I also tend to use
stateless pages for the public area of my web apps to mitigate the risk of
session overbloating by malicious bots. It might also help using
StoreSettings.setMaxSizePerSession to ensure user session stays under a
given size. My 2 cents...
On Tue, 15 Apr 2025, 00:04 andrew goh, <gohand...@yahoo.com.invalid> wrote:
Apache Wicket is a very good framework, coming from the spring-boot camp
and picking up the ropes in Apache Wicket.
I think Apache Wicket is well designed, and probably more so than
various frameworks Spring-framework Spring-boot with all its IOC
containers etc.
Spring-framework, its MVC architecture and templates are 'easier' to
learn vs Apache Wicket, those are more conventional in the sense of HTML
/ JSP (Thymeleaf etc) templates where you script in the templates and
put a MVC Java framework around it. However, as the complexity of web
development evolves, the development progress often becomes rather
repetitive with large amount of HTML intersperse codes, and increasingly
the web starts to look more like an assembly of fragments / components.
I'd guess it is a reason Javascript frameworks e.g. Angular, React etc
evolved to meet those needs. But that Javascript 'runs in the browser'
and has 'SEO' implications etc.
Apache Wicket is 'hard to learn' with its architecture and design with
emphasis around reusable Java components an elaborate state tracking to
make stateful pages, is a much needed 'overhaul' to 'conventional'
'scripting in templates' style of design.
The state tracking and page cache and 'model' architecture with forms is
practically 'fully built-in', automated, I created a javabean used in a
form in which only part of the fields are represented in the form, but
that all the fields / instance variables are properly transferred even
though I missed out on passing those in the form as hidden fields. e.g.
the id field of the javabean used as primary key in a DB table.
As I'm intending to run my app possibly in a VPS (cloud servers), I get
pretty paranoid about Apache Wicket's page cache mechanism as a worry is
that a robot can easily load pages and forms many times, create hundreds
to thousands of page versions in the cache eat up available memory and
possibly crash the app. This turn out difficult and I followed the well
written examples using isStateless() to track how each page and its
components are handled
https://nightlies.apache.org/wicket/guide/9.x/single.html#_stateless_pages
(a hint is to log that to a file so that one can examine the log
afterwards to examine which page is stateless and which is not)
After some time, I managed to have a trial app practically run all the
pages stateless including its forms and as I checked, it did not hit the
session for the page cache once all the pages are stateless. But simple
carelessness such as using Link can turn a page into stateful again. The
resorts are to use BookmarkablePagelinks etc, which are stateless.
After some time and refactoring, it turns out it is possible to design
forms into components and as the page creates it unwraps the reusable
components into the full page including the form, fields, feedbacks,
page decorations etc. The components often summarize otherwise a huge
amount of template htmls into perhaps a single component with <div
wickcet:id="item"> styled components which can unwrap into full blown
codes with components such as fields / inputs + html decorations
etc.This is a big win for forms, especially the complicated ones with
lots of fields.
I'm still learning the ropes and it is a well designed and trodden
framework, many things still to visit.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Andrea Del Bene.
Apache Wicket committer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
