Re: Wicket Appl - Cleanup & Scale
Thanks Martin for the reply. Very much answers the questions i had asked. Will try the suggestions and post update here. - fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Appl-Cleanup-Scale-tp4675820p4675859.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Hi, On Tue, Oct 18, 2016 at 2:25 AM, fzb wrote: > Hi > > > Here are few UI snaps of the application we had built using wicket. > > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/Artboard.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/ > 2016-10-17_08.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/ > 2016-10-18_08.png> > > The stack we had used to build this app are .. > > Wicket - Client > Hibernate - Persistence > ehCache - Caching > Spring - to glue all pieces together > MySql (AWS RDS) - Database > CXF - REST > Jasper - Reports > Open Flash Chart - Chart (Pending Migration to JS based) > DropWizard Metrics - to collect metrics & report > Jetty in dev & Tomcat in live server > > The Pros.. in this app > 1. Easy to maintain > 2. Easy to write custom components. > 3. Not much of browser issues since we don't use JS much except for those > which wicket does. > 4. Use heavily Ajax via Wickets approach. Nothing on our own. > 5. Consistent look n feel, since developers use pre developed with css > built in components for new screens. > > Overall meets the current requirement. > > The Top 3 problems we want to address are .. > > *1. Do not have URL for any document .. say Purchase Doc.. because it is > nested inside component hierarchy. > * > > We designed only the top level icon based navigation as Page based. Which > means to navigate from one page to another we use > setResponsePage.(newPage).. For these pages we have URLs. For the second > level menu (black bar - below the icon menu) & internal tab navigation, > going from list view to detail view etc we had use component replace .. by > repainting the container with the new content. > > cntr.addOrReplace(newComponent); > target.add(cntr); > > 90% of user interactions are via this method. Hence we are not able to > generate URLs for these internal UIs. If user needs to traverse to any of > these, then they navigate to the page.. click menu.. click tab to navigate. > Take a look at https://github.com/martin-g/blogs/tree/master/ajax-history This project shows how to use HTML5 History API to manipulate the url even for Ajax interactions. If you need deep linking since the beginning you will have to put the menus ids/names in the mount path. E.g. /level1/#{level2}/#{level3} where - level1 is the icon menu. It links to a page, as it does now. - level 2 and level 3 are optional parameters. If they are available in page.getPageParameters() then initialize the TabbedPanel active tab to match the provided value > > *2. We are using single server. We want to use a load balancer and > increase > the servers to be able to meet scaling requirement. > * > Currently we just store the user details in session, after authentication. > We need to be able to identify each request and associate session details > (from cache) to the request, so that the request can be served by either > servers.. > Normal Session replication should work just fine. But you can also take a look at https://github.com/magro/memcached-session-manager and/or https://github.com/wicketstuff/core/tree/master/datastores-parent > > > *3. Move all static contents out of war file. * > To reduce the traffic coming in to application server, we intend to move > the > static resources out of appl war file to CDN. > We have used a custom IRequestMapper that wraps Wicket's ResourceMapper that in Production mode produces CDN urls instead of .../wicket/resource/com.example.Scope/css/some-123456.css. This way all the traffic for static resources goes directly to the CDN. > > *4. It is getting bigger n bigger.. Need to avoid making it monolithic * > We wanted to develop new features as micro services and slowly break the > whole app in to.. For service layers we understand how to group > functionalities.. for UI how to we break it in to multiple ? how to regroup > them as single app for the user. > Here are some options: 1) micro services == several small apps Here the question is whether you need to share the user session between those apps. Most probably - yes 2) I think you really need build (Maven, Gradle) modules Each "microservice" lives in its own module. This module provides everything specific to this functionality. The module depends on at least to other modules: - common - provides common "glue" code - components - provides smaller Wicket components re-used in other modules and base pages Each module could register itself in the Application e.g. by using Wicket's IInitializer, or Spring's component scan, or anything else > > Addressing these 4 will take our app to the ne
Re: Wicket Appl - Cleanup & Scale
Hi, > Do you mean you had used lot of OFC or JS based charts. Can give few > choices > u had used for JS. > > I have used client based charts like Flot, http://morrisjs.github.io/morris.js/, and a few others. > Is it better to design all entities as pages ? I was worried about > reconstructing the header for each click if we were to keep redirecting > pages. Reconstructing the header requires to iterate the roles, fetching > menus, etc.. Are there ways to cache the generated components say header > in > this case and render only entity related contents. > What I said is that wicket does not enforces any pattern it all depends of your use case: either AJAX replacement or navigating to another page is fine depending on what you want to offer to your users. You can always offer a button "See details in a separate page" if you want to offer something that is bookmarkable. > > Ernesto Reinaldo Barreiro-4 wrote > >> > >> cntr.addOrReplace(newComponent); > >> target.add(cntr); > >> > >> 90% of user interactions are via this method. Hence we are not able to > >> generate URLs for these internal UIs. If user needs to traverse to any > of > >> these, then they navigate to the page.. click menu.. click tab to > >> navigate. > >> > > This is not enforced by wicket at all > > Sorry i did not get this. Can you elaborate a little bit.. Is using replace > component heavy ? As per my understanding only the changed portion of the > page gets refreshed.. This is what is being done by JS fwk like react to > compare virtual DOM & actuam DOM. In this case we are doing it, whereas in > React it does it by itself. > Again you can design your navigation as you want. Ajax (not bookmarkable) or navigation to a different page.
Re: Wicket Appl - Cleanup & Scale
There exists also java wrapper: https://github.com/jhonnymertz/java-wkhtmltopdf-wrapper On 10/18/2016 05:13 PM, Ernesto Reinaldo Barreiro wrote: Thanks for the pointer: did not know about this project :-) On Tue, Oct 18, 2016 at 4:19 PM, Vit Rozkovec wrote: I would recommend wkhtmltopdf as flying saucer does not play well with Bootstrap and CSS3 features in general. https://github.com/wkhtmltopdf/wkhtmltopdf For generating PDF I prefer flying-saucer and wicket https://github.com/reiern70/wicket-flyingsaucer - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Hi Ernest, Thanks for the feedback. Ernesto Reinaldo Barreiro-4 wrote >> Open Flash Chart - Chart (Pending Migration to JS based) > Done that a lot on my own projects and it is pretty easy with wicket Do you mean you had used lot of OFC or JS based charts. Can give few choices u had used for JS. Ernesto Reinaldo Barreiro-4 wrote >> *1. Do not have URL for any document .. say Purchase Doc.. because it is >> nested inside component hierarchy. > Yous mount a page that shows that "entity" and use the same panel if it > makes sense. Is it better to design all entities as pages ? I was worried about reconstructing the header for each click if we were to keep redirecting pages. Reconstructing the header requires to iterate the roles, fetching menus, etc.. Are there ways to cache the generated components say header in this case and render only entity related contents. Ernesto Reinaldo Barreiro-4 wrote >> >> cntr.addOrReplace(newComponent); >> target.add(cntr); >> >> 90% of user interactions are via this method. Hence we are not able to >> generate URLs for these internal UIs. If user needs to traverse to any of >> these, then they navigate to the page.. click menu.. click tab to >> navigate. >> > This is not enforced by wicket at all Sorry i did not get this. Can you elaborate a little bit.. Is using replace component heavy ? As per my understanding only the changed portion of the page gets refreshed.. This is what is being done by JS fwk like react to compare virtual DOM & actuam DOM. In this case we are doing it, whereas in React it does it by itself. Thank you. Regards Fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Appl-Cleanup-Scale-tp4675820p4675827.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Thanks for the pointer: did not know about this project :-) On Tue, Oct 18, 2016 at 4:19 PM, Vit Rozkovec wrote: > I would recommend wkhtmltopdf as flying saucer does not play well with > Bootstrap and CSS3 features in general. > > https://github.com/wkhtmltopdf/wkhtmltopdf > > For generating PDF I prefer flying-saucer and wicket >> >> https://github.com/reiern70/wicket-flyingsaucer >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
Re: Wicket Appl - Cleanup & Scale
I would recommend wkhtmltopdf as flying saucer does not play well with Bootstrap and CSS3 features in general. https://github.com/wkhtmltopdf/wkhtmltopdf For generating PDF I prefer flying-saucer and wicket https://github.com/reiern70/wicket-flyingsaucer - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Hi, My answers inline Here are few UI snaps of the application we had built using wicket. > > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/Artboard.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/20 > 16-10-17_08.png> > <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/20 > 16-10-18_08.png> > > Nice. > The stack we had used to build this app are .. > > Wicket - Client > Hibernate - Persistence > ehCache - Caching > Spring - to glue all pieces together > MySql (AWS RDS) - Database > CXF - REST > Normally mount resource in Wicket for my limited REST like needs (mostly get back some JSON) > Jasper - Reports > For generating PDF I prefer flying-saucer and wicket https://github.com/reiern70/wicket-flyingsaucer > Open Flash Chart - Chart (Pending Migration to JS based) > Done that a lot on my own projects and it is pretty easy with wicket > Overall meets the current requirement. > > The Top 3 problems we want to address are .. > > *1. Do not have URL for any document .. say Purchase Doc.. because it is > nested inside component hierarchy. > * > Yous mount a page that shows that "entity" and use the same panel if it makes sense. > > We designed only the top level icon based navigation as Page based. Which > means to navigate from one page to another we use > setResponsePage.(newPage).. For these pages we have URLs. For the second > level menu (black bar - below the icon menu) & internal tab navigation, > going from list view to detail view etc we had use component replace .. by > repainting the container with the new content. > Add a button see in a different page... as mentioned above. Wicket is not a limitation there. > > cntr.addOrReplace(newComponent); > target.add(cntr); > > 90% of user interactions are via this method. Hence we are not able to > generate URLs for these internal UIs. If user needs to traverse to any of > these, then they navigate to the page.. click menu.. click tab to navigate. > This is not enforced by wicket at all > > *4. It is getting bigger n bigger.. Need to avoid making it monolithic * > We wanted to develop new features as micro services and slowly break the > whole app in to.. For service layers we understand how to group > functionalities.. for UI how to we break it in to multiple ? how to regroup > them as single app for the user. > Something similar to OSGI? Or modules that contribute elements at some points at the UI. https://code.google.com/archive/p/antilia/wikis/OSGiPowered.wiki > > Addressing these 4 will take our app to the next level. Please give your > suggestions on these .. > > - fzb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > View this message in context: http://apache-wicket.1842946.n > 4.nabble.com/Wicket-Appl-Cleanup-Scale-tp4675820.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
Wicket Appl - Cleanup & Scale
Hi Here are few UI snaps of the application we had built using wicket. <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/Artboard.png> <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/2016-10-17_08.png> <http://apache-wicket.1842946.n4.nabble.com/file/n4675820/2016-10-18_08.png> The stack we had used to build this app are .. Wicket - Client Hibernate - Persistence ehCache - Caching Spring - to glue all pieces together MySql (AWS RDS) - Database CXF - REST Jasper - Reports Open Flash Chart - Chart (Pending Migration to JS based) DropWizard Metrics - to collect metrics & report Jetty in dev & Tomcat in live server The Pros.. in this app 1. Easy to maintain 2. Easy to write custom components. 3. Not much of browser issues since we don't use JS much except for those which wicket does. 4. Use heavily Ajax via Wickets approach. Nothing on our own. 5. Consistent look n feel, since developers use pre developed with css built in components for new screens. Overall meets the current requirement. The Top 3 problems we want to address are .. *1. Do not have URL for any document .. say Purchase Doc.. because it is nested inside component hierarchy. * We designed only the top level icon based navigation as Page based. Which means to navigate from one page to another we use setResponsePage.(newPage).. For these pages we have URLs. For the second level menu (black bar - below the icon menu) & internal tab navigation, going from list view to detail view etc we had use component replace .. by repainting the container with the new content. cntr.addOrReplace(newComponent); target.add(cntr); 90% of user interactions are via this method. Hence we are not able to generate URLs for these internal UIs. If user needs to traverse to any of these, then they navigate to the page.. click menu.. click tab to navigate. *2. We are using single server. We want to use a load balancer and increase the servers to be able to meet scaling requirement. * Currently we just store the user details in session, after authentication. We need to be able to identify each request and associate session details (from cache) to the request, so that the request can be served by either servers.. *3. Move all static contents out of war file. * To reduce the traffic coming in to application server, we intend to move the static resources out of appl war file to CDN. *4. It is getting bigger n bigger.. Need to avoid making it monolithic * We wanted to develop new features as micro services and slowly break the whole app in to.. For service layers we understand how to group functionalities.. for UI how to we break it in to multiple ? how to regroup them as single app for the user. Addressing these 4 will take our app to the next level. Please give your suggestions on these .. - fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Appl-Cleanup-Scale-tp4675820.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org