Wickets standard project setup require Maven. What is your proposal to integrate Wicket into the current stack?
Sebastian 2012/8/27 Maxim Solodovnik <[email protected]>: > I don't really understand why do we need maven? > Why ant+ivy is not enough? > I always thought it is similar tools. > > Could you please explain it? > > On Mon, Aug 27, 2012 at 2:10 PM, [email protected] > <[email protected]> wrote: >> Well lets give it a try with Wicket. >> However when it comes to the real collaboration and UI effects I think >> we will heavily use jQuery. >> We will first have to integrate our application in a Maven styled project. >> >> I guess we can still use ANT to compile certain aspect of our >> application, Maven can trigger ANT build scripts. >> http://maven.apache.org/plugins/maven-antrun-plugin/ >> seems to be a perfect tool for us. >> However some of the Ivy dependency management might be difficult to >> set up. Lets try that out. >> >> Sebastian >> >> 2012/8/27 Maxim Solodovnik <[email protected]>: >>> Hello Sebastian, >>> >>> sorry for the late reply (was out of city with no internet access) >>> While proposing using Apache Wicket I thought of following: >>> >>> 1) Displaying of lists: configuration, language labels, rooms etc. >>> 2) Use of Ajax to refresh only parts of page displayed. >>> >>> We definitely can use JS libraries (like jQuery UI) only but this will >>> make code less readable. I believe Apache Wicket will be good for >>> Admin menu etc. And we can easily add jQuery UI to it. >>> >>> Instead of Wicket we can use Spring MVC and Velocity. >>> I have proposed Wicket only because I have more experience with it and >>> from my point of view it is easy to maintain. >>> >>> On Mon, Aug 27, 2012 at 12:23 AM, [email protected] >>> <[email protected]> wrote: >>>> After some discussion I would like to propose to integrate Apache >>>> Wicket and try it out. >>>> I have update the document: >>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal >>>> Please add your notes. >>>> >>>> Thanks >>>> Sebastian >>>> >>>> 2012/8/24 [email protected] <[email protected]>: >>>>> This would be my proposal: >>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal >>>>> >>>>> 2012/8/24 [email protected] <[email protected]>: >>>>>> What if we instead of Apache Wicket use Apache Velocity to provide the >>>>>> basic structure of the HTML websites? >>>>>> All dynamically loaded data, rendering of items could be then done by >>>>>> jQuery. >>>>>> That way we will have a set of html templates to work on and a UI >>>>>> framework to manipulate it. >>>>>> >>>>>> Sebastian >>>>>> >>>>>> 2012/8/24 [email protected] <[email protected]>: >>>>>>> I would like to share this use-case >>>>>>> >>>>>>> In the next iteration I would like to put the Chat box as a permanent >>>>>>> box similar to what is in Google+ and Facebook on the bottom. >>>>>>> That mean no matter where you go, admin section, room list, dashboard >>>>>>> => the chat always stays the same, so a complete page refresh is not >>>>>>> possible. >>>>>>> I would simply replace the DIV that contains the main content with new >>>>>>> one when switching between main menu entries. >>>>>>> >>>>>>> What do you think about that? >>>>>>> How would that affect the framework discussion? >>>>>>> >>>>>>> Sebastian >>>>>>> >>>>>>> 2012/8/24 [email protected] <[email protected]>: >>>>>>>> When it comes to rendering and UI component frameworks you come to >>>>>>>> projects like: >>>>>>>> code.google.com/p/wiquery >>>>>>>> http://www.7thweb.net/jquery-ui-samples/ >>>>>>>> >>>>>>>> Simple search for "Apache Wicket UI samples" and you find tons of >>>>>>>> jQuery examples that are used in Apache Wicket. >>>>>>>> >>>>>>>> So from my point of view Apache Wicket is simply no UI framework. It >>>>>>>> is a web-framework. How things render is not part of it. Practically >>>>>>>> it might mean that we could combine Apache Wicket with jQuery too. But >>>>>>>> why use Apache Wicket then at all? We have already a backend with Rest >>>>>>>> Services and everything. Wicket would duplicate that. What parts of >>>>>>>> Wicket would we really use? >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>>> 2012/8/24 [email protected] <[email protected]>: >>>>>>>>> Can you show examples of Apache Wicket UI widgets and animation? >>>>>>>>> >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>> 2012/8/24 Maxim Solodovnik <[email protected]>: >>>>>>>>>> I would recommend to review Apache Wicket. >>>>>>>>>> It is MVC it has lots of UI components like paged lists table views >>>>>>>>>> etc. >>>>>>>>>> It had built-in AJAX support. >>>>>>>>>> >>>>>>>>>> In general I'll vote for moving to DHTML >>>>>>>>>> On Aug 24, 2012 3:57 PM, "[email protected]" >>>>>>>>>> <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I would like to start a discussion about options to migrate and a >>>>>>>>>>> Roadmap for the upcomfing versions. >>>>>>>>>>> >>>>>>>>>>> This is our current situation: >>>>>>>>>>> We currently have two client side application a) + b) >>>>>>>>>>> a) Audio/Video related stuff is all the SWF10 app >>>>>>>>>>> b) whiteboard, administration + all the rest in the SWF8 app. >>>>>>>>>>> The two SWFs communicate via LocalConnection with each other. >>>>>>>>>>> >>>>>>>>>>> There are three options from my point of view: >>>>>>>>>>> 1) refactor the SWF8 app to SWF11 and keep the LocalConnection >>>>>>>>>>> 2) refactor the SWF8 and merge SWF8 with SWF10 app to a single SWF11 >>>>>>>>>>> app and get rid of the LocalConnection workaround >>>>>>>>>>> 3) refactor the SWF8 app to HTML5 and only use SWF for the >>>>>>>>>>> audio/video >>>>>>>>>>> part. >>>>>>>>>>> >>>>>>>>>>> option 1 is the easiest thing to do >>>>>>>>>>> option 2 is the best from architecture point of view >>>>>>>>>>> option 3 is the best for moving to HTML5 >>>>>>>>>>> >>>>>>>>>>> From my point of view it would be the best option to start DHTML >>>>>>>>>>> refactoring now (in a version 3.0 branch) and release the current >>>>>>>>>>> trunk tree (as version 2.1). >>>>>>>>>>> >>>>>>>>>>> For the transition to DHTML we have several options: >>>>>>>>>>> I) Refactor to DHTML using OpenLaszlo >>>>>>>>>>> II) Refactor to DHTML using a JavaScript framework (jQuery, Dojo, >>>>>>>>>>> Apache Wicket, Spring+MVC) >>>>>>>>>>> >>>>>>>>>>> My personal preference is using jQuery. It provides components for >>>>>>>>>>> UI >>>>>>>>>>> and animation and is the most widespread. From a project point of >>>>>>>>>>> view >>>>>>>>>>> it will be more easy to attract new developers if they can use tools >>>>>>>>>>> that they are comfortable in. And I really don't want to code a >>>>>>>>>>> client >>>>>>>>>>> side application that requires heavy usage of the page-refresh. That >>>>>>>>>>> would be like moving back in time. >>>>>>>>>>> >>>>>>>>>>> There are some architectural questions that we should discuss for >>>>>>>>>>> the >>>>>>>>>>> JavaScript refactoring. >>>>>>>>>>> However there should be some kind of consens on the overall RoadMap >>>>>>>>>>> first. >>>>>>>>>>> >>>>>>>>>>> So what do you think? >>>>>>>>>>> >>>>>>>>>>> Sebastian >>>>>>>>>>> -- >>>>>>>>>>> Sebastian Wagner >>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sebastian Wagner >>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> http://www.webbase-design.de >>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sebastian Wagner >>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>> http://www.webbase-design.de >>>>>>>> http://www.wagner-sebastian.com >>>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sebastian Wagner >>>>>>> https://twitter.com/#!/dead_lock >>>>>>> http://www.webbase-design.de >>>>>>> http://www.wagner-sebastian.com >>>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Wagner >>>>>> https://twitter.com/#!/dead_lock >>>>>> http://www.webbase-design.de >>>>>> http://www.wagner-sebastian.com >>>>>> [email protected] >>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> [email protected] >>>> >>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> [email protected] >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] > > > > -- > WBR > Maxim aka solomax -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
