We need to add following lines to our ivy.xml:
<dependency org="org.apache.wicket" name="wicket-core"
rev="6.0.0-beta3" conf="openmeetings->*"/>
and that is all
I can create "sample Om main page" and them both of as can add components to it.
On Mon, Aug 27, 2012 at 3:38 PM, [email protected]
<[email protected]> wrote:
> Wickets standard project setup require Maven. What is your proposal to
> integrate Wicket into the current stack?
>
> Sebastian
>
> 2012/8/27 Maxim Solodovnik <[email protected]>:
>> I don't really understand why do we need maven?
>> Why ant+ivy is not enough?
>> I always thought it is similar tools.
>>
>> Could you please explain it?
>>
>> On Mon, Aug 27, 2012 at 2:10 PM, [email protected]
>> <[email protected]> wrote:
>>> Well lets give it a try with Wicket.
>>> However when it comes to the real collaboration and UI effects I think
>>> we will heavily use jQuery.
>>> We will first have to integrate our application in a Maven styled project.
>>>
>>> I guess we can still use ANT to compile certain aspect of our
>>> application, Maven can trigger ANT build scripts.
>>> http://maven.apache.org/plugins/maven-antrun-plugin/
>>> seems to be a perfect tool for us.
>>> However some of the Ivy dependency management might be difficult to
>>> set up. Lets try that out.
>>>
>>> Sebastian
>>>
>>> 2012/8/27 Maxim Solodovnik <[email protected]>:
>>>> Hello Sebastian,
>>>>
>>>> sorry for the late reply (was out of city with no internet access)
>>>> While proposing using Apache Wicket I thought of following:
>>>>
>>>> 1) Displaying of lists: configuration, language labels, rooms etc.
>>>> 2) Use of Ajax to refresh only parts of page displayed.
>>>>
>>>> We definitely can use JS libraries (like jQuery UI) only but this will
>>>> make code less readable. I believe Apache Wicket will be good for
>>>> Admin menu etc. And we can easily add jQuery UI to it.
>>>>
>>>> Instead of Wicket we can use Spring MVC and Velocity.
>>>> I have proposed Wicket only because I have more experience with it and
>>>> from my point of view it is easy to maintain.
>>>>
>>>> On Mon, Aug 27, 2012 at 12:23 AM, [email protected]
>>>> <[email protected]> wrote:
>>>>> After some discussion I would like to propose to integrate Apache
>>>>> Wicket and try it out.
>>>>> I have update the document:
>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>> Please add your notes.
>>>>>
>>>>> Thanks
>>>>> Sebastian
>>>>>
>>>>> 2012/8/24 [email protected] <[email protected]>:
>>>>>> This would be my proposal:
>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>>
>>>>>> 2012/8/24 [email protected] <[email protected]>:
>>>>>>> What if we instead of Apache Wicket use Apache Velocity to provide the
>>>>>>> basic structure of the HTML websites?
>>>>>>> All dynamically loaded data, rendering of items could be then done by
>>>>>>> jQuery.
>>>>>>> That way we will have a set of html templates to work on and a UI
>>>>>>> framework to manipulate it.
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>> 2012/8/24 [email protected] <[email protected]>:
>>>>>>>> I would like to share this use-case
>>>>>>>>
>>>>>>>> In the next iteration I would like to put the Chat box as a permanent
>>>>>>>> box similar to what is in Google+ and Facebook on the bottom.
>>>>>>>> That mean no matter where you go, admin section, room list, dashboard
>>>>>>>> => the chat always stays the same, so a complete page refresh is not
>>>>>>>> possible.
>>>>>>>> I would simply replace the DIV that contains the main content with new
>>>>>>>> one when switching between main menu entries.
>>>>>>>>
>>>>>>>> What do you think about that?
>>>>>>>> How would that affect the framework discussion?
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>> 2012/8/24 [email protected] <[email protected]>:
>>>>>>>>> When it comes to rendering and UI component frameworks you come to
>>>>>>>>> projects like:
>>>>>>>>> code.google.com/p/wiquery
>>>>>>>>> http://www.7thweb.net/jquery-ui-samples/
>>>>>>>>>
>>>>>>>>> Simple search for "Apache Wicket UI samples" and you find tons of
>>>>>>>>> jQuery examples that are used in Apache Wicket.
>>>>>>>>>
>>>>>>>>> So from my point of view Apache Wicket is simply no UI framework. It
>>>>>>>>> is a web-framework. How things render is not part of it. Practically
>>>>>>>>> it might mean that we could combine Apache Wicket with jQuery too. But
>>>>>>>>> why use Apache Wicket then at all? We have already a backend with Rest
>>>>>>>>> Services and everything. Wicket would duplicate that. What parts of
>>>>>>>>> Wicket would we really use?
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> 2012/8/24 [email protected] <[email protected]>:
>>>>>>>>>> Can you show examples of Apache Wicket UI widgets and animation?
>>>>>>>>>>
>>>>>>>>>> Sebastian
>>>>>>>>>>
>>>>>>>>>> 2012/8/24 Maxim Solodovnik <[email protected]>:
>>>>>>>>>>> I would recommend to review Apache Wicket.
>>>>>>>>>>> It is MVC it has lots of UI components like paged lists table views
>>>>>>>>>>> etc.
>>>>>>>>>>> It had built-in AJAX support.
>>>>>>>>>>>
>>>>>>>>>>> In general I'll vote for moving to DHTML
>>>>>>>>>>> On Aug 24, 2012 3:57 PM, "[email protected]"
>>>>>>>>>>> <[email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to start a discussion about options to migrate and a
>>>>>>>>>>>> Roadmap for the upcomfing versions.
>>>>>>>>>>>>
>>>>>>>>>>>> This is our current situation:
>>>>>>>>>>>> We currently have two client side application a) + b)
>>>>>>>>>>>> a) Audio/Video related stuff is all the SWF10 app
>>>>>>>>>>>> b) whiteboard, administration + all the rest in the SWF8 app.
>>>>>>>>>>>> The two SWFs communicate via LocalConnection with each other.
>>>>>>>>>>>>
>>>>>>>>>>>> There are three options from my point of view:
>>>>>>>>>>>> 1) refactor the SWF8 app to SWF11 and keep the LocalConnection
>>>>>>>>>>>> 2) refactor the SWF8 and merge SWF8 with SWF10 app to a single
>>>>>>>>>>>> SWF11
>>>>>>>>>>>> app and get rid of the LocalConnection workaround
>>>>>>>>>>>> 3) refactor the SWF8 app to HTML5 and only use SWF for the
>>>>>>>>>>>> audio/video
>>>>>>>>>>>> part.
>>>>>>>>>>>>
>>>>>>>>>>>> option 1 is the easiest thing to do
>>>>>>>>>>>> option 2 is the best from architecture point of view
>>>>>>>>>>>> option 3 is the best for moving to HTML5
>>>>>>>>>>>>
>>>>>>>>>>>> From my point of view it would be the best option to start DHTML
>>>>>>>>>>>> refactoring now (in a version 3.0 branch) and release the current
>>>>>>>>>>>> trunk tree (as version 2.1).
>>>>>>>>>>>>
>>>>>>>>>>>> For the transition to DHTML we have several options:
>>>>>>>>>>>> I) Refactor to DHTML using OpenLaszlo
>>>>>>>>>>>> II) Refactor to DHTML using a JavaScript framework (jQuery, Dojo,
>>>>>>>>>>>> Apache Wicket, Spring+MVC)
>>>>>>>>>>>>
>>>>>>>>>>>> My personal preference is using jQuery. It provides components for
>>>>>>>>>>>> UI
>>>>>>>>>>>> and animation and is the most widespread. From a project point of
>>>>>>>>>>>> view
>>>>>>>>>>>> it will be more easy to attract new developers if they can use
>>>>>>>>>>>> tools
>>>>>>>>>>>> that they are comfortable in. And I really don't want to code a
>>>>>>>>>>>> client
>>>>>>>>>>>> side application that requires heavy usage of the page-refresh.
>>>>>>>>>>>> That
>>>>>>>>>>>> would be like moving back in time.
>>>>>>>>>>>>
>>>>>>>>>>>> There are some architectural questions that we should discuss for
>>>>>>>>>>>> the
>>>>>>>>>>>> JavaScript refactoring.
>>>>>>>>>>>> However there should be some kind of consens on the overall
>>>>>>>>>>>> RoadMap first.
>>>>>>>>>>>>
>>>>>>>>>>>> So what do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>> [email protected]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> [email protected]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> [email protected]
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> [email protected]
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> [email protected]
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> [email protected]
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> [email protected]
--
WBR
Maxim aka solomax
