And of course while the page is loading you won't be able to chat :) 2012/9/1 [email protected] <[email protected]>
> I see the URL problem not really that relevant then the issue of loosing > the users scope. > WebSockets are permanent connections, they basically have a similar > architecture then the NetConnection in Flash: > > https://cwiki.apache.org/WICKET/wicket-native-websockets.html#WicketNativeWebSockets-ClientsideAPIs > You have to open/close a WebSocket. That means as soon as a user clicks on > a link and reloads the page, he will have to close the WebSocket. During > that time he will not receive any events. After he has reloaded the page > you somehow will have to magically find out what happened while loading the > page. > In case of a chat this might be solved cause you can save a server side > chat history and reload that all the time. But of course you loose for > example other information, you literaly have to store each and every state > on the server side, for example chat box position, height, width > everything, just to recreate the whole chat window in case of a page reload. > You could do the same with other components. But I don't think that it > will make life practically more easy by doing it. And I think it is very > ugly to reload all components all the time. Why having such a history and > store all components state and layout anyhow? > Being able to bookmark a sub-page is no criteria for me that would decide > if doing Single or Multi Page Design. > > Sebastian > > 2012/9/1 Maxim Solodovnik <[email protected]> > >> Also in case we need to calculate which blocks need to be displayed wрich >> time it will complicate the logic and will require additional computing >> time >> >> On Sat, Sep 1, 2012 at 9:25 PM, Maxim Solodovnik <[email protected] >> >wrote: >> >> > Ye you are right. >> > Modules can be created as Wicket panels and maintained this way. >> > But in case of pages you need to find a page and you will get all its >> > components, in case of panels you have only 1 page and you need to >> guess, >> > which panel need to be modified etc. >> > >> > I agree it is no problem to construct a page using panels >> > It is also possible to parse incoming URL (it is made automatically by >> > PageParameters object) >> > but it will be very hard to show URL need to be bookmarked (I believe it >> > will be impossible using both JS and Wicket, since changing the URL >> always >> > mean page reload) >> > >> > I still think multipage is both" developer friendly" and "user >> friendly". >> > I'll try to implement the chat (since it is "key" component) and see if >> it >> > will be possible. >> > >> > Current structure of pages is: >> > >> > *abstract BasePage* (the main page with no authorization, with OM >> header, >> > logo name etc.) >> > *SignInPage extends BasePage* (page with no authorization displaying >> > login form) >> > >> > *abstract class UserPage extends BasePage* (page with no body available >> > for authenticated users with permission level: USER) >> > *MenuPage extends UserPage *(page providing main menu and top links >> > logout, profile etc.) >> > *abstract class AdminPage extends MenuPage* (page with no body available >> > for authenticated users with permission level: ADMIN) >> > *UsersPage extends AdminPage* (page providing functionality for managing >> > users, partially on Ajax, need to be refactored) >> > >> > I really like the idea of having common functionality in base classes >> and >> > to have multiple pages. >> > I believe it will simplify lots of things. >> > >> > Also I guess in case of multitab all tabs need to reside in memory (no >> > matter displayed or not) this might enlarge the time page need to >> render. >> > >> > >> > On Sat, Sep 1, 2012 at 8:56 PM, [email protected] < >> > [email protected]> wrote: >> > >> >> What should be harder to maintain in a single page design? >> >> >> >> Have a look at the AjaxTabbedPanel in Wicket and this example: >> >> >> >> >> http://javathoughts.capesugarbird.com/2007/11/ajax-tabbed-panel-with-lazy-loading.html >> >> >> >> It actually will create regular sub-pages (TabOne/TabTwo). So having a >> >> Single Page Design in the client has nothing todo with how many pages >> you >> >> have on Wicket server side to maintain. >> >> So you still have 3 HTML websites that you can style, maintain and code >> >> separated. >> >> So from mudularization and maintenance I see no difference. >> >> >> >> The same can be done with what we have now, we only need to have a Menu >> >> instead of a Tabbar and use that to load the components. >> >> >> >> Sebastian >> >> >> >> 2012/9/1 Maxim Solodovnik <[email protected]> >> >> >> >> > Single page application will be really to maintain. >> >> > Single page application will be really hard to maintain. >> >> > >> >> > sorry >> >> > >> >> > On Sat, Sep 1, 2012 at 8:16 PM, Maxim Solodovnik < >> [email protected] >> >> > >wrote: >> >> > >> >> > > I'll read about real time communication (have no experience with >> it) >> >> > > Single page application will be really to maintain. >> >> > > I'll try to create simple chat example to test how does it fit into >> >> > > multipage (most probably in the beginning of the next week) >> >> > > >> >> > > >> >> > > On Sat, Sep 1, 2012 at 8:04 PM, [email protected] < >> >> > > [email protected]> wrote: >> >> > > >> >> > >> I agree that there might be exceptions: >> >> > >> For example the SignIn.html could stay an extra page. No need to >> >> bother >> >> > >> the >> >> > >> application with authentication stuff for now. >> >> > >> Also as in the SignIn process there is no need for >> >> > RealTime-Communication. >> >> > >> But for the rest, I don't see another way, then doing it with a >> >> > >> Single-Page >> >> > >> Design. >> >> > >> >> >> > >> Sebastian >> >> > >> >> >> > >> 2012/9/1 [email protected] <[email protected]> >> >> > >> >> >> > >> > If you have multiple pages the chat will refresh everytime you >> >> change >> >> > >> the >> >> > >> > menu entry. It is also just an example, we could also have other >> >> > >> real-time >> >> > >> > updated components that should stay throughout the whole >> session. >> >> You >> >> > >> can >> >> > >> > hardly push messages to a websites if the user constantly could >> >> > >> > refresh/re-enter the website. >> >> > >> > I guess WebSockets also require you to stay on the same website >> all >> >> > the >> >> > >> > time, and not switch permanently from one page to another. >> >> Otherwise >> >> > you >> >> > >> > would constantly re-open the socket and close it xxx times when >> the >> >> > user >> >> > >> > browse's the website. >> >> > >> > Page Refresh + WebSockets/Real time communication just does not >> fit >> >> > >> > together from my point of view. >> >> > >> > >> >> > >> > I think you can also access the browser's URL by using >> JavaScript. >> >> For >> >> > >> > example you could read also the GET parameters of the URL and >> >> based on >> >> > >> that >> >> > >> > send the user to the "bookmarked" area. >> >> > >> > Anyhow, bookmarking subpages should be not the reason why we >> stick >> >> to >> >> > >> > multi-page design. >> >> > >> > >> >> > >> > Sebastian >> >> > >> > >> >> > >> > >> >> > >> > 2012/9/1 Maxim Solodovnik <[email protected]> >> >> > >> > >> >> > >> >> 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 >> >> > >> >> >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > -- >> >> > >> > 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 >> >> > >> >> >> >> >> >> >> >> -- >> >> 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 >> > > > > -- > 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]
