Re: Apache Wicket is a very good framework
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, 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 styled components which can unwrap into full blown codes with components such as fields / inputs + html decorations etc.This is a big win
Re: Apache Wicket is a very good framework
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, 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 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: [email protected] > For additional commands, e-mail: [email protected] > > Andrea Del Bene. Apache Wicket committer.
Re: Apache Wicket is a very good framework
Yes it is! Thanks for sharing > On Apr 14, 2025, at 5:03 PM, andrew goh 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 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: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Apache Wicket is a very good framework
Thanks for the good words about Wicket. Framework is old but still alive... I'm sure our little community will help you with any problems you find along the way. On Mon, Apr 14, 2025 at 5:04 PM andrew goh 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 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards - Ernesto Reinaldo Barreiro
Re: Apache Wicket is a very good framework
Awesome write up, Andrew! Thanks for sharing your experiences. Martijn On Tue, Apr 15, 2025 at 12:04 AM andrew goh 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 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
