That sounds good. Do you want to create a new branch for the DHTML tree or will trunk become the DHTML tree and we create a 2.1 branch ?
Sebastian 2012/8/27 Maxim Solodovnik <[email protected]>: > We need to add following lines to our ivy.xml: > > <dependency org="org.apache.wicket" name="wicket-core" > rev="6.0.0-beta3" conf="openmeetings->*"/> > > and that is all > > I can create "sample Om main page" and them both of as can add components to > it. > > On Mon, Aug 27, 2012 at 3:38 PM, [email protected] > <[email protected]> wrote: >> 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] > > > > -- > WBR > Maxim aka solomax -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
