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
