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
