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]
