hi, as you know, i'm not too deep into development process @the moment, so i surely cannot stat best way to go concerning single-page or classic multi-page design regarding special OM requirements.
my personal flavor is more using a multi-page design - i can keep better overview when thinking in pages reflecting the user's view on the app. but starting with a single-page design surely enforces thinking in a component based structure, so maybe it's better to start that way - afaik wicket allows the mixture of both styles in one app, so nothing is lost imo… regards Olli Am 03.09.2012 um 09:23 schrieb [email protected]: > Great! > I hope Oliver will second that approach too :) > > Sebastian > > 2012/9/3 Maxim Solodovnik <[email protected]> > >> It was multipage. >> I'll try to create single page. >> >> On Mon, Sep 3, 2012 at 2:16 PM, [email protected] < >> [email protected] >>> wrote: >> >>> I don't get it: Do you plan to refactor to Single Page or Multi Page >> Design >>> now? >>> >>> Sebastian >>> >>> 2012/9/1 Maxim Solodovnik <[email protected]> >>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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]
