Ok 2012/8/27 Maxim Solodovnik <[email protected]>: > I prefer develop in trunk. I would vote for this > On Aug 27, 2012 3:49 PM, "[email protected]" <[email protected]> > wrote: > >> 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] >>
-- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
