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]
