Re: How it Feels to Learn Javascript in 2016
Andrea Del Bene-3 wrote > Go straight to slide 26 of my presentation :-D > > http://events.linuxfoundation.org/sites/events/files/slides/Wicket_The_story_so_far_and_beyond.pdf Yes, I went to that link via ur slides .. I forgot that to mention. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-it-Feels-to-Learn-Javascript-in-2016-tp4676883p4676918.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
How it Feels to Learn Javascript in 2016
Must read article if you are thinking to start new app development in Java script world. Also read the comments below, how many of them had echoed the same concerns.. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.gkg3u1pdp Wicket is so easy to develop and maintain.. Thank you Guys for continuing to develop & support Wicket .. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-it-Feels-to-Learn-Javascript-in-2016-tp4676883.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 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 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
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
Re: Wicket vs JS frameworks.
Thanks Martin for the reply. Understood the points conveyed. Martin Grigorov-4 wrote > It scales with the knowledge of the engineers. > It is not just Wicket when you need big scale application. > It goes from the OS configuration, to the selection of the databases, the > web server config and good application code. Is there any place or topic, where we consolidate all best practices & learnings ? Martin Grigorov-4 wrote > I personally try to use only technologies that *I* like, not because the > marketing team of some company said that their product is the best. Yes, agreed. But not just marketing team of that company, the industry trend is more towards those JS frameworks like Angular, React etc.. So wanted to know where do Wicket stand against those.. We wil be in a better position to answer questions down the line.. As an Architect when you make decisions, you need to stand by those and prove it.. This topic was intended to clarify & get more insights to be able to make decision. - fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675798.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 vs JS frameworks.
>From the posts so far this is what i understand.. 1. JS based apps are best suited for high scale applications.. It is worth the effort you take to build and maintain such apps.. 2. Wicket can scale only to certain extent based on the server capacity ? If so how to quantify ? (What about load balancing ? What about stateless pages ? Why it does not scale ?) 3. JS based apps resource availability is plenty.. So for new projects better to go with these ? - What if the maintaining these apps becomes tedious due the cons of these JS discussed earlier. May be some more insights will help us all understand, how to choose what depending on the scenarios in hand. - fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675796.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 vs JS frameworks.
Tobias Soloschenko wrote > I think because Wicket uses HTML5 and Java you can combine JS Frameworks > with many of the features of Wicket. Example: Because you have a java > backend you can build a rest API with wicket-rest-annotations and > configure your Angular JS to work with it - if you have a page change you > could use Wicket components and even the pages could be served with Wicket > containing the Angular content. Yes, we can embed some components from React or Angular if this works. But again maintaining compatibility over release cycles is an issue.. If there was some built in mechanism in wicket, it would be ideal. Is any one attending this conf ? ApacheCon Europe 2016 https://apacheconeu2016.sched.org/event/8UL4?iframe=no May be he might touch up on these topics ? If any one attend, please post .. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675785.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 vs JS frameworks.
Ernesto Reinaldo Barreiro-4 wrote > 2- In some places, companies I have worked for as consultant, I have seen > projects that they considered complex because the JS paraphernalia. They > were be just trivial using Wicket. The sad thing is they did not have any > need to scale. So, something like wicket was more than a perfect fit. Very much true. I am working on a system, where it is a mid or small (100 to 250 users) scaling requirement... I felt wicket is more than sufficient for this. But I do have some issues, i will post a separate topic on the issues to get clarified. This is more general topic. Ernesto Reinaldo Barreiro-4 wrote > They all used REST and some JS machinery (they also did not plan for > mobile so > REST was not needed). Some of these applications were not very DRY... and > REST layer was kind of a mess where you never knew for sure what was > actually used and not. REST should not be a criteria for going with JS based systems. We do have mobile apps, we expose REST services using Spring. We dont need the same data in web & mobile most of the time. For mobile it is very much limited. So having a separate REST layer works well. Lets wait n hear from some more experts on this topic. People who had done lot of apps on JS side & Wicket side will be a good candidate, not being Biased :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675783.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
Wicket vs JS frameworks.
Hi, I am a fan of Wicket & had been working on for last 6 to 7 yrs using the same. Recently had evaluated few frameworks Angular, ReactJS etc in view of developing new applications, I did not feel them appealing may be due to my very bad java script knowledge.. if at all i learn and start working on it, I felt I am not going to be productive on it. Currently I feel Wicket due to its Component based is very much productive and helps to give the consistency across application in terms of look n feel etc. Just thought of hearing comments from others as well .. Are those using Wicket, using other frameworks as well. Are there any combinations which works well with Wicket or otherwise. - fzb -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771.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
