Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi All,

I will try to articulate my requirement. Can I call it a Wicket based
Portal?

I have an application lets call it Application-1  that provides common
functionality such as Authentication/Authorization. It also will provide the
Business layer/Service methods.
As part of this web application, it builds the the TOP level tab menus. Each
of the tab menu will represent a related business application. There is one
single entry point to the whole application suite.

Now, I want to build one of the related business application(Application-2)
using Wicket, Hibernate etc and inherit the common functionality provided by
Application-1. However, I want to provide/or add to the Tab menu provided by
Application-1 and integrate with it. As part of Application-1, I want to be
able to provide Tab1. And as part of Appication-2, I want to be able to
provide Tab2.

So when I eventually build the whole application suite, I must be able to
enable/disable a particular application tab or access to an application
through some business rules (License) etc. Also it should give me the
flexibility to
maintain each module/application independently and allow me to deploy a
particular module for a client.

It is pretty critical that  I have a good solution that gives a reasonable
amount of flexibility. I am sure you must have come across such
requirements, more like a portal. Only, I have to build it using Wicket.
Just so you are aware this is the set up for the project.

Web Tier: Wicket with Wiquery
Security: Apache Shiro
Service Tier: Spring
Model/Persistence: Hibernate/Spring LDAP
Servlet Engine: Tomcat

Would be great to hear some pattern I can follow and references if any that
can serve as a start-up. Any thoughts/experience from your end would be
great and valuable.

Some doubts that lurks in my mind.

1. Does Application-2 need to have a Wicket Application .i.e need to extend
a Wicket Application? Makes sense if I want to deploy it as a stand-alone
one.But If i want to integrate and use the set up as part of Application-1,
should I build the project without a Wicket Applications?

2. How does Application- 2 render the Tabs and integrate with Application-1
that does not know/aware of its child projects?

3. As an alternative, I can build application-2 as part of application-1.
The downside is, when a client wants only few modules, I would need to build
and package the whole suite.This is my last resort but sure your thoughts
will make a difference.

Appreciate your thoughts and time,

Many thanks
Nivedan

Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi Igor,

I went through the provider-lookup mechanism and as I study  the current
project structure it seems to relate to the concept of Extension Mechansim.(
http://java.sun.com/docs/books/tutorial/ext/basics/install.html)  Am I
correct?

1. the *t*est-common.jar that provides the interface to build the tabs acts
as the Service.*

2. *the test-application-1.jar providing the actual implementation of the
Service will be the Service Provider.*

3.* Since test-application-1.jar is within the application classpath of
test-container application*, if* I added a file modified/added an entry into
* *META-INF/services/org.commons.MainTabProvider

4. And add a line  into this file pointing to the provider
org.testapp1.provider.MainTabProvider
   # Provider Implementation for MainTabProvider interface

5. With # 3 and #4 implemented, can the test-container application can now
reference the provider implementation to get to the tabs? So it does not
directly hardcode the classes to get the tab items but gets it via the
provider.

Questions:

1. What *extension* or type of file would
META-INF/services/org.commons.MainTabProvider
be?
2. When I built sub-application using Maven I do not see the
*services*folder as part of META-INF by default. How can I get that as
part of the
maven build?
3. Once available as part of the services directory under META-INF, how will
the container application gain access to the *implementation*? Can I just
say MainTabProvider.*createAppTab()?
    It has to somehow return the instance of the provider so wondering if
there must be a lookup ?

Will be great to hear from you on this,

In the meantime will do my research and hope to get there

Thanks
Niv

*
*
*
On Fri, Jun 18, 2010 at 10:16 AM, Nivedan Nadaraj <sh...@gmail.com>wrote:

> Hi Igor
>
> Thank you for that.  Discovery of sub-applications using the
> 'provider-lookup' mechanism sounds pretty cool.
> I will investigate that concept and work on it,
>
> The # 3. :I I guess If I work on it things will get clearer and if
> something is not would bounce it off you.
>
> Many thanks for the valuable guidance.
>
> Regards
> Niv
>
>
> On Fri, Jun 18, 2010 at 4:32 AM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> On Thu, Jun 17, 2010 at 3:14 AM, Nivedan Nadaraj <sh...@gmail.com>
>> wrote:
>> > Hi Igor,
>> >
>> > I have moved a bit forward since the last email but would like your
>> thoughts
>> > on it. I am now able to render the top level tab from
>> > t*est-application-1*and test-application-2. This is after I resolved
>> > the Wicket Runtime
>> > Exception.
>> >
>> > Now going forward, this is how I fire the classes that provide the
>> > application tabs from the container application
>> >
>> > On the HomePage of the Container Application (for example)
>> >
>> > I instantiate the sub-application's tabs.
>> >
>> >  StudyTab appStudy = new StudyTab("App1Tab");
>> >  add(appStudy);
>> >
>> >  SubjectTab appParticipants = new SubjectTab("App2Tab");
>> >  add(appParticipants);
>> >
>> > The homepage.html contains a reference to the components App1Tab and
>> App2Tab
>> >
>> > <div wicket:id="App1Tab"></div>
>> > <div wicket:id="App2Tab"></div>
>> >
>> > So I can see that each sub-application is contributing to the top level
>> > (container) menu's. Thus abstracting the details to each sub
>> application. I
>> > am yet to render the sub-menus for each application but I guess that is
>> easy
>> > since its within the context of each sub application.
>> >
>> > 1. I would like to get some confirmation if I am on the right path and
>> is
>> > this how I should fire the sub-application's entry level tabs?
>>
>> you are on the right track.
>>
>> > 2. Is there a better way ?
>>
>> you are doing the discovery of sub-applications manually - eg
>> hardcoding it into the container project, it would be nicer if they
>> were automatically discovered at runtime. you can use whatever
>> discovery mechanism you want, for example you can use java's service
>> provider http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
>> Provider
>>
>> > 3. Would like to post another question related to application context as
>> > part of sub-applications? How would application 1..n have reference to
>> the
>> > application context? I guess will try to work it from my side in the
>> > meantime.
>>
>> what is the application context? the instance of application? it can
>> be pulled out from any wicket thread using Application.get()
>>
>> -igor
>> >
>> > Please let me know on #1 and #2 and if I have not deviated.
>> >
>> > Many thanks
>> > Regards
>> > Niv
>> >
>> >
>> >
>> > On Thu, Jun 17, 2010 at 4:21 PM, Nivedan Nadaraj <shravannive@gmail.com
>> >wrote:
>> >
>> >> Hi Igor,
>> >>
>> >> I have started work on the pattern you suggested. This is what I have
>> done
>> >> so far but  there seems to be some missing pieces when I integrate the
>> tabs
>> >> or try to fire them from container app, would be great to get some lead
>> >> here.
>> >>
>> >> The Structure of the projects as follows.
>> >> *
>> >> Project: test-common
>> >> Description: Will provide common interfaces that sub applications can
>> use.
>> >> One of them would be the CreateAppTab interface.
>> >> *Interface to create a new tab, goes like this.
>> >> *
>> >> public ITab createAppTab();*
>> >>
>> >> Using maven POM I have marked it to be built  into a *.jar* file.The
>> built
>> >> jar is available in the local maven repository so other applications
>> can
>> >> refer to it.
>> >>
>> >>
>> >> *Project: test-container
>> >> Description: Will be the base application that will contain
>> >> sub-applications.*
>> >>
>> >> This has the WebApplication and also a Sub-classed Web Application. As
>> Part
>> >> of its POM, I have added *test-common* as a dependency.
>> >> I build this project as a .*WAR *file. As part of its *WEB-INF/lib*, I
>> >> find the* test-common.jar*
>> >> At this point it satisfies the requirements of a Container Application
>> that
>> >> contains the module(jar) as part of it.( Please correct me if I have
>> >> deviated)
>> >>
>> >> *Project:test-application-1*
>> >> *Description: Will be one of the applications. Provides Tab(s) that
>> will
>> >> be associated with this app.* *Project will be built as a .jar*
>> >>
>> >> I do not have a Web Application as part of this project. I include a
>> >> dependency to* test-common.jar* in test-application-1's POM. (Since I
>> >> thought adding dependency to test-container.war did not seem sensible,
>> >> correct me if I am wrong.)  One of the panel class in this application
>> >> implements the test-common's createAppTab interface and add's the
>> returned
>> >> ITab instance into a List. The List<ITab> is added into an instance of
>> >> TabbedPanel. The instance of TabbedPanel is added into the Panel. I
>> have a
>> >> corresponding basic markup for this Panel class.
>> >>
>> >> *Re-Visit test-container*
>> >> I modified the test-container's POM to include test-application-1 as a
>> >> dependency(jar) and built it into a .WAR. The war now contains two jars
>> *test-common.jar
>> >> and **test-application-1.jar
>> >> Is this build strategy acceptable? In one build, able to include the
>> >> dependent application's jar's into one single WAR.
>> >>
>> >> Doubts:*
>> >>
>> >> 1. I need to know how these individual applications/plugins will be
>> fired
>> >> to render the tabs (create an instance of the tabs) from the
>> test-container.
>> >> when the application is started on lands on the Home Page for instance?
>> >>
>> >>
>> >> [On a side note what I did try on those lines was I created an instance
>>  of
>> >> the sub-application's class that implemented the Tab Interface and
>> added it
>> >> to the home page instance.
>> >> As in..
>> >> App1Tab tab1 = new App1Tab("someTab"); //This would fire the
>> constructor
>> >> and create the tab instances
>> >> add(tab1);
>> >>
>> >> This was not a success, as it comes up with a Wicket runtime exception
>> >>
>> >> ITab.getPanel() returned a panel with invalid id [studyPanel]. You must
>> always return a panel with id equal to the provided panelId parameter.
>> >>
>> >> TabbedPanel [8:stab:moduleTabsList] ITab index [0]
>> >> ]
>> >>
>> >>
>> >> Thanks for the time, will be great to hear from you on this.
>> >>
>> >> Regards
>> >> Niv
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Jun 10, 2010 at 11:46 AM, Igor Vaynberg <
>> igor.vaynberg@gmail.com>wrote:
>> >>
>> >>> On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <
>> shravannive@gmail.com>
>> >>> wrote:
>> >>> > Hi Igor,
>> >>> >
>> >>> > Thank you for the quick response and what a ray of hope it brings!
>> It
>> >>> > certainly, from  your experience seems to be a very good design
>> >>> approach. I
>> >>> > am excited to implement it.
>> >>> >
>> >>> > The question(s)/confirmation at this point in time is :
>> >>> >
>> >>> > 1.Will Application 2..(n)  ever extend the sub-class Web Application
>> >>> > provided by the Container Application? [I guess not, since
>> Application-2
>> >>> > needs to be built as a jar and packaged with Container-Application's
>> >>> WAR.
>> >>> > Which means sub application's (jars) will all be part of a Single
>> Wicket
>> >>> > Application instance] (Am I right?)
>> >>>
>> >>> correct, since 2..n are plugins rather then applications they do not
>> >>> need their own application class.
>> >>>
>> >>> > 2. The Tab Provider Interface you mentioned that would be part of
>> the
>> >>> common
>> >>> > jar in Container-Application; would that be a class like
>> >>> > org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is
>> what
>> >>> I
>> >>> > have used at the moment.
>> >>>
>> >>> sure, that will work. usually i have something like this
>> >>>
>> >>> public interface MainTabProvider { ITab newMainTab(); }
>> >>>
>> >>> followed by
>> >>>
>> >>> public interface ApplicationPlugin extends TabProvider, .. bunch of
>> >>> other interfaces
>> >>>
>> >>> -igor
>> >>> >
>> >>> > Appreciate your time. Glad to be using the right framework and not
>> have
>> >>> to
>> >>> > switch to another framework.
>> >>> >
>> >>> > Many thanks
>> >>> > Regards
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <
>> igor.vaynberg@gmail.com
>> >>> >wrote:
>> >>> >
>> >>> >> ive done this many times already, wicket is perfect for things like
>> >>> these.
>> >>> >>
>> >>> >> application 1 should be a simple wicket container app. this is a
>> full
>> >>> >> application with its own subclass of WicketApplication and is what
>> is
>> >>> >> going to be packaged as a war file. it should also have a module
>> (jar)
>> >>> >> with the interfaces for the common services it provides and a way
>> to
>> >>> >> retrieve those interfaces.
>> >>> >>
>> >>> >> application 2 should be a jar file which contains all the necessary
>> >>> >> wicket artifacts such as pages. one of the things in it should be
>> >>> >> something that implements a "tabprovider" interface defined in
>> >>> >> application 1's common jar. the tabprovider would return a tab that
>> >>> >> contains a panel from application 2, this panel would act as the
>> entry
>> >>> >> point into the application.
>> >>> >>
>> >>> >> the only other question is now packaging and deployment. the
>> easiest
>> >>> >> way is to take the jar from application 2 and package it into
>> >>> >> application 1 as part of the war file. a trickier way to do it is
>> to
>> >>> >> have a classloader that can look in some external folder and load
>> from
>> >>> >> all the jars there, this external folder would contain the jars for
>> >>> >> application 2...n.
>> >>> >>
>> >>> >> -igor
>> >>> >>
>> >>> >> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <
>> shravannive@gmail.com
>> >>> >
>> >>> >> wrote:
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > I will try to articulate my requirement. Can I call it a Wicket
>> based
>> >>> >> > Portal?
>> >>> >> >
>> >>> >> > I have an application lets call it Application-1  that provides
>> >>> common
>> >>> >> > functionality such as Authentication/Authorization. It also will
>> >>> provide
>> >>> >> the
>> >>> >> > Business layer/Service methods.
>> >>> >> > As part of this web application, it builds the the TOP level tab
>> >>> menus.
>> >>> >> Each
>> >>> >> > of the tab menu will represent a related business application.
>> There
>> >>> is
>> >>> >> one
>> >>> >> > single entry point to the whole application suite.
>> >>> >> >
>> >>> >> > Now, I want to build one of the related business
>> >>> >> application(Application-2)
>> >>> >> > using Wicket, Hibernate etc and inherit the common functionality
>> >>> provided
>> >>> >> by
>> >>> >> > Application-1. However, I want to provide/or add to the Tab menu
>> >>> provided
>> >>> >> by
>> >>> >> > Application-1 and integrate with it. As part of Application-1, I
>> want
>> >>> to
>> >>> >> be
>> >>> >> > able to provide Tab1. And as part of Appication-2, I want to be
>> able
>> >>> to
>> >>> >> > provide Tab2.
>> >>> >> >
>> >>> >> > So when I eventually build the whole application suite, I must be
>> >>> able to
>> >>> >> > enable/disable a particular application tab or access to an
>> >>> application
>> >>> >> > through some business rules (License) etc. Also it should give me
>> the
>> >>> >> > flexibility to
>> >>> >> > maintain each module/application independently and allow me to
>> deploy
>> >>> a
>> >>> >> > particular module for a client.
>> >>> >> >
>> >>> >> > It is pretty critical that  I have a good solution that gives a
>> >>> >> reasonable
>> >>> >> > amount of flexibility. I am sure you must have come across such
>> >>> >> > requirements, more like a portal. Only, I have to build it using
>> >>> Wicket.
>> >>> >> > Just so you are aware this is the set up for the project.
>> >>> >> >
>> >>> >> > Web Tier: Wicket with Wiquery
>> >>> >> > Security: Apache Shiro
>> >>> >> > Service Tier: Spring
>> >>> >> > Model/Persistence: Hibernate/Spring LDAP
>> >>> >> > Servlet Engine: Tomcat
>> >>> >> >
>> >>> >> > Would be great to hear some pattern I can follow and references
>> if
>> >>> any
>> >>> >> that
>> >>> >> > can serve as a start-up. Any thoughts/experience from your end
>> would
>> >>> be
>> >>> >> > great and valuable.
>> >>> >> >
>> >>> >> > Some doubts that lurks in my mind.
>> >>> >> >
>> >>> >> > 1. Does Application-2 need to have a Wicket Application .i.e need
>> to
>> >>> >> extend
>> >>> >> > a Wicket Application? Makes sense if I want to deploy it as a
>> >>> stand-alone
>> >>> >> > one.But If i want to integrate and use the set up as part of
>> >>> >> Application-1,
>> >>> >> > should I build the project without a Wicket Applications?
>> >>> >> >
>> >>> >> > 2. How does Application- 2 render the Tabs and integrate with
>> >>> >> Application-1
>> >>> >> > that does not know/aware of its child projects?
>> >>> >> >
>> >>> >> > 3. As an alternative, I can build application-2 as part of
>> >>> application-1.
>> >>> >> > The downside is, when a client wants only few modules, I would
>> need
>> >>> to
>> >>> >> build
>> >>> >> > and package the whole suite.This is my last resort but sure your
>> >>> thoughts
>> >>> >> > will make a difference.
>> >>> >> >
>> >>> >> > Appreciate your thoughts and time,
>> >>> >> >
>> >>> >> > Many thanks
>> >>> >> > Nivedan
>> >>> >> >
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi Igor

Thank you for that.  Discovery of sub-applications using the
'provider-lookup' mechanism sounds pretty cool.
I will investigate that concept and work on it,

The # 3. :I I guess If I work on it things will get clearer and if something
is not would bounce it off you.

Many thanks for the valuable guidance.

Regards
Niv

On Fri, Jun 18, 2010 at 4:32 AM, Igor Vaynberg <ig...@gmail.com>wrote:

> On Thu, Jun 17, 2010 at 3:14 AM, Nivedan Nadaraj <sh...@gmail.com>
> wrote:
> > Hi Igor,
> >
> > I have moved a bit forward since the last email but would like your
> thoughts
> > on it. I am now able to render the top level tab from
> > t*est-application-1*and test-application-2. This is after I resolved
> > the Wicket Runtime
> > Exception.
> >
> > Now going forward, this is how I fire the classes that provide the
> > application tabs from the container application
> >
> > On the HomePage of the Container Application (for example)
> >
> > I instantiate the sub-application's tabs.
> >
> >  StudyTab appStudy = new StudyTab("App1Tab");
> >  add(appStudy);
> >
> >  SubjectTab appParticipants = new SubjectTab("App2Tab");
> >  add(appParticipants);
> >
> > The homepage.html contains a reference to the components App1Tab and
> App2Tab
> >
> > <div wicket:id="App1Tab"></div>
> > <div wicket:id="App2Tab"></div>
> >
> > So I can see that each sub-application is contributing to the top level
> > (container) menu's. Thus abstracting the details to each sub application.
> I
> > am yet to render the sub-menus for each application but I guess that is
> easy
> > since its within the context of each sub application.
> >
> > 1. I would like to get some confirmation if I am on the right path and is
> > this how I should fire the sub-application's entry level tabs?
>
> you are on the right track.
>
> > 2. Is there a better way ?
>
> you are doing the discovery of sub-applications manually - eg
> hardcoding it into the container project, it would be nicer if they
> were automatically discovered at runtime. you can use whatever
> discovery mechanism you want, for example you can use java's service
> provider http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
> Provider
>
> > 3. Would like to post another question related to application context as
> > part of sub-applications? How would application 1..n have reference to
> the
> > application context? I guess will try to work it from my side in the
> > meantime.
>
> what is the application context? the instance of application? it can
> be pulled out from any wicket thread using Application.get()
>
> -igor
> >
> > Please let me know on #1 and #2 and if I have not deviated.
> >
> > Many thanks
> > Regards
> > Niv
> >
> >
> >
> > On Thu, Jun 17, 2010 at 4:21 PM, Nivedan Nadaraj <shravannive@gmail.com
> >wrote:
> >
> >> Hi Igor,
> >>
> >> I have started work on the pattern you suggested. This is what I have
> done
> >> so far but  there seems to be some missing pieces when I integrate the
> tabs
> >> or try to fire them from container app, would be great to get some lead
> >> here.
> >>
> >> The Structure of the projects as follows.
> >> *
> >> Project: test-common
> >> Description: Will provide common interfaces that sub applications can
> use.
> >> One of them would be the CreateAppTab interface.
> >> *Interface to create a new tab, goes like this.
> >> *
> >> public ITab createAppTab();*
> >>
> >> Using maven POM I have marked it to be built  into a *.jar* file.The
> built
> >> jar is available in the local maven repository so other applications can
> >> refer to it.
> >>
> >>
> >> *Project: test-container
> >> Description: Will be the base application that will contain
> >> sub-applications.*
> >>
> >> This has the WebApplication and also a Sub-classed Web Application. As
> Part
> >> of its POM, I have added *test-common* as a dependency.
> >> I build this project as a .*WAR *file. As part of its *WEB-INF/lib*, I
> >> find the* test-common.jar*
> >> At this point it satisfies the requirements of a Container Application
> that
> >> contains the module(jar) as part of it.( Please correct me if I have
> >> deviated)
> >>
> >> *Project:test-application-1*
> >> *Description: Will be one of the applications. Provides Tab(s) that will
> >> be associated with this app.* *Project will be built as a .jar*
> >>
> >> I do not have a Web Application as part of this project. I include a
> >> dependency to* test-common.jar* in test-application-1's POM. (Since I
> >> thought adding dependency to test-container.war did not seem sensible,
> >> correct me if I am wrong.)  One of the panel class in this application
> >> implements the test-common's createAppTab interface and add's the
> returned
> >> ITab instance into a List. The List<ITab> is added into an instance of
> >> TabbedPanel. The instance of TabbedPanel is added into the Panel. I have
> a
> >> corresponding basic markup for this Panel class.
> >>
> >> *Re-Visit test-container*
> >> I modified the test-container's POM to include test-application-1 as a
> >> dependency(jar) and built it into a .WAR. The war now contains two jars
> *test-common.jar
> >> and **test-application-1.jar
> >> Is this build strategy acceptable? In one build, able to include the
> >> dependent application's jar's into one single WAR.
> >>
> >> Doubts:*
> >>
> >> 1. I need to know how these individual applications/plugins will be
> fired
> >> to render the tabs (create an instance of the tabs) from the
> test-container.
> >> when the application is started on lands on the Home Page for instance?
> >>
> >>
> >> [On a side note what I did try on those lines was I created an instance
>  of
> >> the sub-application's class that implemented the Tab Interface and added
> it
> >> to the home page instance.
> >> As in..
> >> App1Tab tab1 = new App1Tab("someTab"); //This would fire the constructor
> >> and create the tab instances
> >> add(tab1);
> >>
> >> This was not a success, as it comes up with a Wicket runtime exception
> >>
> >> ITab.getPanel() returned a panel with invalid id [studyPanel]. You must
> always return a panel with id equal to the provided panelId parameter.
> >>
> >> TabbedPanel [8:stab:moduleTabsList] ITab index [0]
> >> ]
> >>
> >>
> >> Thanks for the time, will be great to hear from you on this.
> >>
> >> Regards
> >> Niv
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Jun 10, 2010 at 11:46 AM, Igor Vaynberg <
> igor.vaynberg@gmail.com>wrote:
> >>
> >>> On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <shravannive@gmail.com
> >
> >>> wrote:
> >>> > Hi Igor,
> >>> >
> >>> > Thank you for the quick response and what a ray of hope it brings! It
> >>> > certainly, from  your experience seems to be a very good design
> >>> approach. I
> >>> > am excited to implement it.
> >>> >
> >>> > The question(s)/confirmation at this point in time is :
> >>> >
> >>> > 1.Will Application 2..(n)  ever extend the sub-class Web Application
> >>> > provided by the Container Application? [I guess not, since
> Application-2
> >>> > needs to be built as a jar and packaged with Container-Application's
> >>> WAR.
> >>> > Which means sub application's (jars) will all be part of a Single
> Wicket
> >>> > Application instance] (Am I right?)
> >>>
> >>> correct, since 2..n are plugins rather then applications they do not
> >>> need their own application class.
> >>>
> >>> > 2. The Tab Provider Interface you mentioned that would be part of the
> >>> common
> >>> > jar in Container-Application; would that be a class like
> >>> > org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is
> what
> >>> I
> >>> > have used at the moment.
> >>>
> >>> sure, that will work. usually i have something like this
> >>>
> >>> public interface MainTabProvider { ITab newMainTab(); }
> >>>
> >>> followed by
> >>>
> >>> public interface ApplicationPlugin extends TabProvider, .. bunch of
> >>> other interfaces
> >>>
> >>> -igor
> >>> >
> >>> > Appreciate your time. Glad to be using the right framework and not
> have
> >>> to
> >>> > switch to another framework.
> >>> >
> >>> > Many thanks
> >>> > Regards
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <
> igor.vaynberg@gmail.com
> >>> >wrote:
> >>> >
> >>> >> ive done this many times already, wicket is perfect for things like
> >>> these.
> >>> >>
> >>> >> application 1 should be a simple wicket container app. this is a
> full
> >>> >> application with its own subclass of WicketApplication and is what
> is
> >>> >> going to be packaged as a war file. it should also have a module
> (jar)
> >>> >> with the interfaces for the common services it provides and a way to
> >>> >> retrieve those interfaces.
> >>> >>
> >>> >> application 2 should be a jar file which contains all the necessary
> >>> >> wicket artifacts such as pages. one of the things in it should be
> >>> >> something that implements a "tabprovider" interface defined in
> >>> >> application 1's common jar. the tabprovider would return a tab that
> >>> >> contains a panel from application 2, this panel would act as the
> entry
> >>> >> point into the application.
> >>> >>
> >>> >> the only other question is now packaging and deployment. the easiest
> >>> >> way is to take the jar from application 2 and package it into
> >>> >> application 1 as part of the war file. a trickier way to do it is to
> >>> >> have a classloader that can look in some external folder and load
> from
> >>> >> all the jars there, this external folder would contain the jars for
> >>> >> application 2...n.
> >>> >>
> >>> >> -igor
> >>> >>
> >>> >> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <
> shravannive@gmail.com
> >>> >
> >>> >> wrote:
> >>> >> > Hi All,
> >>> >> >
> >>> >> > I will try to articulate my requirement. Can I call it a Wicket
> based
> >>> >> > Portal?
> >>> >> >
> >>> >> > I have an application lets call it Application-1  that provides
> >>> common
> >>> >> > functionality such as Authentication/Authorization. It also will
> >>> provide
> >>> >> the
> >>> >> > Business layer/Service methods.
> >>> >> > As part of this web application, it builds the the TOP level tab
> >>> menus.
> >>> >> Each
> >>> >> > of the tab menu will represent a related business application.
> There
> >>> is
> >>> >> one
> >>> >> > single entry point to the whole application suite.
> >>> >> >
> >>> >> > Now, I want to build one of the related business
> >>> >> application(Application-2)
> >>> >> > using Wicket, Hibernate etc and inherit the common functionality
> >>> provided
> >>> >> by
> >>> >> > Application-1. However, I want to provide/or add to the Tab menu
> >>> provided
> >>> >> by
> >>> >> > Application-1 and integrate with it. As part of Application-1, I
> want
> >>> to
> >>> >> be
> >>> >> > able to provide Tab1. And as part of Appication-2, I want to be
> able
> >>> to
> >>> >> > provide Tab2.
> >>> >> >
> >>> >> > So when I eventually build the whole application suite, I must be
> >>> able to
> >>> >> > enable/disable a particular application tab or access to an
> >>> application
> >>> >> > through some business rules (License) etc. Also it should give me
> the
> >>> >> > flexibility to
> >>> >> > maintain each module/application independently and allow me to
> deploy
> >>> a
> >>> >> > particular module for a client.
> >>> >> >
> >>> >> > It is pretty critical that  I have a good solution that gives a
> >>> >> reasonable
> >>> >> > amount of flexibility. I am sure you must have come across such
> >>> >> > requirements, more like a portal. Only, I have to build it using
> >>> Wicket.
> >>> >> > Just so you are aware this is the set up for the project.
> >>> >> >
> >>> >> > Web Tier: Wicket with Wiquery
> >>> >> > Security: Apache Shiro
> >>> >> > Service Tier: Spring
> >>> >> > Model/Persistence: Hibernate/Spring LDAP
> >>> >> > Servlet Engine: Tomcat
> >>> >> >
> >>> >> > Would be great to hear some pattern I can follow and references if
> >>> any
> >>> >> that
> >>> >> > can serve as a start-up. Any thoughts/experience from your end
> would
> >>> be
> >>> >> > great and valuable.
> >>> >> >
> >>> >> > Some doubts that lurks in my mind.
> >>> >> >
> >>> >> > 1. Does Application-2 need to have a Wicket Application .i.e need
> to
> >>> >> extend
> >>> >> > a Wicket Application? Makes sense if I want to deploy it as a
> >>> stand-alone
> >>> >> > one.But If i want to integrate and use the set up as part of
> >>> >> Application-1,
> >>> >> > should I build the project without a Wicket Applications?
> >>> >> >
> >>> >> > 2. How does Application- 2 render the Tabs and integrate with
> >>> >> Application-1
> >>> >> > that does not know/aware of its child projects?
> >>> >> >
> >>> >> > 3. As an alternative, I can build application-2 as part of
> >>> application-1.
> >>> >> > The downside is, when a client wants only few modules, I would
> need
> >>> to
> >>> >> build
> >>> >> > and package the whole suite.This is my last resort but sure your
> >>> thoughts
> >>> >> > will make a difference.
> >>> >> >
> >>> >> > Appreciate your thoughts and time,
> >>> >> >
> >>> >> > Many thanks
> >>> >> > Nivedan
> >>> >> >
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>> >>
> >>> >>
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Using Wicket to build Application Portal

[Igor Vaynberg <ig...@gmail.com>]

On Thu, Jun 17, 2010 at 3:14 AM, Nivedan Nadaraj <sh...@gmail.com> wrote:
> Hi Igor,
>
> I have moved a bit forward since the last email but would like your thoughts
> on it. I am now able to render the top level tab from
> t*est-application-1*and test-application-2. This is after I resolved
> the Wicket Runtime
> Exception.
>
> Now going forward, this is how I fire the classes that provide the
> application tabs from the container application
>
> On the HomePage of the Container Application (for example)
>
> I instantiate the sub-application's tabs.
>
>  StudyTab appStudy = new StudyTab("App1Tab");
>  add(appStudy);
>
>  SubjectTab appParticipants = new SubjectTab("App2Tab");
>  add(appParticipants);
>
> The homepage.html contains a reference to the components App1Tab and App2Tab
>
> <div wicket:id="App1Tab"></div>
> <div wicket:id="App2Tab"></div>
>
> So I can see that each sub-application is contributing to the top level
> (container) menu's. Thus abstracting the details to each sub application. I
> am yet to render the sub-menus for each application but I guess that is easy
> since its within the context of each sub application.
>
> 1. I would like to get some confirmation if I am on the right path and is
> this how I should fire the sub-application's entry level tabs?

you are on the right track.

> 2. Is there a better way ?

you are doing the discovery of sub-applications manually - eg
hardcoding it into the container project, it would be nicer if they
were automatically discovered at runtime. you can use whatever
discovery mechanism you want, for example you can use java's service
provider http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
Provider

> 3. Would like to post another question related to application context as
> part of sub-applications? How would application 1..n have reference to the
> application context? I guess will try to work it from my side in the
> meantime.

what is the application context? the instance of application? it can
be pulled out from any wicket thread using Application.get()

-igor
>
> Please let me know on #1 and #2 and if I have not deviated.
>
> Many thanks
> Regards
> Niv
>
>
>
> On Thu, Jun 17, 2010 at 4:21 PM, Nivedan Nadaraj <sh...@gmail.com>wrote:
>
>> Hi Igor,
>>
>> I have started work on the pattern you suggested. This is what I have done
>> so far but  there seems to be some missing pieces when I integrate the tabs
>> or try to fire them from container app, would be great to get some lead
>> here.
>>
>> The Structure of the projects as follows.
>> *
>> Project: test-common
>> Description: Will provide common interfaces that sub applications can use.
>> One of them would be the CreateAppTab interface.
>> *Interface to create a new tab, goes like this.
>> *
>> public ITab createAppTab();*
>>
>> Using maven POM I have marked it to be built  into a *.jar* file.The built
>> jar is available in the local maven repository so other applications can
>> refer to it.
>>
>>
>> *Project: test-container
>> Description: Will be the base application that will contain
>> sub-applications.*
>>
>> This has the WebApplication and also a Sub-classed Web Application. As Part
>> of its POM, I have added *test-common* as a dependency.
>> I build this project as a .*WAR *file. As part of its *WEB-INF/lib*, I
>> find the* test-common.jar*
>> At this point it satisfies the requirements of a Container Application that
>> contains the module(jar) as part of it.( Please correct me if I have
>> deviated)
>>
>> *Project:test-application-1*
>> *Description: Will be one of the applications. Provides Tab(s) that will
>> be associated with this app.* *Project will be built as a .jar*
>>
>> I do not have a Web Application as part of this project. I include a
>> dependency to* test-common.jar* in test-application-1's POM. (Since I
>> thought adding dependency to test-container.war did not seem sensible,
>> correct me if I am wrong.)  One of the panel class in this application
>> implements the test-common's createAppTab interface and add's the returned
>> ITab instance into a List. The List<ITab> is added into an instance of
>> TabbedPanel. The instance of TabbedPanel is added into the Panel. I have a
>> corresponding basic markup for this Panel class.
>>
>> *Re-Visit test-container*
>> I modified the test-container's POM to include test-application-1 as a
>> dependency(jar) and built it into a .WAR. The war now contains two jars *test-common.jar
>> and **test-application-1.jar
>> Is this build strategy acceptable? In one build, able to include the
>> dependent application's jar's into one single WAR.
>>
>> Doubts:*
>>
>> 1. I need to know how these individual applications/plugins will be fired
>> to render the tabs (create an instance of the tabs) from the test-container.
>> when the application is started on lands on the Home Page for instance?
>>
>>
>> [On a side note what I did try on those lines was I created an instance  of
>> the sub-application's class that implemented the Tab Interface and added it
>> to the home page instance.
>> As in..
>> App1Tab tab1 = new App1Tab("someTab"); //This would fire the constructor
>> and create the tab instances
>> add(tab1);
>>
>> This was not a success, as it comes up with a Wicket runtime exception
>>
>> ITab.getPanel() returned a panel with invalid id [studyPanel]. You must always return a panel with id equal to the provided panelId parameter.
>>
>> TabbedPanel [8:stab:moduleTabsList] ITab index [0]
>> ]
>>
>>
>> Thanks for the time, will be great to hear from you on this.
>>
>> Regards
>> Niv
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 10, 2010 at 11:46 AM, Igor Vaynberg <ig...@gmail.com>wrote:
>>
>>> On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <sh...@gmail.com>
>>> wrote:
>>> > Hi Igor,
>>> >
>>> > Thank you for the quick response and what a ray of hope it brings! It
>>> > certainly, from  your experience seems to be a very good design
>>> approach. I
>>> > am excited to implement it.
>>> >
>>> > The question(s)/confirmation at this point in time is :
>>> >
>>> > 1.Will Application 2..(n)  ever extend the sub-class Web Application
>>> > provided by the Container Application? [I guess not, since Application-2
>>> > needs to be built as a jar and packaged with Container-Application's
>>> WAR.
>>> > Which means sub application's (jars) will all be part of a Single Wicket
>>> > Application instance] (Am I right?)
>>>
>>> correct, since 2..n are plugins rather then applications they do not
>>> need their own application class.
>>>
>>> > 2. The Tab Provider Interface you mentioned that would be part of the
>>> common
>>> > jar in Container-Application; would that be a class like
>>> > org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is what
>>> I
>>> > have used at the moment.
>>>
>>> sure, that will work. usually i have something like this
>>>
>>> public interface MainTabProvider { ITab newMainTab(); }
>>>
>>> followed by
>>>
>>> public interface ApplicationPlugin extends TabProvider, .. bunch of
>>> other interfaces
>>>
>>> -igor
>>> >
>>> > Appreciate your time. Glad to be using the right framework and not have
>>> to
>>> > switch to another framework.
>>> >
>>> > Many thanks
>>> > Regards
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <igor.vaynberg@gmail.com
>>> >wrote:
>>> >
>>> >> ive done this many times already, wicket is perfect for things like
>>> these.
>>> >>
>>> >> application 1 should be a simple wicket container app. this is a full
>>> >> application with its own subclass of WicketApplication and is what is
>>> >> going to be packaged as a war file. it should also have a module (jar)
>>> >> with the interfaces for the common services it provides and a way to
>>> >> retrieve those interfaces.
>>> >>
>>> >> application 2 should be a jar file which contains all the necessary
>>> >> wicket artifacts such as pages. one of the things in it should be
>>> >> something that implements a "tabprovider" interface defined in
>>> >> application 1's common jar. the tabprovider would return a tab that
>>> >> contains a panel from application 2, this panel would act as the entry
>>> >> point into the application.
>>> >>
>>> >> the only other question is now packaging and deployment. the easiest
>>> >> way is to take the jar from application 2 and package it into
>>> >> application 1 as part of the war file. a trickier way to do it is to
>>> >> have a classloader that can look in some external folder and load from
>>> >> all the jars there, this external folder would contain the jars for
>>> >> application 2...n.
>>> >>
>>> >> -igor
>>> >>
>>> >> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <shravannive@gmail.com
>>> >
>>> >> wrote:
>>> >> > Hi All,
>>> >> >
>>> >> > I will try to articulate my requirement. Can I call it a Wicket based
>>> >> > Portal?
>>> >> >
>>> >> > I have an application lets call it Application-1  that provides
>>> common
>>> >> > functionality such as Authentication/Authorization. It also will
>>> provide
>>> >> the
>>> >> > Business layer/Service methods.
>>> >> > As part of this web application, it builds the the TOP level tab
>>> menus.
>>> >> Each
>>> >> > of the tab menu will represent a related business application. There
>>> is
>>> >> one
>>> >> > single entry point to the whole application suite.
>>> >> >
>>> >> > Now, I want to build one of the related business
>>> >> application(Application-2)
>>> >> > using Wicket, Hibernate etc and inherit the common functionality
>>> provided
>>> >> by
>>> >> > Application-1. However, I want to provide/or add to the Tab menu
>>> provided
>>> >> by
>>> >> > Application-1 and integrate with it. As part of Application-1, I want
>>> to
>>> >> be
>>> >> > able to provide Tab1. And as part of Appication-2, I want to be able
>>> to
>>> >> > provide Tab2.
>>> >> >
>>> >> > So when I eventually build the whole application suite, I must be
>>> able to
>>> >> > enable/disable a particular application tab or access to an
>>> application
>>> >> > through some business rules (License) etc. Also it should give me the
>>> >> > flexibility to
>>> >> > maintain each module/application independently and allow me to deploy
>>> a
>>> >> > particular module for a client.
>>> >> >
>>> >> > It is pretty critical that  I have a good solution that gives a
>>> >> reasonable
>>> >> > amount of flexibility. I am sure you must have come across such
>>> >> > requirements, more like a portal. Only, I have to build it using
>>> Wicket.
>>> >> > Just so you are aware this is the set up for the project.
>>> >> >
>>> >> > Web Tier: Wicket with Wiquery
>>> >> > Security: Apache Shiro
>>> >> > Service Tier: Spring
>>> >> > Model/Persistence: Hibernate/Spring LDAP
>>> >> > Servlet Engine: Tomcat
>>> >> >
>>> >> > Would be great to hear some pattern I can follow and references if
>>> any
>>> >> that
>>> >> > can serve as a start-up. Any thoughts/experience from your end would
>>> be
>>> >> > great and valuable.
>>> >> >
>>> >> > Some doubts that lurks in my mind.
>>> >> >
>>> >> > 1. Does Application-2 need to have a Wicket Application .i.e need to
>>> >> extend
>>> >> > a Wicket Application? Makes sense if I want to deploy it as a
>>> stand-alone
>>> >> > one.But If i want to integrate and use the set up as part of
>>> >> Application-1,
>>> >> > should I build the project without a Wicket Applications?
>>> >> >
>>> >> > 2. How does Application- 2 render the Tabs and integrate with
>>> >> Application-1
>>> >> > that does not know/aware of its child projects?
>>> >> >
>>> >> > 3. As an alternative, I can build application-2 as part of
>>> application-1.
>>> >> > The downside is, when a client wants only few modules, I would need
>>> to
>>> >> build
>>> >> > and package the whole suite.This is my last resort but sure your
>>> thoughts
>>> >> > will make a difference.
>>> >> >
>>> >> > Appreciate your thoughts and time,
>>> >> >
>>> >> > Many thanks
>>> >> > Nivedan
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi Igor,

I have moved a bit forward since the last email but would like your thoughts
on it. I am now able to render the top level tab from
t*est-application-1*and test-application-2. This is after I resolved
the Wicket Runtime
Exception.

Now going forward, this is how I fire the classes that provide the
application tabs from the container application

On the HomePage of the Container Application (for example)

I instantiate the sub-application's tabs.

 StudyTab appStudy = new StudyTab("App1Tab");
 add(appStudy);

 SubjectTab appParticipants = new SubjectTab("App2Tab");
 add(appParticipants);

The homepage.html contains a reference to the components App1Tab and App2Tab

<div wicket:id="App1Tab"></div>
<div wicket:id="App2Tab"></div>

So I can see that each sub-application is contributing to the top level
(container) menu's. Thus abstracting the details to each sub application. I
am yet to render the sub-menus for each application but I guess that is easy
since its within the context of each sub application.

1. I would like to get some confirmation if I am on the right path and is
this how I should fire the sub-application's entry level tabs?
2. Is there a better way ?
3. Would like to post another question related to application context as
part of sub-applications? How would application 1..n have reference to the
application context? I guess will try to work it from my side in the
meantime.

Please let me know on #1 and #2 and if I have not deviated.

Many thanks
Regards
Niv



On Thu, Jun 17, 2010 at 4:21 PM, Nivedan Nadaraj <sh...@gmail.com>wrote:

> Hi Igor,
>
> I have started work on the pattern you suggested. This is what I have done
> so far but  there seems to be some missing pieces when I integrate the tabs
> or try to fire them from container app, would be great to get some lead
> here.
>
> The Structure of the projects as follows.
> *
> Project: test-common
> Description: Will provide common interfaces that sub applications can use.
> One of them would be the CreateAppTab interface.
> *Interface to create a new tab, goes like this.
> *
> public ITab createAppTab();*
>
> Using maven POM I have marked it to be built  into a *.jar* file.The built
> jar is available in the local maven repository so other applications can
> refer to it.
>
>
> *Project: test-container
> Description: Will be the base application that will contain
> sub-applications.*
>
> This has the WebApplication and also a Sub-classed Web Application. As Part
> of its POM, I have added *test-common* as a dependency.
> I build this project as a .*WAR *file. As part of its *WEB-INF/lib*, I
> find the* test-common.jar*
> At this point it satisfies the requirements of a Container Application that
> contains the module(jar) as part of it.( Please correct me if I have
> deviated)
>
> *Project:test-application-1*
> *Description: Will be one of the applications. Provides Tab(s) that will
> be associated with this app.* *Project will be built as a .jar*
>
> I do not have a Web Application as part of this project. I include a
> dependency to* test-common.jar* in test-application-1's POM. (Since I
> thought adding dependency to test-container.war did not seem sensible,
> correct me if I am wrong.)  One of the panel class in this application
> implements the test-common's createAppTab interface and add's the returned
> ITab instance into a List. The List<ITab> is added into an instance of
> TabbedPanel. The instance of TabbedPanel is added into the Panel. I have a
> corresponding basic markup for this Panel class.
>
> *Re-Visit test-container*
> I modified the test-container's POM to include test-application-1 as a
> dependency(jar) and built it into a .WAR. The war now contains two jars *test-common.jar
> and **test-application-1.jar
> Is this build strategy acceptable? In one build, able to include the
> dependent application's jar's into one single WAR.
>
> Doubts:*
>
> 1. I need to know how these individual applications/plugins will be fired
> to render the tabs (create an instance of the tabs) from the test-container.
> when the application is started on lands on the Home Page for instance?
>
>
> [On a side note what I did try on those lines was I created an instance  of
> the sub-application's class that implemented the Tab Interface and added it
> to the home page instance.
> As in..
> App1Tab tab1 = new App1Tab("someTab"); //This would fire the constructor
> and create the tab instances
> add(tab1);
>
> This was not a success, as it comes up with a Wicket runtime exception
>
> ITab.getPanel() returned a panel with invalid id [studyPanel]. You must always return a panel with id equal to the provided panelId parameter.
>
> TabbedPanel [8:stab:moduleTabsList] ITab index [0]
> ]
>
>
> Thanks for the time, will be great to hear from you on this.
>
> Regards
> Niv
>
>
>
>
>
>
>
> On Thu, Jun 10, 2010 at 11:46 AM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <sh...@gmail.com>
>> wrote:
>> > Hi Igor,
>> >
>> > Thank you for the quick response and what a ray of hope it brings! It
>> > certainly, from  your experience seems to be a very good design
>> approach. I
>> > am excited to implement it.
>> >
>> > The question(s)/confirmation at this point in time is :
>> >
>> > 1.Will Application 2..(n)  ever extend the sub-class Web Application
>> > provided by the Container Application? [I guess not, since Application-2
>> > needs to be built as a jar and packaged with Container-Application's
>> WAR.
>> > Which means sub application's (jars) will all be part of a Single Wicket
>> > Application instance] (Am I right?)
>>
>> correct, since 2..n are plugins rather then applications they do not
>> need their own application class.
>>
>> > 2. The Tab Provider Interface you mentioned that would be part of the
>> common
>> > jar in Container-Application; would that be a class like
>> > org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is what
>> I
>> > have used at the moment.
>>
>> sure, that will work. usually i have something like this
>>
>> public interface MainTabProvider { ITab newMainTab(); }
>>
>> followed by
>>
>> public interface ApplicationPlugin extends TabProvider, .. bunch of
>> other interfaces
>>
>> -igor
>> >
>> > Appreciate your time. Glad to be using the right framework and not have
>> to
>> > switch to another framework.
>> >
>> > Many thanks
>> > Regards
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <igor.vaynberg@gmail.com
>> >wrote:
>> >
>> >> ive done this many times already, wicket is perfect for things like
>> these.
>> >>
>> >> application 1 should be a simple wicket container app. this is a full
>> >> application with its own subclass of WicketApplication and is what is
>> >> going to be packaged as a war file. it should also have a module (jar)
>> >> with the interfaces for the common services it provides and a way to
>> >> retrieve those interfaces.
>> >>
>> >> application 2 should be a jar file which contains all the necessary
>> >> wicket artifacts such as pages. one of the things in it should be
>> >> something that implements a "tabprovider" interface defined in
>> >> application 1's common jar. the tabprovider would return a tab that
>> >> contains a panel from application 2, this panel would act as the entry
>> >> point into the application.
>> >>
>> >> the only other question is now packaging and deployment. the easiest
>> >> way is to take the jar from application 2 and package it into
>> >> application 1 as part of the war file. a trickier way to do it is to
>> >> have a classloader that can look in some external folder and load from
>> >> all the jars there, this external folder would contain the jars for
>> >> application 2...n.
>> >>
>> >> -igor
>> >>
>> >> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <shravannive@gmail.com
>> >
>> >> wrote:
>> >> > Hi All,
>> >> >
>> >> > I will try to articulate my requirement. Can I call it a Wicket based
>> >> > Portal?
>> >> >
>> >> > I have an application lets call it Application-1  that provides
>> common
>> >> > functionality such as Authentication/Authorization. It also will
>> provide
>> >> the
>> >> > Business layer/Service methods.
>> >> > As part of this web application, it builds the the TOP level tab
>> menus.
>> >> Each
>> >> > of the tab menu will represent a related business application. There
>> is
>> >> one
>> >> > single entry point to the whole application suite.
>> >> >
>> >> > Now, I want to build one of the related business
>> >> application(Application-2)
>> >> > using Wicket, Hibernate etc and inherit the common functionality
>> provided
>> >> by
>> >> > Application-1. However, I want to provide/or add to the Tab menu
>> provided
>> >> by
>> >> > Application-1 and integrate with it. As part of Application-1, I want
>> to
>> >> be
>> >> > able to provide Tab1. And as part of Appication-2, I want to be able
>> to
>> >> > provide Tab2.
>> >> >
>> >> > So when I eventually build the whole application suite, I must be
>> able to
>> >> > enable/disable a particular application tab or access to an
>> application
>> >> > through some business rules (License) etc. Also it should give me the
>> >> > flexibility to
>> >> > maintain each module/application independently and allow me to deploy
>> a
>> >> > particular module for a client.
>> >> >
>> >> > It is pretty critical that  I have a good solution that gives a
>> >> reasonable
>> >> > amount of flexibility. I am sure you must have come across such
>> >> > requirements, more like a portal. Only, I have to build it using
>> Wicket.
>> >> > Just so you are aware this is the set up for the project.
>> >> >
>> >> > Web Tier: Wicket with Wiquery
>> >> > Security: Apache Shiro
>> >> > Service Tier: Spring
>> >> > Model/Persistence: Hibernate/Spring LDAP
>> >> > Servlet Engine: Tomcat
>> >> >
>> >> > Would be great to hear some pattern I can follow and references if
>> any
>> >> that
>> >> > can serve as a start-up. Any thoughts/experience from your end would
>> be
>> >> > great and valuable.
>> >> >
>> >> > Some doubts that lurks in my mind.
>> >> >
>> >> > 1. Does Application-2 need to have a Wicket Application .i.e need to
>> >> extend
>> >> > a Wicket Application? Makes sense if I want to deploy it as a
>> stand-alone
>> >> > one.But If i want to integrate and use the set up as part of
>> >> Application-1,
>> >> > should I build the project without a Wicket Applications?
>> >> >
>> >> > 2. How does Application- 2 render the Tabs and integrate with
>> >> Application-1
>> >> > that does not know/aware of its child projects?
>> >> >
>> >> > 3. As an alternative, I can build application-2 as part of
>> application-1.
>> >> > The downside is, when a client wants only few modules, I would need
>> to
>> >> build
>> >> > and package the whole suite.This is my last resort but sure your
>> thoughts
>> >> > will make a difference.
>> >> >
>> >> > Appreciate your thoughts and time,
>> >> >
>> >> > Many thanks
>> >> > Nivedan
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi Igor,

I have started work on the pattern you suggested. This is what I have done
so far but  there seems to be some missing pieces when I integrate the tabs
or try to fire them from container app, would be great to get some lead
here.

The Structure of the projects as follows.
*
Project: test-common
Description: Will provide common interfaces that sub applications can use.
One of them would be the CreateAppTab interface.
*Interface to create a new tab, goes like this.
*
public ITab createAppTab();*

Using maven POM I have marked it to be built  into a *.jar* file.The built
jar is available in the local maven repository so other applications can
refer to it.


*Project: test-container
Description: Will be the base application that will contain
sub-applications.*

This has the WebApplication and also a Sub-classed Web Application. As Part
of its POM, I have added *test-common* as a dependency.
I build this project as a .*WAR *file. As part of its *WEB-INF/lib*, I find
the* test-common.jar*
At this point it satisfies the requirements of a Container Application that
contains the module(jar) as part of it.( Please correct me if I have
deviated)

*Project:test-application-1*
*Description: Will be one of the applications. Provides Tab(s) that will be
associated with this app.* *Project will be built as a .jar*

I do not have a Web Application as part of this project. I include a
dependency to* test-common.jar* in test-application-1's POM. (Since I
thought adding dependency to test-container.war did not seem sensible,
correct me if I am wrong.)  One of the panel class in this application
implements the test-common's createAppTab interface and add's the returned
ITab instance into a List. The List<ITab> is added into an instance of
TabbedPanel. The instance of TabbedPanel is added into the Panel. I have a
corresponding basic markup for this Panel class.

*Re-Visit test-container*
I modified the test-container's POM to include test-application-1 as a
dependency(jar) and built it into a .WAR. The war now contains two
jars *test-common.jar
and **test-application-1.jar
Is this build strategy acceptable? In one build, able to include the
dependent application's jar's into one single WAR.

Doubts:*

1. I need to know how these individual applications/plugins will be fired to
render the tabs (create an instance of the tabs) from the test-container.
when the application is started on lands on the Home Page for instance?


[On a side note what I did try on those lines was I created an instance  of
the sub-application's class that implemented the Tab Interface and added it
to the home page instance.
As in..
App1Tab tab1 = new App1Tab("someTab"); //This would fire the constructor and
create the tab instances
add(tab1);

This was not a success, as it comes up with a Wicket runtime exception

ITab.getPanel() returned a panel with invalid id [studyPanel]. You
must always return a panel with id equal to the provided panelId
parameter.
TabbedPanel [8:stab:moduleTabsList] ITab index [0]
]


Thanks for the time, will be great to hear from you on this.

Regards
Niv






On Thu, Jun 10, 2010 at 11:46 AM, Igor Vaynberg <ig...@gmail.com>wrote:

> On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <sh...@gmail.com>
> wrote:
> > Hi Igor,
> >
> > Thank you for the quick response and what a ray of hope it brings! It
> > certainly, from  your experience seems to be a very good design approach.
> I
> > am excited to implement it.
> >
> > The question(s)/confirmation at this point in time is :
> >
> > 1.Will Application 2..(n)  ever extend the sub-class Web Application
> > provided by the Container Application? [I guess not, since Application-2
> > needs to be built as a jar and packaged with Container-Application's WAR.
> > Which means sub application's (jars) will all be part of a Single Wicket
> > Application instance] (Am I right?)
>
> correct, since 2..n are plugins rather then applications they do not
> need their own application class.
>
> > 2. The Tab Provider Interface you mentioned that would be part of the
> common
> > jar in Container-Application; would that be a class like
> > org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is what
> I
> > have used at the moment.
>
> sure, that will work. usually i have something like this
>
> public interface MainTabProvider { ITab newMainTab(); }
>
> followed by
>
> public interface ApplicationPlugin extends TabProvider, .. bunch of
> other interfaces
>
> -igor
> >
> > Appreciate your time. Glad to be using the right framework and not have
> to
> > switch to another framework.
> >
> > Many thanks
> > Regards
> >
> >
> >
> >
> >
> > On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >
> >> ive done this many times already, wicket is perfect for things like
> these.
> >>
> >> application 1 should be a simple wicket container app. this is a full
> >> application with its own subclass of WicketApplication and is what is
> >> going to be packaged as a war file. it should also have a module (jar)
> >> with the interfaces for the common services it provides and a way to
> >> retrieve those interfaces.
> >>
> >> application 2 should be a jar file which contains all the necessary
> >> wicket artifacts such as pages. one of the things in it should be
> >> something that implements a "tabprovider" interface defined in
> >> application 1's common jar. the tabprovider would return a tab that
> >> contains a panel from application 2, this panel would act as the entry
> >> point into the application.
> >>
> >> the only other question is now packaging and deployment. the easiest
> >> way is to take the jar from application 2 and package it into
> >> application 1 as part of the war file. a trickier way to do it is to
> >> have a classloader that can look in some external folder and load from
> >> all the jars there, this external folder would contain the jars for
> >> application 2...n.
> >>
> >> -igor
> >>
> >> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <sh...@gmail.com>
> >> wrote:
> >> > Hi All,
> >> >
> >> > I will try to articulate my requirement. Can I call it a Wicket based
> >> > Portal?
> >> >
> >> > I have an application lets call it Application-1  that provides common
> >> > functionality such as Authentication/Authorization. It also will
> provide
> >> the
> >> > Business layer/Service methods.
> >> > As part of this web application, it builds the the TOP level tab
> menus.
> >> Each
> >> > of the tab menu will represent a related business application. There
> is
> >> one
> >> > single entry point to the whole application suite.
> >> >
> >> > Now, I want to build one of the related business
> >> application(Application-2)
> >> > using Wicket, Hibernate etc and inherit the common functionality
> provided
> >> by
> >> > Application-1. However, I want to provide/or add to the Tab menu
> provided
> >> by
> >> > Application-1 and integrate with it. As part of Application-1, I want
> to
> >> be
> >> > able to provide Tab1. And as part of Appication-2, I want to be able
> to
> >> > provide Tab2.
> >> >
> >> > So when I eventually build the whole application suite, I must be able
> to
> >> > enable/disable a particular application tab or access to an
> application
> >> > through some business rules (License) etc. Also it should give me the
> >> > flexibility to
> >> > maintain each module/application independently and allow me to deploy
> a
> >> > particular module for a client.
> >> >
> >> > It is pretty critical that  I have a good solution that gives a
> >> reasonable
> >> > amount of flexibility. I am sure you must have come across such
> >> > requirements, more like a portal. Only, I have to build it using
> Wicket.
> >> > Just so you are aware this is the set up for the project.
> >> >
> >> > Web Tier: Wicket with Wiquery
> >> > Security: Apache Shiro
> >> > Service Tier: Spring
> >> > Model/Persistence: Hibernate/Spring LDAP
> >> > Servlet Engine: Tomcat
> >> >
> >> > Would be great to hear some pattern I can follow and references if any
> >> that
> >> > can serve as a start-up. Any thoughts/experience from your end would
> be
> >> > great and valuable.
> >> >
> >> > Some doubts that lurks in my mind.
> >> >
> >> > 1. Does Application-2 need to have a Wicket Application .i.e need to
> >> extend
> >> > a Wicket Application? Makes sense if I want to deploy it as a
> stand-alone
> >> > one.But If i want to integrate and use the set up as part of
> >> Application-1,
> >> > should I build the project without a Wicket Applications?
> >> >
> >> > 2. How does Application- 2 render the Tabs and integrate with
> >> Application-1
> >> > that does not know/aware of its child projects?
> >> >
> >> > 3. As an alternative, I can build application-2 as part of
> application-1.
> >> > The downside is, when a client wants only few modules, I would need to
> >> build
> >> > and package the whole suite.This is my last resort but sure your
> thoughts
> >> > will make a difference.
> >> >
> >> > Appreciate your thoughts and time,
> >> >
> >> > Many thanks
> >> > Nivedan
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Using Wicket to build Application Portal

[Igor Vaynberg <ig...@gmail.com>]

On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <sh...@gmail.com> wrote:
> Hi Igor,
>
> Thank you for the quick response and what a ray of hope it brings! It
> certainly, from  your experience seems to be a very good design approach. I
> am excited to implement it.
>
> The question(s)/confirmation at this point in time is :
>
> 1.Will Application 2..(n)  ever extend the sub-class Web Application
> provided by the Container Application? [I guess not, since Application-2
> needs to be built as a jar and packaged with Container-Application's WAR.
> Which means sub application's (jars) will all be part of a Single Wicket
> Application instance] (Am I right?)

correct, since 2..n are plugins rather then applications they do not
need their own application class.

> 2. The Tab Provider Interface you mentioned that would be part of the common
> jar in Container-Application; would that be a class like
> org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is what I
> have used at the moment.

sure, that will work. usually i have something like this

public interface MainTabProvider { ITab newMainTab(); }

followed by

public interface ApplicationPlugin extends TabProvider, .. bunch of
other interfaces

-igor
>
> Appreciate your time. Glad to be using the right framework and not have to
> switch to another framework.
>
> Many thanks
> Regards
>
>
>
>
>
> On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> ive done this many times already, wicket is perfect for things like these.
>>
>> application 1 should be a simple wicket container app. this is a full
>> application with its own subclass of WicketApplication and is what is
>> going to be packaged as a war file. it should also have a module (jar)
>> with the interfaces for the common services it provides and a way to
>> retrieve those interfaces.
>>
>> application 2 should be a jar file which contains all the necessary
>> wicket artifacts such as pages. one of the things in it should be
>> something that implements a "tabprovider" interface defined in
>> application 1's common jar. the tabprovider would return a tab that
>> contains a panel from application 2, this panel would act as the entry
>> point into the application.
>>
>> the only other question is now packaging and deployment. the easiest
>> way is to take the jar from application 2 and package it into
>> application 1 as part of the war file. a trickier way to do it is to
>> have a classloader that can look in some external folder and load from
>> all the jars there, this external folder would contain the jars for
>> application 2...n.
>>
>> -igor
>>
>> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <sh...@gmail.com>
>> wrote:
>> > Hi All,
>> >
>> > I will try to articulate my requirement. Can I call it a Wicket based
>> > Portal?
>> >
>> > I have an application lets call it Application-1  that provides common
>> > functionality such as Authentication/Authorization. It also will provide
>> the
>> > Business layer/Service methods.
>> > As part of this web application, it builds the the TOP level tab menus.
>> Each
>> > of the tab menu will represent a related business application. There is
>> one
>> > single entry point to the whole application suite.
>> >
>> > Now, I want to build one of the related business
>> application(Application-2)
>> > using Wicket, Hibernate etc and inherit the common functionality provided
>> by
>> > Application-1. However, I want to provide/or add to the Tab menu provided
>> by
>> > Application-1 and integrate with it. As part of Application-1, I want to
>> be
>> > able to provide Tab1. And as part of Appication-2, I want to be able to
>> > provide Tab2.
>> >
>> > So when I eventually build the whole application suite, I must be able to
>> > enable/disable a particular application tab or access to an application
>> > through some business rules (License) etc. Also it should give me the
>> > flexibility to
>> > maintain each module/application independently and allow me to deploy a
>> > particular module for a client.
>> >
>> > It is pretty critical that  I have a good solution that gives a
>> reasonable
>> > amount of flexibility. I am sure you must have come across such
>> > requirements, more like a portal. Only, I have to build it using Wicket.
>> > Just so you are aware this is the set up for the project.
>> >
>> > Web Tier: Wicket with Wiquery
>> > Security: Apache Shiro
>> > Service Tier: Spring
>> > Model/Persistence: Hibernate/Spring LDAP
>> > Servlet Engine: Tomcat
>> >
>> > Would be great to hear some pattern I can follow and references if any
>> that
>> > can serve as a start-up. Any thoughts/experience from your end would be
>> > great and valuable.
>> >
>> > Some doubts that lurks in my mind.
>> >
>> > 1. Does Application-2 need to have a Wicket Application .i.e need to
>> extend
>> > a Wicket Application? Makes sense if I want to deploy it as a stand-alone
>> > one.But If i want to integrate and use the set up as part of
>> Application-1,
>> > should I build the project without a Wicket Applications?
>> >
>> > 2. How does Application- 2 render the Tabs and integrate with
>> Application-1
>> > that does not know/aware of its child projects?
>> >
>> > 3. As an alternative, I can build application-2 as part of application-1.
>> > The downside is, when a client wants only few modules, I would need to
>> build
>> > and package the whole suite.This is my last resort but sure your thoughts
>> > will make a difference.
>> >
>> > Appreciate your thoughts and time,
>> >
>> > Many thanks
>> > Nivedan
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Using Wicket to build Application Portal

[Nivedan Nadaraj <sh...@gmail.com>]

Hi Igor,

Thank you for the quick response and what a ray of hope it brings! It
certainly, from  your experience seems to be a very good design approach. I
am excited to implement it.

The question(s)/confirmation at this point in time is :

1.Will Application 2..(n)  ever extend the sub-class Web Application
provided by the Container Application? [I guess not, since Application-2
needs to be built as a jar and packaged with Container-Application's WAR.
Which means sub application's (jars) will all be part of a Single Wicket
Application instance] (Am I right?)

2. The Tab Provider Interface you mentioned that would be part of the common
jar in Container-Application; would that be a class like
org.apache.wicket.extensions.markup.html.tabs.AbstractTab ? This is what I
have used at the moment.

Appreciate your time. Glad to be using the right framework and not have to
switch to another framework.

Many thanks
Regards





On Wed, Jun 9, 2010 at 10:44 PM, Igor Vaynberg <ig...@gmail.com>wrote:

> ive done this many times already, wicket is perfect for things like these.
>
> application 1 should be a simple wicket container app. this is a full
> application with its own subclass of WicketApplication and is what is
> going to be packaged as a war file. it should also have a module (jar)
> with the interfaces for the common services it provides and a way to
> retrieve those interfaces.
>
> application 2 should be a jar file which contains all the necessary
> wicket artifacts such as pages. one of the things in it should be
> something that implements a "tabprovider" interface defined in
> application 1's common jar. the tabprovider would return a tab that
> contains a panel from application 2, this panel would act as the entry
> point into the application.
>
> the only other question is now packaging and deployment. the easiest
> way is to take the jar from application 2 and package it into
> application 1 as part of the war file. a trickier way to do it is to
> have a classloader that can look in some external folder and load from
> all the jars there, this external folder would contain the jars for
> application 2...n.
>
> -igor
>
> On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <sh...@gmail.com>
> wrote:
> > Hi All,
> >
> > I will try to articulate my requirement. Can I call it a Wicket based
> > Portal?
> >
> > I have an application lets call it Application-1  that provides common
> > functionality such as Authentication/Authorization. It also will provide
> the
> > Business layer/Service methods.
> > As part of this web application, it builds the the TOP level tab menus.
> Each
> > of the tab menu will represent a related business application. There is
> one
> > single entry point to the whole application suite.
> >
> > Now, I want to build one of the related business
> application(Application-2)
> > using Wicket, Hibernate etc and inherit the common functionality provided
> by
> > Application-1. However, I want to provide/or add to the Tab menu provided
> by
> > Application-1 and integrate with it. As part of Application-1, I want to
> be
> > able to provide Tab1. And as part of Appication-2, I want to be able to
> > provide Tab2.
> >
> > So when I eventually build the whole application suite, I must be able to
> > enable/disable a particular application tab or access to an application
> > through some business rules (License) etc. Also it should give me the
> > flexibility to
> > maintain each module/application independently and allow me to deploy a
> > particular module for a client.
> >
> > It is pretty critical that  I have a good solution that gives a
> reasonable
> > amount of flexibility. I am sure you must have come across such
> > requirements, more like a portal. Only, I have to build it using Wicket.
> > Just so you are aware this is the set up for the project.
> >
> > Web Tier: Wicket with Wiquery
> > Security: Apache Shiro
> > Service Tier: Spring
> > Model/Persistence: Hibernate/Spring LDAP
> > Servlet Engine: Tomcat
> >
> > Would be great to hear some pattern I can follow and references if any
> that
> > can serve as a start-up. Any thoughts/experience from your end would be
> > great and valuable.
> >
> > Some doubts that lurks in my mind.
> >
> > 1. Does Application-2 need to have a Wicket Application .i.e need to
> extend
> > a Wicket Application? Makes sense if I want to deploy it as a stand-alone
> > one.But If i want to integrate and use the set up as part of
> Application-1,
> > should I build the project without a Wicket Applications?
> >
> > 2. How does Application- 2 render the Tabs and integrate with
> Application-1
> > that does not know/aware of its child projects?
> >
> > 3. As an alternative, I can build application-2 as part of application-1.
> > The downside is, when a client wants only few modules, I would need to
> build
> > and package the whole suite.This is my last resort but sure your thoughts
> > will make a difference.
> >
> > Appreciate your thoughts and time,
> >
> > Many thanks
> > Nivedan
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Using Wicket to build Application Portal

[Igor Vaynberg <ig...@gmail.com>]

ive done this many times already, wicket is perfect for things like these.

application 1 should be a simple wicket container app. this is a full
application with its own subclass of WicketApplication and is what is
going to be packaged as a war file. it should also have a module (jar)
with the interfaces for the common services it provides and a way to
retrieve those interfaces.

application 2 should be a jar file which contains all the necessary
wicket artifacts such as pages. one of the things in it should be
something that implements a "tabprovider" interface defined in
application 1's common jar. the tabprovider would return a tab that
contains a panel from application 2, this panel would act as the entry
point into the application.

the only other question is now packaging and deployment. the easiest
way is to take the jar from application 2 and package it into
application 1 as part of the war file. a trickier way to do it is to
have a classloader that can look in some external folder and load from
all the jars there, this external folder would contain the jars for
application 2...n.

-igor

On Wed, Jun 9, 2010 at 7:11 AM, Nivedan Nadaraj <sh...@gmail.com> wrote:
> Hi All,
>
> I will try to articulate my requirement. Can I call it a Wicket based
> Portal?
>
> I have an application lets call it Application-1  that provides common
> functionality such as Authentication/Authorization. It also will provide the
> Business layer/Service methods.
> As part of this web application, it builds the the TOP level tab menus. Each
> of the tab menu will represent a related business application. There is one
> single entry point to the whole application suite.
>
> Now, I want to build one of the related business application(Application-2)
> using Wicket, Hibernate etc and inherit the common functionality provided by
> Application-1. However, I want to provide/or add to the Tab menu provided by
> Application-1 and integrate with it. As part of Application-1, I want to be
> able to provide Tab1. And as part of Appication-2, I want to be able to
> provide Tab2.
>
> So when I eventually build the whole application suite, I must be able to
> enable/disable a particular application tab or access to an application
> through some business rules (License) etc. Also it should give me the
> flexibility to
> maintain each module/application independently and allow me to deploy a
> particular module for a client.
>
> It is pretty critical that  I have a good solution that gives a reasonable
> amount of flexibility. I am sure you must have come across such
> requirements, more like a portal. Only, I have to build it using Wicket.
> Just so you are aware this is the set up for the project.
>
> Web Tier: Wicket with Wiquery
> Security: Apache Shiro
> Service Tier: Spring
> Model/Persistence: Hibernate/Spring LDAP
> Servlet Engine: Tomcat
>
> Would be great to hear some pattern I can follow and references if any that
> can serve as a start-up. Any thoughts/experience from your end would be
> great and valuable.
>
> Some doubts that lurks in my mind.
>
> 1. Does Application-2 need to have a Wicket Application .i.e need to extend
> a Wicket Application? Makes sense if I want to deploy it as a stand-alone
> one.But If i want to integrate and use the set up as part of Application-1,
> should I build the project without a Wicket Applications?
>
> 2. How does Application- 2 render the Tabs and integrate with Application-1
> that does not know/aware of its child projects?
>
> 3. As an alternative, I can build application-2 as part of application-1.
> The downside is, when a client wants only few modules, I would need to build
> and package the whole suite.This is my last resort but sure your thoughts
> will make a difference.
>
> Appreciate your thoughts and time,
>
> Many thanks
> Nivedan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org