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
