Guys, please do not rush, let me think a bit. -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095
On Mon, Aug 27, 2012 at 12:55 PM, [email protected] <[email protected]> wrote: > 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]
