I did it this way. But this need to be redesigned to be "real" multi-page.
On Sat, Sep 1, 2012 at 10:56 PM, Oliver becherer <[email protected]>wrote: > hi, > > here my 2 cents again... > > > using wicket, the <wicket:child /> <wicket:extend /> mechanism could come > quite handy… > > A surrounding Wicket Page could provide a good basic structure and store > components like navigation/feedback panel and so on > > could look like this : > > Main.html : > > <body> > > overall content for every page goes here…. > > … > <wicket:child /> > … > > > and here > </body> > > > SpecialPage.html > > > <body> > <wicket:extend> > > … specific content goes here > > </wicket:extend> > </body> > > > SpecialPage.java : > > > public class SpecialPage extends Main { > > …. > } > > > The Main page can contain all the common stuff (navigation, feedback > panels, …) and it's accessible from inherited pages… > AFAIK , on every call for SpecificPage.html a new Instance of Main.java is > created as well, so it provides no static context for all derived pages by > default, > but stuff like the chat context and so on would better be stored in the > session context anyway, i think - so a static chat handler could provide > chat messages over the pages, even if > its rendered from another page after navigating to another wicket page... > > > > kind regards > > O > > > > > > Am 01.09.2012 um 16:25 schrieb Maxim Solodovnik: > > > 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
