CODEWITHSUNDEEP
javawicketcode-reuse
Marcelo
Marcelo

Reputation: 11308

How can I reuse code when two different wicket applications share common functionality

I have a Wicket AuthenticatedWebApplication which has several pages and features that need to be reused in a new AuthenticatedWebApplication that I have to develop.

I am using Wicket 1.4, Spring and Hibernate.

Both applications will even share the same look (except for Application logo) which is now implemented in a base page.

Has anyone had a similar experience? I definitely don't want to recur to copy-paste code because the common functionality implements a workflow process which can and will change.

What can I do to keep my applications modular, and achieve my goal?

Upvotes: 1

Views: 581

Answers (4)

Nicktar
Nicktar

Reputation: 5575

Judging from your other comments and answers:

  1. Refactor your application and push all common code to (abstract) base classes.
  2. Move these to a new project and set the BuildPath of your 2 new application-projects to require the base package.
  3. Extend your base classes to implement the changing functionality.

Depending on your current implementation, you can change your logo by implementing two different imageresources or by providing different models from your new projects to your basebasepage or you could put the image-url into your properties and supply different propertyfiles in your applications. The same is valid for databases or tables... For example with JPA you colud push all the global used entities to your base and implement two different user-entities using different table names. You could even use a shared abstract baseUser-entity to reduce code duplication there.

Upvotes: 1

jbrookover
jbrookover

Reputation: 5150

My company does this all the time. We have a core package that holds the base UserApplication, User accounts, login, authentication, etc. Then, every project we develop extends this base package. There is some duplication - e.g. almost all of the configuration files look identical in each - but each one has it's own theme directory that supplies the markup, customized to the look and feel of the application.

Some suggestions as you do this:

  1. The core application should have a fair number of getXPanel() methods that each sub-application overrides. For example, getHeaderPanel()
  2. Use a "BasePage" class that everyone extends. This is where you set up your overall look-and-feel, overridden in sub-application theme folders, and make heavy use of <wicket:extend> features. Also a good place to put your jQuery import, ec.
  3. Keep in mind that markup is easily overridden. Your sub-application doesn't need to create java extensions of pages in order to change the logos. Just use different markup.

Each of our applications is divided into at least 4 modules. For example:

  1. base - Wicket dependency, basic event logging
  2. data - UserApplication, AdminPage, User hibernate obect. Each page has its own markup, but is usually overridden.
  3. science - A core project with a lot of code for displaying a science textbook. ScienceApplication extends UserAppication.
  4. foundations - A theme specific implementation for elementary students FoundationsApplication extends ScienceApplication
  5. inquiry - A different theme specific implementation for high school students InquiryApplication extends ScienceApplication

Our two science applications have different headers and even a few different pages, but ScienceApplication has a those methods I described above.

Upvotes: 1

salman.mirghasemi
salman.mirghasemi

Reputation: 1059

From your question I guess your main concern is about pages. Then this is my suggestion: First, you should specify which parts of the pages can change from one application to another application. Then you have to take out the data of these parts to get the templates. Now you should decide (based on your requirement) how you want to store data (e.g., in xml files, DB). Now you can compile your pages from templates online or offline based on your needs.

Upvotes: 0

martin-g
martin-g

Reputation: 17533

This is the main point of component based frameworks. Put the common code (components, behaviors, base classes as session, application, ...) in a separate java project (.jar). Later depend on this project in the specific .war projects (put the .jar in WEB-INF/lib). Voila!

Upvotes: 1

Related Questions