On Wed, Jun 9, 2010 at 8:20 PM, Nivedan Nadaraj <[email protected]> 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 <[email protected]>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 <[email protected]>
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
