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] >
