You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2012/09/01 09:50:02 UTC

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

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 <so...@gmail.com>:
> 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
> <ic...@oliver-becherer.name> 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
>>> <ic...@oliver-becherer.name> 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
>>>>> <al...@gmail.com> 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 <so...@gmail.com> 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, seba.wagner@gmail.com
>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>>>>>>>>> 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, seba.wagner@gmail.com
>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>>>>>>>>>>> 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, seba.wagner@gmail.com
>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>> Ok
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <se...@gmail.com>
>>>>>>>>>>>>> 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 <so...@gmail.com>:
>>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What is your proposal to
>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>>>>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <so...@gmail.com>:
>>>>>>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI widgets and
>>>>>>>>>>>>>> animation?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <so...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "seba.wagner@gmail.com" <
>>>>>>>>>>>>>> seba.wagner@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

I just take a look at gmail.
It has single page design.
OK
I'll try to redesign the app to handle this.
don't know how right now, but I'll try.

On Sat, Sep 1, 2012 at 9:49 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> And of course while the page is loading you won't be able to chat :)
>
> 2012/9/1 seba.wagner@gmail.com <se...@gmail.com>
>
> > I see the URL problem not really that relevant then the issue of loosing
> > the users scope.
> > WebSockets are permanent connections, they basically have a similar
> > architecture then the NetConnection in Flash:
> >
> >
> https://cwiki.apache.org/WICKET/wicket-native-websockets.html#WicketNativeWebSockets-ClientsideAPIs
> > You have to open/close a WebSocket. That means as soon as a user clicks
> on
> > a link and reloads the page, he will have to close the WebSocket. During
> > that time he will not receive any events. After he has reloaded the page
> > you somehow will have to magically find out what happened while loading
> the
> > page.
> > In case of a chat this might be solved cause you can save a server side
> > chat history and reload that all the time. But of course you loose for
> > example other information, you literaly have to store each and every
> state
> > on the server side, for example chat box position, height, width
> > everything, just to recreate the whole chat window in case of a page
> reload.
> > You could do the same with other components. But I don't think that it
> > will make life practically more easy by doing it. And I think it is very
> > ugly to reload all components all the time. Why having such a history and
> > store all components state and layout anyhow?
> > Being able to bookmark a sub-page is no criteria for me that would decide
> > if doing Single or Multi Page Design.
> >
> > Sebastian
> >
> > 2012/9/1 Maxim Solodovnik <so...@gmail.com>
> >
> >> Also in case we need to calculate which blocks need to be displayed
> wрich
> >> time it will complicate the logic and will require additional computing
> >> time
> >>
> >> On Sat, Sep 1, 2012 at 9:25 PM, Maxim Solodovnik <solomax666@gmail.com
> >> >wrote:
> >>
> >> > Ye you are right.
> >> > Modules can be created as Wicket panels and maintained this way.
> >> > But in case of pages you need to find a page and you will get all its
> >> > components, in case of panels you have only 1 page and you need to
> >> guess,
> >> > which panel need to be modified etc.
> >> >
> >> > I agree it is no problem to construct a page using panels
> >> > It is also possible to parse incoming URL (it is made automatically by
> >> > PageParameters object)
> >> > but it will be very hard to show URL need to be bookmarked (I believe
> it
> >> > will be impossible using both JS and Wicket, since changing the URL
> >> always
> >> > mean page reload)
> >> >
> >> > I still think multipage is both" developer friendly" and "user
> >> friendly".
> >> > I'll try to implement the chat (since it is "key" component) and see
> if
> >> it
> >> > will be possible.
> >> >
> >> > Current structure of pages is:
> >> >
> >> > *abstract BasePage* (the main page with no authorization, with OM
> >> header,
> >> > logo name etc.)
> >> > *SignInPage extends BasePage* (page with no authorization  displaying
> >> > login form)
> >> >
> >> > *abstract class UserPage extends BasePage* (page with no body
> available
> >> > for authenticated users with permission level: USER)
> >> > *MenuPage extends UserPage *(page providing main menu and top links
> >> > logout, profile etc.)
> >> > *abstract class AdminPage extends MenuPage* (page with no body
> available
> >> > for authenticated users with permission level: ADMIN)
> >> > *UsersPage extends AdminPage* (page providing functionality for
> managing
> >> > users, partially on Ajax, need to be refactored)
> >> >
> >> > I really like the idea of having common functionality in base classes
> >> and
> >> > to have multiple pages.
> >> > I believe it will simplify lots of things.
> >> >
> >> > Also I guess in case of multitab all tabs need to reside in memory (no
> >> > matter displayed or not) this might enlarge the time page need to
> >> render.
> >> >
> >> >
> >> > On Sat, Sep 1, 2012 at 8:56 PM, seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> >> >>
> >> >> > 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 <
> >> solomax666@gmail.com
> >> >> > >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, seba.wagner@gmail.com <
> >> >> > > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >> >> > >>
> >> >> > >> > 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 <so...@gmail.com>
> >> >> > >> >
> >> >> > >> >> 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, seba.wagner@gmail.com <
> >> >> > >> >> seba.wagner@gmail.com
> >> >> > >> >> > 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 <so...@gmail.com>:
> >> >> > >> >> > > 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
> >> >> > >> >> > > <ic...@oliver-becherer.name> 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
> >> >> > >> >> > >>> <ic...@oliver-becherer.name> 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
> >> >> > >> >> > >>>>> <al...@gmail.com> 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 <
> >> >> > >> >> > solomax666@gmail.com> 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,
> >> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>> <se...@gmail.com> 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 <
> alexei.fedotov@gmail.com
> >> >:
> >> >> > >> >> > >>>>>>>>> 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,
> >> >> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>> <se...@gmail.com> 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 <
> >> alexei.fedotov@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>> 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,
> >> >> > seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
> >> >> > >> >> > >>>>>>>>>>>> Ok
> >> >> > >> >> > >>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> >> solomax666@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for
> >> this
> >> >> > >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "
> >> seba.wagner@gmail.com"
> >> >> <
> >> >> > >> >> > seba.wagner@gmail.com>
> >> >> > >> >> > >>>>>>>>>>>>> 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 <
> >> solomax666@gmail.com
> >> >> >:
> >> >> > >> >> > >>>>>>>>>>>>>>> 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,
> >> >> > >> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >> >> > >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require
> >> Maven.
> >> >> What
> >> >> > >> is
> >> >> > >> >> > your proposal to
> >> >> > >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >> >> > >> >> > >>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian
> >> >> > >> >> > >>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> >> >> solomax666@gmail.com
> >> >> > >:
> >> >> > >> >> > >>>>>>>>>>>>>>>>> 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,
> >> >> > >> >> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> >> >> > solomax666@gmail.com
> >> >> > >> >:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>> 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,
> >> >> > >> >> > seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> >> >> > >> >> > seba.wagner@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>
> >> >> > >> >> >
> >> >> > >>
> >> >>
> >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> >> >> > >> >> > seba.wagner@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > >> >> > seba.wagner@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > >> >> > seba.wagner@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > >> >> > seba.wagner@gmail.com>:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
> >> >> Wicket UI
> >> >> > >> >> > widgets and
> >> >> > >> >> > >>>>>>>>>>>>>> animation?
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> >> >> > >> >> solomax666@gmail.com
> >> >> > >> >> > >:
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> >> >> > >> >> seba.wagner@gmail.com"
> >> >> > >> >> > <
> >> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>> WBR
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>>> WBR
> >> >> > >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >> >> > >>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>>> WBR
> >> >> > >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >> >> > >>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>>
> >> >> > >> >> > >>>>>>>>>> --
> >> >> > >> >> > >>>>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>>
> >> >> > >> >> > >>>>>>>>
> >> >> > >> >> > >>>>>>>>
> >> >> > >> >> > >>>>>>>> --
> >> >> > >> >> > >>>>>>>> Sebastian Wagner
> >> >> > >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >> >> > >>>>>>>> http://www.webbase-design.de
> >> >> > >> >> > >>>>>>>> http://www.wagner-sebastian.com
> >> >> > >> >> > >>>>>>>> seba.wagner@gmail.com
> >> >> > >> >> > >>>>>>>
> >> >> > >> >> > >>>>>>>
> >> >> > >> >> > >>>>>>>
> >> >> > >> >> > >>>>>>> --
> >> >> > >> >> > >>>>>>> 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
> >> >> > >> >> > seba.wagner@gmail.com
> >> >> > >> >> >
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >> --
> >> >> > >> >> WBR
> >> >> > >> >> Maxim aka solomax
> >> >> > >> >>
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > --
> >> >> > >> > Sebastian Wagner
> >> >> > >> > https://twitter.com/#!/dead_lock
> >> >> > >> > http://www.webbase-design.de
> >> >> > >> > http://www.wagner-sebastian.com
> >> >> > >> > seba.wagner@gmail.com
> >> >> > >> >
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> --
> >> >> > >> Sebastian Wagner
> >> >> > >> https://twitter.com/#!/dead_lock
> >> >> > >> http://www.webbase-design.de
> >> >> > >> http://www.wagner-sebastian.com
> >> >> > >> seba.wagner@gmail.com
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > 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
> >> >> seba.wagner@gmail.com
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

And of course while the page is loading you won't be able to chat :)

2012/9/1 seba.wagner@gmail.com <se...@gmail.com>

> I see the URL problem not really that relevant then the issue of loosing
> the users scope.
> WebSockets are permanent connections, they basically have a similar
> architecture then the NetConnection in Flash:
>
> https://cwiki.apache.org/WICKET/wicket-native-websockets.html#WicketNativeWebSockets-ClientsideAPIs
> You have to open/close a WebSocket. That means as soon as a user clicks on
> a link and reloads the page, he will have to close the WebSocket. During
> that time he will not receive any events. After he has reloaded the page
> you somehow will have to magically find out what happened while loading the
> page.
> In case of a chat this might be solved cause you can save a server side
> chat history and reload that all the time. But of course you loose for
> example other information, you literaly have to store each and every state
> on the server side, for example chat box position, height, width
> everything, just to recreate the whole chat window in case of a page reload.
> You could do the same with other components. But I don't think that it
> will make life practically more easy by doing it. And I think it is very
> ugly to reload all components all the time. Why having such a history and
> store all components state and layout anyhow?
> Being able to bookmark a sub-page is no criteria for me that would decide
> if doing Single or Multi Page Design.
>
> Sebastian
>
> 2012/9/1 Maxim Solodovnik <so...@gmail.com>
>
>> Also in case we need to calculate which blocks need to be displayed wрich
>> time it will complicate the logic and will require additional computing
>> time
>>
>> On Sat, Sep 1, 2012 at 9:25 PM, Maxim Solodovnik <solomax666@gmail.com
>> >wrote:
>>
>> > Ye you are right.
>> > Modules can be created as Wicket panels and maintained this way.
>> > But in case of pages you need to find a page and you will get all its
>> > components, in case of panels you have only 1 page and you need to
>> guess,
>> > which panel need to be modified etc.
>> >
>> > I agree it is no problem to construct a page using panels
>> > It is also possible to parse incoming URL (it is made automatically by
>> > PageParameters object)
>> > but it will be very hard to show URL need to be bookmarked (I believe it
>> > will be impossible using both JS and Wicket, since changing the URL
>> always
>> > mean page reload)
>> >
>> > I still think multipage is both" developer friendly" and "user
>> friendly".
>> > I'll try to implement the chat (since it is "key" component) and see if
>> it
>> > will be possible.
>> >
>> > Current structure of pages is:
>> >
>> > *abstract BasePage* (the main page with no authorization, with OM
>> header,
>> > logo name etc.)
>> > *SignInPage extends BasePage* (page with no authorization  displaying
>> > login form)
>> >
>> > *abstract class UserPage extends BasePage* (page with no body available
>> > for authenticated users with permission level: USER)
>> > *MenuPage extends UserPage *(page providing main menu and top links
>> > logout, profile etc.)
>> > *abstract class AdminPage extends MenuPage* (page with no body available
>> > for authenticated users with permission level: ADMIN)
>> > *UsersPage extends AdminPage* (page providing functionality for managing
>> > users, partially on Ajax, need to be refactored)
>> >
>> > I really like the idea of having common functionality in base classes
>> and
>> > to have multiple pages.
>> > I believe it will simplify lots of things.
>> >
>> > Also I guess in case of multitab all tabs need to reside in memory (no
>> > matter displayed or not) this might enlarge the time page need to
>> render.
>> >
>> >
>> > On Sat, Sep 1, 2012 at 8:56 PM, seba.wagner@gmail.com <
>> > seba.wagner@gmail.com> 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 <so...@gmail.com>
>> >>
>> >> > 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 <
>> solomax666@gmail.com
>> >> > >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, seba.wagner@gmail.com <
>> >> > > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> >> > >>
>> >> > >> > 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 <so...@gmail.com>
>> >> > >> >
>> >> > >> >> 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, seba.wagner@gmail.com <
>> >> > >> >> seba.wagner@gmail.com
>> >> > >> >> > 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 <so...@gmail.com>:
>> >> > >> >> > > 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
>> >> > >> >> > > <ic...@oliver-becherer.name> 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
>> >> > >> >> > >>> <ic...@oliver-becherer.name> 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
>> >> > >> >> > >>>>> <al...@gmail.com> 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 <
>> >> > >> >> > solomax666@gmail.com> 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,
>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>> <se...@gmail.com> 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 <alexei.fedotov@gmail.com
>> >:
>> >> > >> >> > >>>>>>>>> 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,
>> >> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>> <se...@gmail.com> 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 <
>> alexei.fedotov@gmail.com>:
>> >> > >> >> > >>>>>>>>>>> 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,
>> >> > seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
>> >> > >> >> > >>>>>>>>>>>> Ok
>> >> > >> >> > >>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>> solomax666@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for
>> this
>> >> > >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "
>> seba.wagner@gmail.com"
>> >> <
>> >> > >> >> > seba.wagner@gmail.com>
>> >> > >> >> > >>>>>>>>>>>>> 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 <
>> solomax666@gmail.com
>> >> >:
>> >> > >> >> > >>>>>>>>>>>>>>> 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,
>> >> > >> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>> >> > >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require
>> Maven.
>> >> What
>> >> > >> is
>> >> > >> >> > your proposal to
>> >> > >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>> >> > >> >> > >>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian
>> >> > >> >> > >>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>> >> solomax666@gmail.com
>> >> > >:
>> >> > >> >> > >>>>>>>>>>>>>>>>> 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,
>> >> > >> >> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
>> >> > solomax666@gmail.com
>> >> > >> >:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>> 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,
>> >> > >> >> > seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>> >> > >> >> > seba.wagner@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>
>> >> > >> >> >
>> >> > >>
>> >>
>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>> >> > >> >> > seba.wagner@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > >> >> > seba.wagner@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > >> >> > seba.wagner@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > >> >> > seba.wagner@gmail.com>:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
>> >> Wicket UI
>> >> > >> >> > widgets and
>> >> > >> >> > >>>>>>>>>>>>>> animation?
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>> >> > >> >> solomax666@gmail.com
>> >> > >> >> > >:
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>> >> > >> >> seba.wagner@gmail.com"
>> >> > >> >> > <
>> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>>> WBR
>> >> > >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >> >> > >>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>>> WBR
>> >> > >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >> >> > >>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>>> WBR
>> >> > >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >> >> > >>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>
>> >> > >> >> > >>>>>>>>>>
>> >> > >> >> > >>>>>>>>>> --
>> >> > >> >> > >>>>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>>
>> >> > >> >> > >>>>>>>>
>> >> > >> >> > >>>>>>>>
>> >> > >> >> > >>>>>>>> --
>> >> > >> >> > >>>>>>>> Sebastian Wagner
>> >> > >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >> >> > >>>>>>>> http://www.webbase-design.de
>> >> > >> >> > >>>>>>>> http://www.wagner-sebastian.com
>> >> > >> >> > >>>>>>>> seba.wagner@gmail.com
>> >> > >> >> > >>>>>>>
>> >> > >> >> > >>>>>>>
>> >> > >> >> > >>>>>>>
>> >> > >> >> > >>>>>>> --
>> >> > >> >> > >>>>>>> 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
>> >> > >> >> > seba.wagner@gmail.com
>> >> > >> >> >
>> >> > >> >>
>> >> > >> >>
>> >> > >> >>
>> >> > >> >> --
>> >> > >> >> WBR
>> >> > >> >> Maxim aka solomax
>> >> > >> >>
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > --
>> >> > >> > Sebastian Wagner
>> >> > >> > https://twitter.com/#!/dead_lock
>> >> > >> > http://www.webbase-design.de
>> >> > >> > http://www.wagner-sebastian.com
>> >> > >> > seba.wagner@gmail.com
>> >> > >> >
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> Sebastian Wagner
>> >> > >> https://twitter.com/#!/dead_lock
>> >> > >> http://www.webbase-design.de
>> >> > >> http://www.wagner-sebastian.com
>> >> > >> seba.wagner@gmail.com
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > 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
>> >> seba.wagner@gmail.com
>> >>
>> >
>> >
>> >
>> > --
>> > 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
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

I see the URL problem not really that relevant then the issue of loosing
the users scope.
WebSockets are permanent connections, they basically have a similar
architecture then the NetConnection in Flash:
https://cwiki.apache.org/WICKET/wicket-native-websockets.html#WicketNativeWebSockets-ClientsideAPIs
You have to open/close a WebSocket. That means as soon as a user clicks on
a link and reloads the page, he will have to close the WebSocket. During
that time he will not receive any events. After he has reloaded the page
you somehow will have to magically find out what happened while loading the
page.
In case of a chat this might be solved cause you can save a server side
chat history and reload that all the time. But of course you loose for
example other information, you literaly have to store each and every state
on the server side, for example chat box position, height, width
everything, just to recreate the whole chat window in case of a page reload.
You could do the same with other components. But I don't think that it will
make life practically more easy by doing it. And I think it is very ugly to
reload all components all the time. Why having such a history and store all
components state and layout anyhow?
Being able to bookmark a sub-page is no criteria for me that would decide
if doing Single or Multi Page Design.

Sebastian

2012/9/1 Maxim Solodovnik <so...@gmail.com>

> Also in case we need to calculate which blocks need to be displayed wрich
> time it will complicate the logic and will require additional computing
> time
>
> On Sat, Sep 1, 2012 at 9:25 PM, Maxim Solodovnik <solomax666@gmail.com
> >wrote:
>
> > Ye you are right.
> > Modules can be created as Wicket panels and maintained this way.
> > But in case of pages you need to find a page and you will get all its
> > components, in case of panels you have only 1 page and you need to guess,
> > which panel need to be modified etc.
> >
> > I agree it is no problem to construct a page using panels
> > It is also possible to parse incoming URL (it is made automatically by
> > PageParameters object)
> > but it will be very hard to show URL need to be bookmarked (I believe it
> > will be impossible using both JS and Wicket, since changing the URL
> always
> > mean page reload)
> >
> > I still think multipage is both" developer friendly" and "user friendly".
> > I'll try to implement the chat (since it is "key" component) and see if
> it
> > will be possible.
> >
> > Current structure of pages is:
> >
> > *abstract BasePage* (the main page with no authorization, with OM header,
> > logo name etc.)
> > *SignInPage extends BasePage* (page with no authorization  displaying
> > login form)
> >
> > *abstract class UserPage extends BasePage* (page with no body available
> > for authenticated users with permission level: USER)
> > *MenuPage extends UserPage *(page providing main menu and top links
> > logout, profile etc.)
> > *abstract class AdminPage extends MenuPage* (page with no body available
> > for authenticated users with permission level: ADMIN)
> > *UsersPage extends AdminPage* (page providing functionality for managing
> > users, partially on Ajax, need to be refactored)
> >
> > I really like the idea of having common functionality in base classes and
> > to have multiple pages.
> > I believe it will simplify lots of things.
> >
> > Also I guess in case of multitab all tabs need to reside in memory (no
> > matter displayed or not) this might enlarge the time page need to render.
> >
> >
> > On Sat, Sep 1, 2012 at 8:56 PM, seba.wagner@gmail.com <
> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> >>
> >> > 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 <
> solomax666@gmail.com
> >> > >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, seba.wagner@gmail.com <
> >> > > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >> > >>
> >> > >> > 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 <so...@gmail.com>
> >> > >> >
> >> > >> >> 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, seba.wagner@gmail.com <
> >> > >> >> seba.wagner@gmail.com
> >> > >> >> > 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 <so...@gmail.com>:
> >> > >> >> > > 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
> >> > >> >> > > <ic...@oliver-becherer.name> 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
> >> > >> >> > >>> <ic...@oliver-becherer.name> 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
> >> > >> >> > >>>>> <al...@gmail.com> 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 <
> >> > >> >> > solomax666@gmail.com> 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,
> seba.wagner@gmail.com
> >> > >> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >> > >> >> > >>>>>>>>> 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,
> >> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>> <se...@gmail.com> 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 <alexei.fedotov@gmail.com
> >:
> >> > >> >> > >>>>>>>>>>> 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,
> >> > seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
> >> > >> >> > >>>>>>>>>>>> Ok
> >> > >> >> > >>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com
> >:
> >> > >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> >> > >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com
> "
> >> <
> >> > >> >> > seba.wagner@gmail.com>
> >> > >> >> > >>>>>>>>>>>>> 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 <
> solomax666@gmail.com
> >> >:
> >> > >> >> > >>>>>>>>>>>>>>> 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,
> >> > >> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >> > >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
> >> What
> >> > >> is
> >> > >> >> > your proposal to
> >> > >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >> > >> >> > >>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian
> >> > >> >> > >>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> >> solomax666@gmail.com
> >> > >:
> >> > >> >> > >>>>>>>>>>>>>>>>> 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,
> >> > >> >> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> >> > solomax666@gmail.com
> >> > >> >:
> >> > >> >> > >>>>>>>>>>>>>>>>>>> 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,
> >> > >> >> > seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> >> > >> >> > seba.wagner@gmail.com>:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>
> >> > >> >> >
> >> > >>
> >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> >> > >> >> > seba.wagner@gmail.com>:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > >> >> > seba.wagner@gmail.com>:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > >> >> > seba.wagner@gmail.com>:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > >> >> > seba.wagner@gmail.com>:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
> >> Wicket UI
> >> > >> >> > widgets and
> >> > >> >> > >>>>>>>>>>>>>> animation?
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> >> > >> >> solomax666@gmail.com
> >> > >> >> > >:
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> >> > >> >> seba.wagner@gmail.com"
> >> > >> >> > <
> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>>> WBR
> >> > >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>>> WBR
> >> > >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> >> > >> >> > >>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>>> WBR
> >> > >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
> >> > >> >> > >>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>>
> >> > >> >> > >>>>>>>>>>>> --
> >> > >> >> > >>>>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>>>
> >> > >> >> > >>>>>>>>>>
> >> > >> >> > >>>>>>>>>>
> >> > >> >> > >>>>>>>>>> --
> >> > >> >> > >>>>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>>
> >> > >> >> > >>>>>>>>
> >> > >> >> > >>>>>>>>
> >> > >> >> > >>>>>>>> --
> >> > >> >> > >>>>>>>> Sebastian Wagner
> >> > >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
> >> > >> >> > >>>>>>>> http://www.webbase-design.de
> >> > >> >> > >>>>>>>> http://www.wagner-sebastian.com
> >> > >> >> > >>>>>>>> seba.wagner@gmail.com
> >> > >> >> > >>>>>>>
> >> > >> >> > >>>>>>>
> >> > >> >> > >>>>>>>
> >> > >> >> > >>>>>>> --
> >> > >> >> > >>>>>>> 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
> >> > >> >> > seba.wagner@gmail.com
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >>
> >> > >> >> --
> >> > >> >> WBR
> >> > >> >> Maxim aka solomax
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > --
> >> > >> > Sebastian Wagner
> >> > >> > https://twitter.com/#!/dead_lock
> >> > >> > http://www.webbase-design.de
> >> > >> > http://www.wagner-sebastian.com
> >> > >> > seba.wagner@gmail.com
> >> > >> >
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Sebastian Wagner
> >> > >> https://twitter.com/#!/dead_lock
> >> > >> http://www.webbase-design.de
> >> > >> http://www.wagner-sebastian.com
> >> > >> seba.wagner@gmail.com
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > 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
> >> seba.wagner@gmail.com
> >>
> >
> >
> >
> > --
> > 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
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

Also in case we need to calculate which blocks need to be displayed wрich
time it will complicate the logic and will require additional computing time

On Sat, Sep 1, 2012 at 9:25 PM, Maxim Solodovnik <so...@gmail.com>wrote:

> Ye you are right.
> Modules can be created as Wicket panels and maintained this way.
> But in case of pages you need to find a page and you will get all its
> components, in case of panels you have only 1 page and you need to guess,
> which panel need to be modified etc.
>
> I agree it is no problem to construct a page using panels
> It is also possible to parse incoming URL (it is made automatically by
> PageParameters object)
> but it will be very hard to show URL need to be bookmarked (I believe it
> will be impossible using both JS and Wicket, since changing the URL always
> mean page reload)
>
> I still think multipage is both" developer friendly" and "user friendly".
> I'll try to implement the chat (since it is "key" component) and see if it
> will be possible.
>
> Current structure of pages is:
>
> *abstract BasePage* (the main page with no authorization, with OM header,
> logo name etc.)
> *SignInPage extends BasePage* (page with no authorization  displaying
> login form)
>
> *abstract class UserPage extends BasePage* (page with no body available
> for authenticated users with permission level: USER)
> *MenuPage extends UserPage *(page providing main menu and top links
> logout, profile etc.)
> *abstract class AdminPage extends MenuPage* (page with no body available
> for authenticated users with permission level: ADMIN)
> *UsersPage extends AdminPage* (page providing functionality for managing
> users, partially on Ajax, need to be refactored)
>
> I really like the idea of having common functionality in base classes and
> to have multiple pages.
> I believe it will simplify lots of things.
>
> Also I guess in case of multitab all tabs need to reside in memory (no
> matter displayed or not) this might enlarge the time page need to render.
>
>
> On Sat, Sep 1, 2012 at 8:56 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <so...@gmail.com>
>>
>> > 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 <solomax666@gmail.com
>> > >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, seba.wagner@gmail.com <
>> > > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> > >>
>> > >> > 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 <so...@gmail.com>
>> > >> >
>> > >> >> 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, seba.wagner@gmail.com <
>> > >> >> seba.wagner@gmail.com
>> > >> >> > 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 <so...@gmail.com>:
>> > >> >> > > 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
>> > >> >> > > <ic...@oliver-becherer.name> 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
>> > >> >> > >>> <ic...@oliver-becherer.name> 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
>> > >> >> > >>>>> <al...@gmail.com> 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 <
>> > >> >> > solomax666@gmail.com> 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, seba.wagner@gmail.com
>> > >> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> > >> >> > >>>>>>>>> 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,
>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> > >> >> > >>>>>>>>>>> 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,
>> > seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
>> > >> >> > >>>>>>>>>>>> Ok
>> > >> >> > >>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>> > >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
>> > >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com"
>> <
>> > >> >> > seba.wagner@gmail.com>
>> > >> >> > >>>>>>>>>>>>> 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 <solomax666@gmail.com
>> >:
>> > >> >> > >>>>>>>>>>>>>>> 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,
>> > >> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>> > >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
>> What
>> > >> is
>> > >> >> > your proposal to
>> > >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>> > >> >> > >>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>> Sebastian
>> > >> >> > >>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>> solomax666@gmail.com
>> > >:
>> > >> >> > >>>>>>>>>>>>>>>>> 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,
>> > >> >> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
>> > solomax666@gmail.com
>> > >> >:
>> > >> >> > >>>>>>>>>>>>>>>>>>> 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,
>> > >> >> > seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>> > >> >> > seba.wagner@gmail.com>:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>
>> > >> >> >
>> > >>
>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>> > >> >> > seba.wagner@gmail.com>:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > >> >> > seba.wagner@gmail.com>:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > >> >> > seba.wagner@gmail.com>:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > >> >> > seba.wagner@gmail.com>:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
>> Wicket UI
>> > >> >> > widgets and
>> > >> >> > >>>>>>>>>>>>>> animation?
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>> > >> >> solomax666@gmail.com
>> > >> >> > >:
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>> > >> >> seba.wagner@gmail.com"
>> > >> >> > <
>> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>>> WBR
>> > >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
>> > >> >> > >>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>>> WBR
>> > >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
>> > >> >> > >>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>>> WBR
>> > >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
>> > >> >> > >>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>>
>> > >> >> > >>>>>>>>>>>> --
>> > >> >> > >>>>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>>>
>> > >> >> > >>>>>>>>>>
>> > >> >> > >>>>>>>>>>
>> > >> >> > >>>>>>>>>> --
>> > >> >> > >>>>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>>
>> > >> >> > >>>>>>>>
>> > >> >> > >>>>>>>>
>> > >> >> > >>>>>>>> --
>> > >> >> > >>>>>>>> Sebastian Wagner
>> > >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
>> > >> >> > >>>>>>>> http://www.webbase-design.de
>> > >> >> > >>>>>>>> http://www.wagner-sebastian.com
>> > >> >> > >>>>>>>> seba.wagner@gmail.com
>> > >> >> > >>>>>>>
>> > >> >> > >>>>>>>
>> > >> >> > >>>>>>>
>> > >> >> > >>>>>>> --
>> > >> >> > >>>>>>> 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
>> > >> >> > seba.wagner@gmail.com
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> --
>> > >> >> WBR
>> > >> >> Maxim aka solomax
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Sebastian Wagner
>> > >> > https://twitter.com/#!/dead_lock
>> > >> > http://www.webbase-design.de
>> > >> > http://www.wagner-sebastian.com
>> > >> > seba.wagner@gmail.com
>> > >> >
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Sebastian Wagner
>> > >> https://twitter.com/#!/dead_lock
>> > >> http://www.webbase-design.de
>> > >> http://www.wagner-sebastian.com
>> > >> seba.wagner@gmail.com
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > 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
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

Yes sure, such a method could potentiall be added also outside of the
SOAP/REST API.
There is no need to make such an API call available to the SOAP/REST API

Sebastian


2012/9/6 Maxim Solodovnik <so...@gmail.com>:
> In fact we don't need REST/SOAP to access data inside Wicket.
> Wicket is another JEE bean inside same tomcat and same context.
>
> If you take a look at current Admin/Users page it uses UserDAO only.
> Edit will be implemented the same way.
> Users entity will be used as Model object. It will be changed in the form
> and all changes will be reflected by Wicket, all we need is perform
> em.merge using UsersDAO.
>
> I'll try to make skeleton of all areas ASAP.
> I saw good Jquery plugin for calendar.
>
>
> On Thu, Sep 6, 2012 at 4:20 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
>> wrote:
>
>> I think we can implement everything except the conference room itself
>> in the first iteration of the Ajax interface.
>> There are only some limited real-time communication areas outside of
>> the conference room.
>> My idea was to refactor everything except the conference room to
>> Ajax/JavaScript.
>> That way we get comfortable with the new framework and we can already
>> test/implement some basic functionalities with WebSockets.
>> Based on our experiences we can then in the second iteration start
>> refactoring the conference room itself to Ajax.
>>
>> For the first iteration I would suggest we use the existing SOAP/REST
>> API of openmeetings to generate regular HASHs like the "secureHash" to
>> enter a conference room.
>> We will have to add one more SOAP/REST call where it is possible to
>> not only set an external but also internal user id so that the user
>> does not get duplicated when he enters the conference room.
>> I can implement such functionality into the SOAP/REST API when we will
>> need it.
>> I think it should be possible that the client directly invokes the
>> REST API as it is situated on the server URL, there should be no
>> Cross-Site-Scripting issues.
>>
>> We just need to make sure that we keep in mind that in the second
>> iteration the conference room will be loaded into our Ajax interface.
>>
>> What do think about that?
>>
>> Sebasitan
>>
>>
>> 2012/9/6 Maxim Solodovnik <so...@gmail.com>:
>> > @Sebastian
>> > Alexey asks for room user list implemented in wicket.
>> > What do you think is this possible?
>> >
>> > Also could you tell me is this possible to "enter the room by public SID"
>> > i.e. in Wicket I work with DB and I would like to open the room for the
>> > current user.
>> > I can create SID for the user and need mechanism to open the room.
>> >
>> > Right now I'll try to
>> > 1) display room list
>> > 2) add couple of editable fields to the user
>> > 3) implement chat (able to send receive messages)
>> >
>> >
>> > On Thu, Sep 6, 2012 at 3:54 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com
>> >> wrote:
>> >
>> >> I will test as soon as possible
>> >>
>> >> Btw: Reading the release notes of Wicket 6.0.0:
>> >>
>> >>
>> https://cwiki.apache.org/WICKET/migration-to-wicket-60.html#MigrationtoWicket6.0-UseJQueryasabackinglibraryforWicketAjaxfunctionality
>> >>
>> >> Wicket now natively uses jQuery for Ajax. This should be quite handy
>> >> for us as we decided to use jQuery anyway!
>> >>
>> >> Sebastian
>> >>
>> >> 2012/9/4 Maxim Solodovnik <so...@gmail.com>:
>> >> > Just commited improved Wicket app
>> >> >
>> >> > What was improved:
>> >> > 1) Application is now single paged
>> >> > 2) Application is available at
>> >> > http://localhost:5080/openmeetings/html(both old and new apps are
>> >> > accessible)
>> >> > 3) Only 1 menu item works as expected (Admin Users)
>> >> >
>> >> > What is not done
>> >> > 1) bookmarkable params need to be added (gmail style)
>> >> > 2) some more pages (available to USER not ADMIN)
>> >> > 3) functionality to edit User/handle errors
>> >> >
>> >> > any feedback is appreciated
>> >> >
>> >> > On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
>> >> > r.bitter.mailinglists@googlemail.com> wrote:
>> >> >
>> >> >> Just a comment on using OpenLaszlo: Seeing that Gliffy
>> >> >> http://www.gliffy.com essentially rebuilt their HTML5 version of the
>> >> >> software not using OpenLaszlo, I don't know any major software
>> product
>> >> >> using the DHTML runtime besides what Laszlo does with Webtop (and I
>> >> >> still have to see a public version of Webtop running in DHTML in
>> >> >> production). I agree with Sebastian that it would be more future
>> proof
>> >> >> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
>> >> >> OpenMeetings, unless there is any willingness to become involved with
>> >> >> DHTML runtime support - which is not very advisable for this project.
>> >> >>
>> >> >> - Raju
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > WBR
>> >> > Maxim aka solomax
>> >>
>> >>
>> >>
>> >> --
>> >> Sebastian Wagner
>> >> https://twitter.com/#!/dead_lock
>> >> http://www.webbase-design.de
>> >> http://www.wagner-sebastian.com
>> >> seba.wagner@gmail.com
>> >>
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

In fact we don't need REST/SOAP to access data inside Wicket.
Wicket is another JEE bean inside same tomcat and same context.

If you take a look at current Admin/Users page it uses UserDAO only.
Edit will be implemented the same way.
Users entity will be used as Model object. It will be changed in the form
and all changes will be reflected by Wicket, all we need is perform
em.merge using UsersDAO.

I'll try to make skeleton of all areas ASAP.
I saw good Jquery plugin for calendar.


On Thu, Sep 6, 2012 at 4:20 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> I think we can implement everything except the conference room itself
> in the first iteration of the Ajax interface.
> There are only some limited real-time communication areas outside of
> the conference room.
> My idea was to refactor everything except the conference room to
> Ajax/JavaScript.
> That way we get comfortable with the new framework and we can already
> test/implement some basic functionalities with WebSockets.
> Based on our experiences we can then in the second iteration start
> refactoring the conference room itself to Ajax.
>
> For the first iteration I would suggest we use the existing SOAP/REST
> API of openmeetings to generate regular HASHs like the "secureHash" to
> enter a conference room.
> We will have to add one more SOAP/REST call where it is possible to
> not only set an external but also internal user id so that the user
> does not get duplicated when he enters the conference room.
> I can implement such functionality into the SOAP/REST API when we will
> need it.
> I think it should be possible that the client directly invokes the
> REST API as it is situated on the server URL, there should be no
> Cross-Site-Scripting issues.
>
> We just need to make sure that we keep in mind that in the second
> iteration the conference room will be loaded into our Ajax interface.
>
> What do think about that?
>
> Sebasitan
>
>
> 2012/9/6 Maxim Solodovnik <so...@gmail.com>:
> > @Sebastian
> > Alexey asks for room user list implemented in wicket.
> > What do you think is this possible?
> >
> > Also could you tell me is this possible to "enter the room by public SID"
> > i.e. in Wicket I work with DB and I would like to open the room for the
> > current user.
> > I can create SID for the user and need mechanism to open the room.
> >
> > Right now I'll try to
> > 1) display room list
> > 2) add couple of editable fields to the user
> > 3) implement chat (able to send receive messages)
> >
> >
> > On Thu, Sep 6, 2012 at 3:54 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> >> wrote:
> >
> >> I will test as soon as possible
> >>
> >> Btw: Reading the release notes of Wicket 6.0.0:
> >>
> >>
> https://cwiki.apache.org/WICKET/migration-to-wicket-60.html#MigrationtoWicket6.0-UseJQueryasabackinglibraryforWicketAjaxfunctionality
> >>
> >> Wicket now natively uses jQuery for Ajax. This should be quite handy
> >> for us as we decided to use jQuery anyway!
> >>
> >> Sebastian
> >>
> >> 2012/9/4 Maxim Solodovnik <so...@gmail.com>:
> >> > Just commited improved Wicket app
> >> >
> >> > What was improved:
> >> > 1) Application is now single paged
> >> > 2) Application is available at
> >> > http://localhost:5080/openmeetings/html(both old and new apps are
> >> > accessible)
> >> > 3) Only 1 menu item works as expected (Admin Users)
> >> >
> >> > What is not done
> >> > 1) bookmarkable params need to be added (gmail style)
> >> > 2) some more pages (available to USER not ADMIN)
> >> > 3) functionality to edit User/handle errors
> >> >
> >> > any feedback is appreciated
> >> >
> >> > On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
> >> > r.bitter.mailinglists@googlemail.com> wrote:
> >> >
> >> >> Just a comment on using OpenLaszlo: Seeing that Gliffy
> >> >> http://www.gliffy.com essentially rebuilt their HTML5 version of the
> >> >> software not using OpenLaszlo, I don't know any major software
> product
> >> >> using the DHTML runtime besides what Laszlo does with Webtop (and I
> >> >> still have to see a public version of Webtop running in DHTML in
> >> >> production). I agree with Sebastian that it would be more future
> proof
> >> >> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
> >> >> OpenMeetings, unless there is any willingness to become involved with
> >> >> DHTML runtime support - which is not very advisable for this project.
> >> >>
> >> >> - Raju
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > WBR
> >> > Maxim aka solomax
> >>
> >>
> >>
> >> --
> >> Sebastian Wagner
> >> https://twitter.com/#!/dead_lock
> >> http://www.webbase-design.de
> >> http://www.wagner-sebastian.com
> >> seba.wagner@gmail.com
> >>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

I think we can implement everything except the conference room itself
in the first iteration of the Ajax interface.
There are only some limited real-time communication areas outside of
the conference room.
My idea was to refactor everything except the conference room to
Ajax/JavaScript.
That way we get comfortable with the new framework and we can already
test/implement some basic functionalities with WebSockets.
Based on our experiences we can then in the second iteration start
refactoring the conference room itself to Ajax.

For the first iteration I would suggest we use the existing SOAP/REST
API of openmeetings to generate regular HASHs like the "secureHash" to
enter a conference room.
We will have to add one more SOAP/REST call where it is possible to
not only set an external but also internal user id so that the user
does not get duplicated when he enters the conference room.
I can implement such functionality into the SOAP/REST API when we will need it.
I think it should be possible that the client directly invokes the
REST API as it is situated on the server URL, there should be no
Cross-Site-Scripting issues.

We just need to make sure that we keep in mind that in the second
iteration the conference room will be loaded into our Ajax interface.

What do think about that?

Sebasitan

2012/9/6 Maxim Solodovnik <so...@gmail.com>:
> @Sebastian
> Alexey asks for room user list implemented in wicket.
> What do you think is this possible?
>
> Also could you tell me is this possible to "enter the room by public SID"
> i.e. in Wicket I work with DB and I would like to open the room for the
> current user.
> I can create SID for the user and need mechanism to open the room.
>
> Right now I'll try to
> 1) display room list
> 2) add couple of editable fields to the user
> 3) implement chat (able to send receive messages)
>
>
> On Thu, Sep 6, 2012 at 3:54 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
>> wrote:
>
>> I will test as soon as possible
>>
>> Btw: Reading the release notes of Wicket 6.0.0:
>>
>> https://cwiki.apache.org/WICKET/migration-to-wicket-60.html#MigrationtoWicket6.0-UseJQueryasabackinglibraryforWicketAjaxfunctionality
>>
>> Wicket now natively uses jQuery for Ajax. This should be quite handy
>> for us as we decided to use jQuery anyway!
>>
>> Sebastian
>>
>> 2012/9/4 Maxim Solodovnik <so...@gmail.com>:
>> > Just commited improved Wicket app
>> >
>> > What was improved:
>> > 1) Application is now single paged
>> > 2) Application is available at
>> > http://localhost:5080/openmeetings/html(both old and new apps are
>> > accessible)
>> > 3) Only 1 menu item works as expected (Admin Users)
>> >
>> > What is not done
>> > 1) bookmarkable params need to be added (gmail style)
>> > 2) some more pages (available to USER not ADMIN)
>> > 3) functionality to edit User/handle errors
>> >
>> > any feedback is appreciated
>> >
>> > On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
>> > r.bitter.mailinglists@googlemail.com> wrote:
>> >
>> >> Just a comment on using OpenLaszlo: Seeing that Gliffy
>> >> http://www.gliffy.com essentially rebuilt their HTML5 version of the
>> >> software not using OpenLaszlo, I don't know any major software product
>> >> using the DHTML runtime besides what Laszlo does with Webtop (and I
>> >> still have to see a public version of Webtop running in DHTML in
>> >> production). I agree with Sebastian that it would be more future proof
>> >> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
>> >> OpenMeetings, unless there is any willingness to become involved with
>> >> DHTML runtime support - which is not very advisable for this project.
>> >>
>> >> - Raju
>> >>
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax

-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

@Sebastian
Alexey asks for room user list implemented in wicket.
What do you think is this possible?

Also could you tell me is this possible to "enter the room by public SID"
i.e. in Wicket I work with DB and I would like to open the room for the
current user.
I can create SID for the user and need mechanism to open the room.

Right now I'll try to
1) display room list
2) add couple of editable fields to the user
3) implement chat (able to send receive messages)


On Thu, Sep 6, 2012 at 3:54 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> I will test as soon as possible
>
> Btw: Reading the release notes of Wicket 6.0.0:
>
> https://cwiki.apache.org/WICKET/migration-to-wicket-60.html#MigrationtoWicket6.0-UseJQueryasabackinglibraryforWicketAjaxfunctionality
>
> Wicket now natively uses jQuery for Ajax. This should be quite handy
> for us as we decided to use jQuery anyway!
>
> Sebastian
>
> 2012/9/4 Maxim Solodovnik <so...@gmail.com>:
> > Just commited improved Wicket app
> >
> > What was improved:
> > 1) Application is now single paged
> > 2) Application is available at
> > http://localhost:5080/openmeetings/html(both old and new apps are
> > accessible)
> > 3) Only 1 menu item works as expected (Admin Users)
> >
> > What is not done
> > 1) bookmarkable params need to be added (gmail style)
> > 2) some more pages (available to USER not ADMIN)
> > 3) functionality to edit User/handle errors
> >
> > any feedback is appreciated
> >
> > On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
> > r.bitter.mailinglists@googlemail.com> wrote:
> >
> >> Just a comment on using OpenLaszlo: Seeing that Gliffy
> >> http://www.gliffy.com essentially rebuilt their HTML5 version of the
> >> software not using OpenLaszlo, I don't know any major software product
> >> using the DHTML runtime besides what Laszlo does with Webtop (and I
> >> still have to see a public version of Webtop running in DHTML in
> >> production). I agree with Sebastian that it would be more future proof
> >> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
> >> OpenMeetings, unless there is any willingness to become involved with
> >> DHTML runtime support - which is not very advisable for this project.
> >>
> >> - Raju
> >>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

I will test as soon as possible

Btw: Reading the release notes of Wicket 6.0.0:
https://cwiki.apache.org/WICKET/migration-to-wicket-60.html#MigrationtoWicket6.0-UseJQueryasabackinglibraryforWicketAjaxfunctionality

Wicket now natively uses jQuery for Ajax. This should be quite handy
for us as we decided to use jQuery anyway!

Sebastian

2012/9/4 Maxim Solodovnik <so...@gmail.com>:
> Just commited improved Wicket app
>
> What was improved:
> 1) Application is now single paged
> 2) Application is available at
> http://localhost:5080/openmeetings/html(both old and new apps are
> accessible)
> 3) Only 1 menu item works as expected (Admin Users)
>
> What is not done
> 1) bookmarkable params need to be added (gmail style)
> 2) some more pages (available to USER not ADMIN)
> 3) functionality to edit User/handle errors
>
> any feedback is appreciated
>
> On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
> r.bitter.mailinglists@googlemail.com> wrote:
>
>> Just a comment on using OpenLaszlo: Seeing that Gliffy
>> http://www.gliffy.com essentially rebuilt their HTML5 version of the
>> software not using OpenLaszlo, I don't know any major software product
>> using the DHTML runtime besides what Laszlo does with Webtop (and I
>> still have to see a public version of Webtop running in DHTML in
>> production). I agree with Sebastian that it would be more future proof
>> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
>> OpenMeetings, unless there is any willingness to become involved with
>> DHTML runtime support - which is not very advisable for this project.
>>
>> - Raju
>>
>
>
>
> --
> WBR
> Maxim aka solomax



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

Just commited improved Wicket app

What was improved:
1) Application is now single paged
2) Application is available at
http://localhost:5080/openmeetings/html(both old and new apps are
accessible)
3) Only 1 menu item works as expected (Admin Users)

What is not done
1) bookmarkable params need to be added (gmail style)
2) some more pages (available to USER not ADMIN)
3) functionality to edit User/handle errors

any feedback is appreciated

On Wed, Sep 5, 2012 at 12:35 AM, Raju Bitter <
r.bitter.mailinglists@googlemail.com> wrote:

> Just a comment on using OpenLaszlo: Seeing that Gliffy
> http://www.gliffy.com essentially rebuilt their HTML5 version of the
> software not using OpenLaszlo, I don't know any major software product
> using the DHTML runtime besides what Laszlo does with Webtop (and I
> still have to see a public version of Webtop running in DHTML in
> production). I agree with Sebastian that it would be more future proof
> for OpenMeetings to not use OpenLaszlo for the HTML5 version of
> OpenMeetings, unless there is any willingness to become involved with
> DHTML runtime support - which is not very advisable for this project.
>
> - Raju
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Raju Bitter <r....@googlemail.com>.

Just a comment on using OpenLaszlo: Seeing that Gliffy
http://www.gliffy.com essentially rebuilt their HTML5 version of the
software not using OpenLaszlo, I don't know any major software product
using the DHTML runtime besides what Laszlo does with Webtop (and I
still have to see a public version of Webtop running in DHTML in
production). I agree with Sebastian that it would be more future proof
for OpenMeetings to not use OpenLaszlo for the HTML5 version of
OpenMeetings, unless there is any willingness to become involved with
DHTML runtime support - which is not very advisable for this project.

- Raju

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Oliver becherer <ic...@oliver-becherer.name>.

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 seba.wagner@gmail.com:

> Great!
> I hope Oliver will second that approach too :)
> 
> Sebastian
> 
> 2012/9/3 Maxim Solodovnik <so...@gmail.com>
> 
>> It was multipage.
>> I'll try to create single page.
>> 
>> On Mon, Sep 3, 2012 at 2:16 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com
>>> 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 <so...@gmail.com>
>>> 
>>>> 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
>>>> <ic...@oliver-becherer.name>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, seba.wagner@gmail.com <
>>>>> seba.wagner@gmail.com
>>>>>>> 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 <so...@gmail.com>
>>>>>>> 
>>>>>>>> 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 <
>>>> solomax666@gmail.com
>>>>>>>>> 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, seba.wagner@gmail.com <
>>>>>>>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>>> 
>>>>>>>>>>> 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 <so...@gmail.com>
>>>>>>>>>>> 
>>>>>>>>>>>> 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, seba.wagner@gmail.com <
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>> 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 <so...@gmail.com>:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <ic...@oliver-becherer.name> 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
>>>>>>>>>>>>>>>> <ic...@oliver-becherer.name> 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
>>>>>>>>>>>>>>>>>> <al...@gmail.com> 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 <
>>>>>>>>>>>>> solomax666@gmail.com> 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,
>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <alexei.fedotov@gmail.com
>>> :
>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
>> alexei.fedotov@gmail.com
>>>> :
>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>> solomax666@gmail.com
>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for
>> this
>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "
>> seba.wagner@gmail.com"
>>> <
>>>>>>>>>>>>> seba.wagner@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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 <
>>> solomax666@gmail.com
>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require
>> Maven.
>>>>>>> What
>>>>>>>>>> is
>>>>>>>>>>>>> your proposal to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>>>>>>> solomax666@gmail.com
>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
>>>>>>>> solomax666@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>>>>>>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>> 
>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>>>>>>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
>>> Wicket
>>>>>>> UI
>>>>>>>>>>>>> widgets and
>>>>>>>>>>>>>>>>>>>>>>>>>>> animation?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>>>>>>>>>>>> solomax666@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>>>>>>>>>>>> seba.wagner@gmail.com"
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>> seba.wagner@gmail.com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 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
>>> seba.wagner@gmail.com
>>> 
>> 
>> 
>> 
>> --
>> WBR
>> Maxim aka solomax
>> 
> 
> 
> 
> -- 
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

Great!
I hope Oliver will second that approach too :)

Sebastian

2012/9/3 Maxim Solodovnik <so...@gmail.com>

> It was multipage.
> I'll try to create single page.
>
> On Mon, Sep 3, 2012 at 2:16 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> > 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 <so...@gmail.com>
> >
> > > 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
> > > <ic...@oliver-becherer.name>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, seba.wagner@gmail.com <
> > > > seba.wagner@gmail.com
> > > > >> 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 <so...@gmail.com>
> > > > >>
> > > > >>> 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 <
> > > solomax666@gmail.com
> > > > >>>> 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, seba.wagner@gmail.com <
> > > > >>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> > > > >>>>>
> > > > >>>>>> 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 <so...@gmail.com>
> > > > >>>>>>
> > > > >>>>>>> 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, seba.wagner@gmail.com <
> > > > >>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>> 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 <so...@gmail.com>:
> > > > >>>>>>>>> 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
> > > > >>>>>>>>> <ic...@oliver-becherer.name> 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
> > > > >>>>>>>>>>> <ic...@oliver-becherer.name> 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
> > > > >>>>>>>>>>>>> <al...@gmail.com> 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 <
> > > > >>>>>>>> solomax666@gmail.com> 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,
> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>> <se...@gmail.com> 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 <alexei.fedotov@gmail.com
> >:
> > > > >>>>>>>>>>>>>>>>> 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,
> > > > >> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> alexei.fedotov@gmail.com
> > >:
> > > > >>>>>>>>>>>>>>>>>>> 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,
> > > > >>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > > > >>>>>>>>>>>>>>>>>>>> Ok
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> solomax666@gmail.com
> > >:
> > > > >>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for
> this
> > > > >>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "
> seba.wagner@gmail.com"
> > <
> > > > >>>>>>>> seba.wagner@gmail.com>
> > > > >>>>>>>>>>>>>>>>>>>>> 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 <
> > solomax666@gmail.com
> > > > >>> :
> > > > >>>>>>>>>>>>>>>>>>>>>>> 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,
> > > > >>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require
> Maven.
> > > > >> What
> > > > >>>>> is
> > > > >>>>>>>> your proposal to
> > > > >>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> > > > >> solomax666@gmail.com
> > > > >>>> :
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > > > >>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> > > > >>> solomax666@gmail.com
> > > > >>>>>> :
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > > > >>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> > > > >>>>>>>> seba.wagner@gmail.com>:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>
> > > > >>
> > >
> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> > > > >>>>>>>> seba.wagner@gmail.com>:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > > >>>>>>>> seba.wagner@gmail.com>:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > > >>>>>>>> seba.wagner@gmail.com>:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > > >>>>>>>> seba.wagner@gmail.com>:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
> > Wicket
> > > > >> UI
> > > > >>>>>>>> widgets and
> > > > >>>>>>>>>>>>>>>>>>>>>> animation?
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> > > > >>>>>>> solomax666@gmail.com
> > > > >>>>>>>>> :
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> > > > >>>>>>> seba.wagner@gmail.com"
> > > > >>>>>>>> <
> > > > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>> WBR
> > > > >>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>> Sebastian Wagner
> > > > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>> 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
> > > > >>>>>>>> seba.wagner@gmail.com
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>> WBR
> > > > >>>>>>> Maxim aka solomax
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Sebastian Wagner
> > > > >>>>>> https://twitter.com/#!/dead_lock
> > > > >>>>>> http://www.webbase-design.de
> > > > >>>>>> http://www.wagner-sebastian.com
> > > > >>>>>> seba.wagner@gmail.com
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Sebastian Wagner
> > > > >>>>> https://twitter.com/#!/dead_lock
> > > > >>>>> http://www.webbase-design.de
> > > > >>>>> http://www.wagner-sebastian.com
> > > > >>>>> seba.wagner@gmail.com
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> 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
> > > > >> seba.wagner@gmail.com
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

It was multipage.
I'll try to create single page.

On Mon, Sep 3, 2012 at 2:16 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 <so...@gmail.com>
>
> > 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
> > <ic...@oliver-becherer.name>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, seba.wagner@gmail.com <
> > > seba.wagner@gmail.com
> > > >> 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 <so...@gmail.com>
> > > >>
> > > >>> 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 <
> > solomax666@gmail.com
> > > >>>> 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, seba.wagner@gmail.com <
> > > >>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> > > >>>>>
> > > >>>>>> 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 <so...@gmail.com>
> > > >>>>>>
> > > >>>>>>> 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, seba.wagner@gmail.com <
> > > >>>>>>> seba.wagner@gmail.com
> > > >>>>>>>> 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 <so...@gmail.com>:
> > > >>>>>>>>> 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
> > > >>>>>>>>> <ic...@oliver-becherer.name> 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
> > > >>>>>>>>>>> <ic...@oliver-becherer.name> 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
> > > >>>>>>>>>>>>> <al...@gmail.com> 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 <
> > > >>>>>>>> solomax666@gmail.com> 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, seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > > >>>>>>>>>>>>>>>>> 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,
> > > >> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <alexei.fedotov@gmail.com
> >:
> > > >>>>>>>>>>>>>>>>>>> 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,
> > > >>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>> Ok
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com
> >:
> > > >>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> > > >>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com"
> <
> > > >>>>>>>> seba.wagner@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>> 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 <
> solomax666@gmail.com
> > > >>> :
> > > >>>>>>>>>>>>>>>>>>>>>>> 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,
> > > >>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
> > > >> What
> > > >>>>> is
> > > >>>>>>>> your proposal to
> > > >>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> > > >> solomax666@gmail.com
> > > >>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > > >>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> > > >>> solomax666@gmail.com
> > > >>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > > >>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> > > >>>>>>>> seba.wagner@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>
> > > >>
> > https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> > > >>>>>>>> seba.wagner@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > >>>>>>>> seba.wagner@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > >>>>>>>> seba.wagner@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > > >>>>>>>> seba.wagner@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache
> Wicket
> > > >> UI
> > > >>>>>>>> widgets and
> > > >>>>>>>>>>>>>>>>>>>>>> animation?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> > > >>>>>>> solomax666@gmail.com
> > > >>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> > > >>>>>>> seba.wagner@gmail.com"
> > > >>>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > > >>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>> WBR
> > > >>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>> Sebastian Wagner
> > > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> > > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>> 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
> > > >>>>>>>> seba.wagner@gmail.com
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> WBR
> > > >>>>>>> Maxim aka solomax
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Sebastian Wagner
> > > >>>>>> https://twitter.com/#!/dead_lock
> > > >>>>>> http://www.webbase-design.de
> > > >>>>>> http://www.wagner-sebastian.com
> > > >>>>>> seba.wagner@gmail.com
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Sebastian Wagner
> > > >>>>> https://twitter.com/#!/dead_lock
> > > >>>>> http://www.webbase-design.de
> > > >>>>> http://www.wagner-sebastian.com
> > > >>>>> seba.wagner@gmail.com
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> 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
> > > >> seba.wagner@gmail.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

I don't get it: Do you plan to refactor to Single Page or Multi Page Design
now?

Sebastian

2012/9/1 Maxim Solodovnik <so...@gmail.com>

> 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
> <ic...@oliver-becherer.name>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, seba.wagner@gmail.com <
> > seba.wagner@gmail.com
> > >> 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 <so...@gmail.com>
> > >>
> > >>> 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 <
> solomax666@gmail.com
> > >>>> 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, seba.wagner@gmail.com <
> > >>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> > >>>>>
> > >>>>>> 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 <so...@gmail.com>
> > >>>>>>
> > >>>>>>> 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, seba.wagner@gmail.com <
> > >>>>>>> seba.wagner@gmail.com
> > >>>>>>>> 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 <so...@gmail.com>:
> > >>>>>>>>> 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
> > >>>>>>>>> <ic...@oliver-becherer.name> 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
> > >>>>>>>>>>> <ic...@oliver-becherer.name> 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
> > >>>>>>>>>>>>> <al...@gmail.com> 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 <
> > >>>>>>>> solomax666@gmail.com> 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, seba.wagner@gmail.com
> > >>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >>>>>>>>>>>>>>>>> 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,
> > >> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >>>>>>>>>>>>>>>>>>> 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,
> > >>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>>>>> Ok
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> > >>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> > >>>>>>>> seba.wagner@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>> 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 <solomax666@gmail.com
> > >>> :
> > >>>>>>>>>>>>>>>>>>>>>>> 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,
> > >>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
> > >> What
> > >>>>> is
> > >>>>>>>> your proposal to
> > >>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> > >> solomax666@gmail.com
> > >>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > >>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> > >>> solomax666@gmail.com
> > >>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
> > >>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> > >>>>>>>> seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>
> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> > >>>>>>>> seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >>>>>>>> seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >>>>>>>> seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >>>>>>>> seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket
> > >> UI
> > >>>>>>>> widgets and
> > >>>>>>>>>>>>>>>>>>>>>> animation?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> > >>>>>>> solomax666@gmail.com
> > >>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> > >>>>>>> seba.wagner@gmail.com"
> > >>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>> 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
> > >>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> WBR
> > >>>>>>> Maxim aka solomax
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Sebastian Wagner
> > >>>>>> https://twitter.com/#!/dead_lock
> > >>>>>> http://www.webbase-design.de
> > >>>>>> http://www.wagner-sebastian.com
> > >>>>>> seba.wagner@gmail.com
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Sebastian Wagner
> > >>>>> https://twitter.com/#!/dead_lock
> > >>>>> http://www.webbase-design.de
> > >>>>> http://www.wagner-sebastian.com
> > >>>>> seba.wagner@gmail.com
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> 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
> > >> seba.wagner@gmail.com
> > >>
> > >
> > >
> > >
> > > --
> > > 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
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

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
<ic...@oliver-becherer.name>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, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> >> 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 <so...@gmail.com>
> >>
> >>> 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 <solomax666@gmail.com
> >>>> 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, seba.wagner@gmail.com <
> >>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >>>>>
> >>>>>> 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 <so...@gmail.com>
> >>>>>>
> >>>>>>> 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, seba.wagner@gmail.com <
> >>>>>>> seba.wagner@gmail.com
> >>>>>>>> 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 <so...@gmail.com>:
> >>>>>>>>> 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
> >>>>>>>>> <ic...@oliver-becherer.name> 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
> >>>>>>>>>>> <ic...@oliver-becherer.name> 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
> >>>>>>>>>>>>> <al...@gmail.com> 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 <
> >>>>>>>> solomax666@gmail.com> 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, seba.wagner@gmail.com
> >>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >>>>>>>>>>>>>>>>> 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,
> >> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >>>>>>>>>>>>>>>>>>> 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,
> >>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>> Ok
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> >>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> >>>>>>>> seba.wagner@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> 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 <solomax666@gmail.com
> >>> :
> >>>>>>>>>>>>>>>>>>>>>>> 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,
> >>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
> >> What
> >>>>> is
> >>>>>>>> your proposal to
> >>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> >> solomax666@gmail.com
> >>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>> 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,
> >>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> >>> solomax666@gmail.com
> >>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
> >>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> >>>>>>>> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>
> >>>>>
> >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> >>>>>>>> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >>>>>>>> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >>>>>>>> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >>>>>>>> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket
> >> UI
> >>>>>>>> widgets and
> >>>>>>>>>>>>>>>>>>>>>> animation?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> >>>>>>> solomax666@gmail.com
> >>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> >>>>>>> seba.wagner@gmail.com"
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> 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
> >>>>>>>> seba.wagner@gmail.com
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> WBR
> >>>>>>> Maxim aka solomax
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Sebastian Wagner
> >>>>>> https://twitter.com/#!/dead_lock
> >>>>>> http://www.webbase-design.de
> >>>>>> http://www.wagner-sebastian.com
> >>>>>> seba.wagner@gmail.com
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Sebastian Wagner
> >>>>> https://twitter.com/#!/dead_lock
> >>>>> http://www.webbase-design.de
> >>>>> http://www.wagner-sebastian.com
> >>>>> seba.wagner@gmail.com
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >> seba.wagner@gmail.com
> >>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>


-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Oliver becherer <ic...@oliver-becherer.name>.

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, seba.wagner@gmail.com <seba.wagner@gmail.com
>> 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 <so...@gmail.com>
>> 
>>> 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 <solomax666@gmail.com
>>>> 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, seba.wagner@gmail.com <
>>>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>>>> 
>>>>>> 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 <so...@gmail.com>
>>>>>> 
>>>>>>> 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, seba.wagner@gmail.com <
>>>>>>> seba.wagner@gmail.com
>>>>>>>> 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 <so...@gmail.com>:
>>>>>>>>> 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
>>>>>>>>> <ic...@oliver-becherer.name> 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
>>>>>>>>>>> <ic...@oliver-becherer.name> 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
>>>>>>>>>>>>> <al...@gmail.com> 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 <
>>>>>>>> solomax666@gmail.com> 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, seba.wagner@gmail.com
>>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>>>>>>>>>>>>>>>>> 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,
>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>>>>>>>>>>>>>>>>>>> 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,
>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
>>>>>>>>>>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
>>>>>>>> seba.wagner@gmail.com>
>>>>>>>>>>>>>>>>>>>>> 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 <solomax666@gmail.com
>>> :
>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
>> What
>>>>> is
>>>>>>>> your proposal to
>>>>>>>>>>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
>> solomax666@gmail.com
>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
>>> solomax666@gmail.com
>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>> 
>>>>> 
>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>>>>>>>> seba.wagner@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket
>> UI
>>>>>>>> widgets and
>>>>>>>>>>>>>>>>>>>>>> animation?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>>>>>>> solomax666@gmail.com
>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>>>>>>> seba.wagner@gmail.com"
>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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
>>>>>>>> seba.wagner@gmail.com
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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
>> seba.wagner@gmail.com
>> 
> 
> 
> 
> -- 
> WBR
> Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 <so...@gmail.com>
>
> > 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 <solomax666@gmail.com
> > >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, seba.wagner@gmail.com <
> > > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> > >>
> > >> > 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 <so...@gmail.com>
> > >> >
> > >> >> 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, seba.wagner@gmail.com <
> > >> >> seba.wagner@gmail.com
> > >> >> > 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 <so...@gmail.com>:
> > >> >> > > 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
> > >> >> > > <ic...@oliver-becherer.name> 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
> > >> >> > >>> <ic...@oliver-becherer.name> 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
> > >> >> > >>>>> <al...@gmail.com> 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 <
> > >> >> > solomax666@gmail.com> 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, seba.wagner@gmail.com
> > >> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >> >> > >>>>>>>>> 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,
> seba.wagner@gmail.com
> > >> >> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >> >> > >>>>>>>>>>> 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,
> > seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
> > >> >> > >>>>>>>>>>>> Ok
> > >> >> > >>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> > >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> > >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> > >> >> > seba.wagner@gmail.com>
> > >> >> > >>>>>>>>>>>>> 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 <solomax666@gmail.com
> >:
> > >> >> > >>>>>>>>>>>>>>> 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,
> > >> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven.
> What
> > >> is
> > >> >> > your proposal to
> > >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> > >> >> > >>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>> Sebastian
> > >> >> > >>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <
> solomax666@gmail.com
> > >:
> > >> >> > >>>>>>>>>>>>>>>>> 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,
> > >> >> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> > solomax666@gmail.com
> > >> >:
> > >> >> > >>>>>>>>>>>>>>>>>>> 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,
> > >> >> > seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> > >> >> > seba.wagner@gmail.com>:
> > >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>
> > >> >> >
> > >>
> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> > >> >> > seba.wagner@gmail.com>:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >> >> > seba.wagner@gmail.com>:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >> >> > seba.wagner@gmail.com>:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > >> >> > seba.wagner@gmail.com>:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket
> UI
> > >> >> > widgets and
> > >> >> > >>>>>>>>>>>>>> animation?
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> > >> >> solomax666@gmail.com
> > >> >> > >:
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> > >> >> seba.wagner@gmail.com"
> > >> >> > <
> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>>> WBR
> > >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > >> >> > >>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>>> WBR
> > >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> > >> >> > >>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>>> WBR
> > >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
> > >> >> > >>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>>
> > >> >> > >>>>>>>>>>>> --
> > >> >> > >>>>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>>>
> > >> >> > >>>>>>>>>>
> > >> >> > >>>>>>>>>>
> > >> >> > >>>>>>>>>> --
> > >> >> > >>>>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>> --
> > >> >> > >>>>>>>> Sebastian Wagner
> > >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
> > >> >> > >>>>>>>> http://www.webbase-design.de
> > >> >> > >>>>>>>> http://www.wagner-sebastian.com
> > >> >> > >>>>>>>> seba.wagner@gmail.com
> > >> >> > >>>>>>>
> > >> >> > >>>>>>>
> > >> >> > >>>>>>>
> > >> >> > >>>>>>> --
> > >> >> > >>>>>>> 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
> > >> >> > seba.wagner@gmail.com
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> WBR
> > >> >> Maxim aka solomax
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sebastian Wagner
> > >> > https://twitter.com/#!/dead_lock
> > >> > http://www.webbase-design.de
> > >> > http://www.wagner-sebastian.com
> > >> > seba.wagner@gmail.com
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Sebastian Wagner
> > >> https://twitter.com/#!/dead_lock
> > >> http://www.webbase-design.de
> > >> http://www.wagner-sebastian.com
> > >> seba.wagner@gmail.com
> > >>
> > >
> > >
> > >
> > > --
> > > 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
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 <so...@gmail.com>

> 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 <solomax666@gmail.com
> >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, seba.wagner@gmail.com <
> > seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >>
> >> > 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 <so...@gmail.com>
> >> >
> >> >> 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, seba.wagner@gmail.com <
> >> >> seba.wagner@gmail.com
> >> >> > 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 <so...@gmail.com>:
> >> >> > > 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
> >> >> > > <ic...@oliver-becherer.name> 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
> >> >> > >>> <ic...@oliver-becherer.name> 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
> >> >> > >>>>> <al...@gmail.com> 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 <
> >> >> > solomax666@gmail.com> 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, seba.wagner@gmail.com
> >> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >> >> > >>>>>>>>> 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, seba.wagner@gmail.com
> >> >> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >> >> > >>>>>>>>>>> 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,
> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
> >> >> > >>>>>>>>>>>> Ok
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> >> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> >> >> > seba.wagner@gmail.com>
> >> >> > >>>>>>>>>>>>> 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 <so...@gmail.com>:
> >> >> > >>>>>>>>>>>>>>> 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,
> >> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What
> >> is
> >> >> > your proposal to
> >> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> Sebastian
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com
> >:
> >> >> > >>>>>>>>>>>>>>>>> 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,
> >> >> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <
> solomax666@gmail.com
> >> >:
> >> >> > >>>>>>>>>>>>>>>>>>> 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,
> >> >> > seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> >> >> > seba.wagner@gmail.com>:
> >> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>
> >> >> >
> >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> >> >> > seba.wagner@gmail.com>:
> >> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > seba.wagner@gmail.com>:
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > seba.wagner@gmail.com>:
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> >> > seba.wagner@gmail.com>:
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
> >> >> > widgets and
> >> >> > >>>>>>>>>>>>>> animation?
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> >> >> solomax666@gmail.com
> >> >> > >:
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> >> >> seba.wagner@gmail.com"
> >> >> > <
> >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>>> WBR
> >> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>>> WBR
> >> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>>> WBR
> >> >> > >>>>>>>>>>>>>>> Maxim aka solomax
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> --
> >> >> > >>>>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>> --
> >> >> > >>>>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>> --
> >> >> > >>>>>>>> Sebastian Wagner
> >> >> > >>>>>>>> https://twitter.com/#!/dead_lock
> >> >> > >>>>>>>> http://www.webbase-design.de
> >> >> > >>>>>>>> http://www.wagner-sebastian.com
> >> >> > >>>>>>>> seba.wagner@gmail.com
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>> --
> >> >> > >>>>>>> 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
> >> >> > seba.wagner@gmail.com
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> WBR
> >> >> Maxim aka solomax
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Sebastian Wagner
> >> > https://twitter.com/#!/dead_lock
> >> > http://www.webbase-design.de
> >> > http://www.wagner-sebastian.com
> >> > seba.wagner@gmail.com
> >> >
> >>
> >>
> >>
> >> --
> >> Sebastian Wagner
> >> https://twitter.com/#!/dead_lock
> >> http://www.webbase-design.de
> >> http://www.wagner-sebastian.com
> >> seba.wagner@gmail.com
> >>
> >
> >
> >
> > --
> > 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
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

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 <so...@gmail.com>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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>
>> > 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 <so...@gmail.com>
>> >
>> >> 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, seba.wagner@gmail.com <
>> >> seba.wagner@gmail.com
>> >> > 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 <so...@gmail.com>:
>> >> > > 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
>> >> > > <ic...@oliver-becherer.name> 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
>> >> > >>> <ic...@oliver-becherer.name> 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
>> >> > >>>>> <al...@gmail.com> 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 <
>> >> > solomax666@gmail.com> 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, seba.wagner@gmail.com
>> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> >> > >>>>>>>>> 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, seba.wagner@gmail.com
>> >> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> >> > >>>>>>>>>>> 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, seba.wagner@gmail.com
>> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
>> >> > >>>>>>>>>>>> Ok
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
>> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
>> >> > seba.wagner@gmail.com>
>> >> > >>>>>>>>>>>>> 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 <so...@gmail.com>:
>> >> > >>>>>>>>>>>>>>> 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,
>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What
>> is
>> >> > your proposal to
>> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>> >> > >>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>> Sebastian
>> >> > >>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>> 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,
>> >> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <solomax666@gmail.com
>> >:
>> >> > >>>>>>>>>>>>>>>>>>> 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,
>> >> > seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>> >> > seba.wagner@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>
>> >> >
>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>> >> > seba.wagner@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > seba.wagner@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > seba.wagner@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> >> > seba.wagner@gmail.com>:
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
>> >> > widgets and
>> >> > >>>>>>>>>>>>>> animation?
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>> >> solomax666@gmail.com
>> >> > >:
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>> >> seba.wagner@gmail.com"
>> >> > <
>> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>>> WBR
>> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>>> WBR
>> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>>> WBR
>> >> > >>>>>>>>>>>>>>> Maxim aka solomax
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>> --
>> >> > >>>>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>> --
>> >> > >>>>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>> --
>> >> > >>>>>>>>>> Sebastian Wagner
>> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>>
>> >> > >>>>>>>>
>> >> > >>>>>>>>
>> >> > >>>>>>>> --
>> >> > >>>>>>>> Sebastian Wagner
>> >> > >>>>>>>> https://twitter.com/#!/dead_lock
>> >> > >>>>>>>> http://www.webbase-design.de
>> >> > >>>>>>>> http://www.wagner-sebastian.com
>> >> > >>>>>>>> seba.wagner@gmail.com
>> >> > >>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>> --
>> >> > >>>>>>> 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
>> >> > seba.wagner@gmail.com
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> WBR
>> >> Maxim aka solomax
>> >>
>> >
>> >
>> >
>> > --
>> > Sebastian Wagner
>> > https://twitter.com/#!/dead_lock
>> > http://www.webbase-design.de
>> > http://www.wagner-sebastian.com
>> > seba.wagner@gmail.com
>> >
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 seba.wagner@gmail.com <se...@gmail.com>
>
> > 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 <so...@gmail.com>
> >
> >> 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, seba.wagner@gmail.com <
> >> seba.wagner@gmail.com
> >> > 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 <so...@gmail.com>:
> >> > > 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
> >> > > <ic...@oliver-becherer.name> 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
> >> > >>> <ic...@oliver-becherer.name> 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
> >> > >>>>> <al...@gmail.com> 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 <
> >> > solomax666@gmail.com> 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, seba.wagner@gmail.com
> >> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >> > >>>>>>>>> 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, seba.wagner@gmail.com
> >> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >> > >>>>>>>>>>> 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, seba.wagner@gmail.com
> >> > >>>>>>>>>>> <se...@gmail.com> wrote:
> >> > >>>>>>>>>>>> Ok
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> >> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> >> > seba.wagner@gmail.com>
> >> > >>>>>>>>>>>>> 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 <so...@gmail.com>:
> >> > >>>>>>>>>>>>>>> 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,
> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What is
> >> > your proposal to
> >> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>> Sebastian
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >> > >>>>>>>>>>>>>>>>> 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,
> >> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <so...@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>> 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,
> >> > seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>
> >> >
> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com>:
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
> >> > widgets and
> >> > >>>>>>>>>>>>>> animation?
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> >> solomax666@gmail.com
> >> > >:
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> >> seba.wagner@gmail.com"
> >> > <
> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>>> WBR
> >> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >> > >>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>>> WBR
> >> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>>> WBR
> >> > >>>>>>>>>>>>>>> Maxim aka solomax
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>> --
> >> > >>>>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> --
> >> > >>>>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> --
> >> > >>>>>>>>>> Sebastian Wagner
> >> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>> --
> >> > >>>>>>>> Sebastian Wagner
> >> > >>>>>>>> https://twitter.com/#!/dead_lock
> >> > >>>>>>>> http://www.webbase-design.de
> >> > >>>>>>>> http://www.wagner-sebastian.com
> >> > >>>>>>>> seba.wagner@gmail.com
> >> > >>>>>>>
> >> > >>>>>>>
> >> > >>>>>>>
> >> > >>>>>>> --
> >> > >>>>>>> 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
> >> > seba.wagner@gmail.com
> >> >
> >>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 seba.wagner@gmail.com <se...@gmail.com>

> 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 <so...@gmail.com>
>
>> 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, seba.wagner@gmail.com <
>> seba.wagner@gmail.com
>> > 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 <so...@gmail.com>:
>> > > 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
>> > > <ic...@oliver-becherer.name> 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
>> > >>> <ic...@oliver-becherer.name> 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
>> > >>>>> <al...@gmail.com> 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 <
>> > solomax666@gmail.com> 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, seba.wagner@gmail.com
>> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> > >>>>>>>>> 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, seba.wagner@gmail.com
>> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
>> > >>>>>>>>>>> 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, seba.wagner@gmail.com
>> > >>>>>>>>>>> <se...@gmail.com> wrote:
>> > >>>>>>>>>>>> Ok
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
>> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
>> > seba.wagner@gmail.com>
>> > >>>>>>>>>>>>> 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 <so...@gmail.com>:
>> > >>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
>> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What is
>> > your proposal to
>> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> Sebastian
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
>> > >>>>>>>>>>>>>>>>> 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,
>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <so...@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>> 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,
>> > seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
>> > seba.wagner@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
>> > >>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>> > >>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
>> > seba.wagner@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > seba.wagner@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > seba.wagner@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
>> > seba.wagner@gmail.com>:
>> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
>> > widgets and
>> > >>>>>>>>>>>>>> animation?
>> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
>> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
>> solomax666@gmail.com
>> > >:
>> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
>> seba.wagner@gmail.com"
>> > <
>> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
>> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>>> WBR
>> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>>> WBR
>> > >>>>>>>>>>>>>>>>> Maxim aka solomax
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>>> WBR
>> > >>>>>>>>>>>>>>> Maxim aka solomax
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> --
>> > >>>>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> --
>> > >>>>>>>>>> Sebastian Wagner
>> > >>>>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>>>> http://www.webbase-design.de
>> > >>>>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> --
>> > >>>>>>>> Sebastian Wagner
>> > >>>>>>>> https://twitter.com/#!/dead_lock
>> > >>>>>>>> http://www.webbase-design.de
>> > >>>>>>>> http://www.wagner-sebastian.com
>> > >>>>>>>> seba.wagner@gmail.com
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> --
>> > >>>>>>> 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
>> > seba.wagner@gmail.com
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 <so...@gmail.com>

> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> > 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 <so...@gmail.com>:
> > > 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
> > > <ic...@oliver-becherer.name> 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
> > >>> <ic...@oliver-becherer.name> 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
> > >>>>> <al...@gmail.com> 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 <
> > solomax666@gmail.com> 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, seba.wagner@gmail.com
> > >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >>>>>>>>> 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, seba.wagner@gmail.com
> > >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> > >>>>>>>>>>> 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, seba.wagner@gmail.com
> > >>>>>>>>>>> <se...@gmail.com> wrote:
> > >>>>>>>>>>>> Ok
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> > >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> > >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> > seba.wagner@gmail.com>
> > >>>>>>>>>>>>> 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 <so...@gmail.com>:
> > >>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
> > >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> > >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What is
> > your proposal to
> > >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Sebastian
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> > >>>>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <so...@gmail.com>:
> > >>>>>>>>>>>>>>>>>>> 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,
> > seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> > seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> > seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> > seba.wagner@gmail.com>:
> > >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
> > widgets and
> > >>>>>>>>>>>>>> animation?
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <
> solomax666@gmail.com
> > >:
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "
> seba.wagner@gmail.com"
> > <
> > >>>>>>>>>>>>>> seba.wagner@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>> WBR
> > >>>>>>>>>>>>>>> Maxim aka solomax
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Sebastian Wagner
> > >>>>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>>>> http://www.webbase-design.de
> > >>>>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>>>> seba.wagner@gmail.com
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Sebastian Wagner
> > >>>>>>>> https://twitter.com/#!/dead_lock
> > >>>>>>>> http://www.webbase-design.de
> > >>>>>>>> http://www.wagner-sebastian.com
> > >>>>>>>> seba.wagner@gmail.com
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> 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
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings

Posted by Maxim Solodovnik <so...@gmail.com>.

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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 <so...@gmail.com>:
> > 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
> > <ic...@oliver-becherer.name> 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
> >>> <ic...@oliver-becherer.name> 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
> >>>>> <al...@gmail.com> 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 <
> solomax666@gmail.com> 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, seba.wagner@gmail.com
> >>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >>>>>>>>> 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, seba.wagner@gmail.com
> >>>>>>>>> <se...@gmail.com> 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 <al...@gmail.com>:
> >>>>>>>>>>> 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, seba.wagner@gmail.com
> >>>>>>>>>>> <se...@gmail.com> wrote:
> >>>>>>>>>>>> Ok
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >>>>>>>>>>>>> I prefer develop in trunk. I would vote for this
> >>>>>>>>>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <
> seba.wagner@gmail.com>
> >>>>>>>>>>>>> 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 <so...@gmail.com>:
> >>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
> >>>>>>>>>>>>>>> <se...@gmail.com> wrote:
> >>>>>>>>>>>>>>>> Wickets standard project setup require Maven. What is
> your proposal to
> >>>>>>>>>>>>>>>> integrate Wicket into the current stack?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sebastian
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2012/8/27 Maxim Solodovnik <so...@gmail.com>:
> >>>>>>>>>>>>>>>>> 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, seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>> <se...@gmail.com> 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 <so...@gmail.com>:
> >>>>>>>>>>>>>>>>>>> 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,
> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>> <se...@gmail.com> 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 seba.wagner@gmail.com <
> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>> This would be my proposal:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2012/8/24 seba.wagner@gmail.com <
> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>> 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 seba.wagner@gmail.com <
> seba.wagner@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>> Can you show examples of Apache Wicket UI
> widgets and
> >>>>>>>>>>>>>> animation?
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 2012/8/24 Maxim Solodovnik <solomax666@gmail.com
> >:
> >>>>>>>>>>>>>>>>>>>>>>>>>> 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, "seba.wagner@gmail.com"
> <
> >>>>>>>>>>>>>> seba.wagner@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> WBR
> >>>>>>>>>>>>>>> Maxim aka solomax
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Sebastian Wagner
> >>>>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sebastian Wagner
> >>>>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>>>> http://www.webbase-design.de
> >>>>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>>>> seba.wagner@gmail.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Sebastian Wagner
> >>>>>>>> https://twitter.com/#!/dead_lock
> >>>>>>>> http://www.webbase-design.de
> >>>>>>>> http://www.wagner-sebastian.com
> >>>>>>>> seba.wagner@gmail.com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax