You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by fzb <na...@bzforce.com> on 2016/10/18 00:25:48 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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
Posted by fzb <na...@bzforce.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Posted by Vit Rozkovec <ro...@email.cz>.
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 <ro...@email.cz> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Thanks for the pointer: did not know about this project :-)
On Tue, Oct 18, 2016 at 4:19 PM, Vit Rozkovec <ro...@email.cz> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Wicket Appl - Cleanup & Scale
Posted by Vit Rozkovec <ro...@email.cz>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Wicket Appl - Cleanup & Scale
Posted by fzb <na...@bzforce.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Appl - Cleanup & Scale
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Oct 18, 2016 at 2:25 AM, fzb <na...@bzforce.com> 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 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>