> 1) Displaying of lists: configuration, language labels, rooms etc. Maybe we should use java management API and embed the existing management console? Maybe we should ship admin as a separate release bundle? Splitting will help re-using other technologies. Maybe we should ask designer guys on look & feel concept, and apply it to our product?
-- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Tue, Aug 28, 2012 at 1:45 PM, Alexei Fedotov <[email protected]> wrote: > I do not stop people from volunteering. My thanks to Maxim for 1) > proactivity; 2) good technology choice. > > I missed few items, Maxim told the first one is somewhere in the thread. > 1. Why not to recompile OpenLaszlo to DHTML? > 2. What is the plan and is it actually doable? What is time estimate? > > My friend who worked for our competior told me that they have > re-written design four times during the last for years. We don't have > resources for this. So my suggestion would be the following: > 1. Find Openmeetings usability problems or most wanted features. Maybe > Marco can help. > 2. Develop that using new technology, making minor adjustments to > already working things. > > So main concerns > 1. It make little sense copying existing workflow. It adds value to > improve the workflow. > 2. We need to add value to the product on any step. That makes us > user-oriented, not technology oriented. > > How good wicket is with jquery? It does not seem to work with jquery > out of the box. > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Tue, Aug 28, 2012 at 11:51 AM, [email protected] > <[email protected]> wrote: >> What are your alternatives? >> There are already people volunteering to start contributing to it. >> It can be realized without breaking functionality, we still have the >> Flash interface available while we build DHTML. >> >> Thanks! >> Sebastian >> >> 2012/8/28 Alexei Fedotov <[email protected]>: >>> 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] >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected]
