Hello Sebastian, I agree we need to use Ajax to make pages smooth. But I thought about multiple pages to make page bookmarking available. The main page of wicket application is currently mapped to: http://localhost:5080/openmeetings/html For example I would like to make following pages: html -- dashboard html/signin html/logout html/calendar html/admin/users etc ...
all navigations/loadings will be via Ajax inside the pages above. Chat will be present as component added to the footer of the main page. (all other pages will derive from it) On Sat, Sep 1, 2012 at 2:50 PM, [email protected] <[email protected] > wrote: > Hi Maxim, > > thanks for adding the Wicket components! > > I would like to discuss some basic architectural questions of the > website before we are going to implement the modules in detail. > What is important to me it that we build a Single Page Application > (SPA). That means instead of generating links to subpages that > completely re-render the whole page we replace components/fragements > of the website at runtime. > From my point of view that is very important as we have a number of > components that should stay the same or initialized at runtime. > For example the Chat window should stay open no matter where you > navigate to. Or for example in the conference room you can create new > instance of the whiteboard. There is no chance to reload everything > just to add or remove a component. > > So I would like to create/find consens about a basic mechanism of how > to load and create fragements of the website at runtime in Apache > Wicket. > One solution is to load all components and only make the visible when > you need them. I don't think that this is a solution for us as we just > have too many components. Also I think it would be better to load at > runtime so that it is possible to create some kind of plugin loader > mechanism later. > So now comes the issue: How to realize a dynamic component loader in > Wicket? How to integrate that into our layout? > > Practically it would mean we have a single "Main.html" and "Main.java" > and from that one it links / dynamically loads the sub components via > Ajax. > That means that we internally of course have sub-pages, however they > are loaded via Ajax. > There is an example with Modal Dialogue's in Wickets Ajax library: > http://www.wicket-library.com/wicket-examples/ajax/modal-window?9 > A similar mechanism should be realized when you click on our main menu > and load the content for each sub-section (like user-administration, > dashboard, room-list, et cetera). > > What do you think, did you run into a similar problem yet? > > Thanks! > Sebastian > > 2012/8/30 Maxim Solodovnik <[email protected]>: > > I did create my own SignIn page ant set it in Application derived from > > AuthenticatedWebApplication and perform login based on the credentials > > entered. > > > > On Thu, Aug 30, 2012 at 4:56 PM, Oliver becherer > > <[email protected]> wrote: > >> > >> kay, i see... > >> > >> are you using IAuthorizationStrategy Interface? i found that very handy > in setting up wicket apps, since it's easy to extend, when starting > >> with page based navigation rules and later on expanding to component > based/ action based authentication/navigation rules... > >> > >> it's also quite good when its planned to provide deep links into the > application, throwing user back to login page with > RestartResponseAtInterceptPageException in case he's not authenticated and > redirecting him to deep link page after login... > >> > >> > >> thanks for the update! > >> > >> O > >> > >> Am 30.08.2012 um 11:18 schrieb Maxim Solodovnik: > >> > >>>> for a better understanding : why is the login performed with jQuery > instead of the default Authentication mechanisms provided by wicket? > >>> > >>> Standard Wicket login page was replaced with custom form so login via > >>> LDAP can be implemented. > >>> Login is not performed using jQuery, login form is just wrapped with > >>> jQuery dialog to look similar to current Om login dialog. > >>> > >>> On Thu, Aug 30, 2012 at 4:14 PM, Oliver becherer > >>> <[email protected]> wrote: > >>>> > >>>> hi, > >>>> > >>>> this is great news for me - unfortunately, i've been inactive for a > long time in OM now, but will try to catch up with you guys. > >>>> > >>>> -> Implementing Wicket as UI technology is perfect way to go, in my > opinion, since we can reduce the technology stack for developing OM on the > long run (as soon as openLaszlo is no longer required in future times ^^). > >>>> > >>>> Chapeau! from my side... > >>>> > >>>> for a better understanding : why is the login performed with jQuery > instead of the default Authentication mechanisms provided by wicket? > >>>> > >>>> > >>>> thanks! > >>>> > >>>> > >>>> O > >>>> > >>>> > >>>> Am 30.08.2012 um 09:53 schrieb Maxim Solodovnik: > >>>> > >>>>> I have no public server to run this. > >>>>> You can run it locally: > >>>>> > >>>>> 1) svn up > >>>>> 2) edit web.xml (uncomment Wicket Filter) > >>>>> 3) ant -Ddb=mysql > >>>>> 4) http://localhost:5080/openmeetings > >>>>> > >>>>> On Thu, Aug 30, 2012 at 2:42 PM, Alexei Fedotov > >>>>> <[email protected]> wrote: > >>>>>> Maxim, that's great! > >>>>>> Can I check a demo somewhere? > >>>>>> > >>>>>> -- > >>>>>> With best regards / с наилучшими пожеланиями, > >>>>>> Alexei Fedotov / Алексей Федотов, > >>>>>> http://dataved.ru/ > >>>>>> +7 916 562 8095 > >>>>>> > >>>>>> > >>>>>> On Wed, Aug 29, 2012 at 10:50 PM, Maxim Solodovnik < > [email protected]> wrote: > >>>>>>> Just have commited Initial "HelloWorld" OM Wicket application (to > use > >>>>>>> need to uncomment wicket filter in web.xml) > >>>>>>> > >>>>>>> What was done: > >>>>>>> 1) Wicket is starts and handle pages > >>>>>>> 2) All OM labels are displayed from DB > >>>>>>> 3) You can login using your OM username/pass (login dialog uses > jQuery > >>>>>>> UI dialog) > >>>>>>> 4) OM user levels are in effect (user or admin) > >>>>>>> 5) OM Navi menu is displayed from the DB > >>>>>>> 6) Navi link to Admin users page displays stub for admin users page > >>>>>>> > >>>>>>> What was not done: > >>>>>>> 1) wicket currently handles all URLs (this is why it is currently > commented) > >>>>>>> 2) Entity list is not displayed from the DB as paged table (going > to > >>>>>>> do as next task) > >>>>>>> > >>>>>>> Please take a look and tell me what do you think? > >>>>>>> > >>>>>>> On Tue, Aug 28, 2012 at 5:08 PM, [email protected] > >>>>>>> <[email protected]> wrote: > >>>>>>>> There have been no votes against using OpenLaszlo and compile to > >>>>>>>> DHTML. However the OpenLaszlo project seems currently no more > >>>>>>>> maintained. There has been no release since 2010 of the project. > The > >>>>>>>> comunity has downsized by factor of 10. > >>>>>>>> This is the community activity in the last years: > >>>>>>>> > http://www.openlaszlo.org/pipermail/laszlo-dev/2012-June/024912.html > >>>>>>>> > >>>>>>>> It is likely that if we are switching to DHTML that we will run > into > >>>>>>>> issues as soon as new browser features of HTML5 will come up as > the > >>>>>>>> Openlaszlo platform does not implement them. It would be actually > our > >>>>>>>> task not only to develop OpenMeetings but also OpenLaszlo. > >>>>>>>> > >>>>>>>> As DHTML compilation is a quite future orientated task I think we > >>>>>>>> should choose technology that support mobile devices and > constantly > >>>>>>>> improves its cross-browser capibilities. > >>>>>>>> > >>>>>>>> And last but not least the question is of course: How can we > attract > >>>>>>>> new users? Chossing OpenLaszlo does actively look-out people as > they > >>>>>>>> are not willing to learn it. We will have much better chances to > find > >>>>>>>> new contributors if we choose a technology people are familiar > with. > >>>>>>>> > >>>>>>>> jQuery and Wicket do not bundle out of the box, simply because > jQuery > >>>>>>>> is an UI framework and Wicket is a server side framework. There > are > >>>>>>>> projects and components that combine jQuery and Wicket > >>>>>>>> code.google.com/p/wiquery/ > >>>>>>>> code.google.com/p/jqwicket/ > >>>>>>>> code.google.com/p/wickext/ > >>>>>>>> code.google.com/p/wicket-jquery-ui/ > >>>>>>>> www.7thweb.net/jquery-ui-samples/ > >>>>>>>> > >>>>>>>> And those are only the "projects" actually combining those > >>>>>>>> technologies needs nothing more then an import statement of the > jQuery > >>>>>>>> library in the page header. > >>>>>>>> > >>>>>>>> *It make little sense copying existing workflow. It adds value to > >>>>>>>> improve the workflow.* > >>>>>>>> => I agree on that, however Flash is dead. We have to provide a > DHTML > >>>>>>>> alternative. We will not replace our server side workflow. > >>>>>>>> > >>>>>>>> *We need to add value to the product on any step. That makes us > >>>>>>>> user-oriented, not technology oriented.* > >>>>>>>> => We will keep existing Flash frontend as long as its needed. It > is > >>>>>>>> my intention to have a running OpenMeetings package all the time. > >>>>>>>> > >>>>>>>> *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?* > >>>>>>>> => Sorry but now you are actually the one the broadens the whole > >>>>>>>> discussion to a much larger scale. > >>>>>>>> I agree with you that we need to define small steps to improve > our project. > >>>>>>>> But having more modularization like "separate release bundle" has > >>>>>>>> actually nothing to do with DHTML compilation. It is just another > >>>>>>>> topic. Same as "ask designer guys on look & feel concept". > >>>>>>>> This is just not the topic of DHTML or not. You can do it > regardless > >>>>>>>> if you compile DHTML or Flash. > >>>>>>>> > >>>>>>>> Sebastian > >>>>>>>> > >>>>>>>> 2012/8/28 Alexei Fedotov <[email protected]>: > >>>>>>>>> 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] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Sebastian Wagner > >>>>>>>> https://twitter.com/#!/dead_lock > >>>>>>>> http://www.webbase-design.de > >>>>>>>> http://www.wagner-sebastian.com > >>>>>>>> [email protected] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> WBR > >>>>>>> Maxim aka solomax > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> WBR > >>>>> Maxim aka solomax > >>>> > >>> > >>> > >>> > >>> -- > >>> WBR > >>> Maxim aka solomax > >> > > > > > > > > -- > > 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
