[an error occurred while processing this directive]
> developer > web app development
Sharing your Director Components
by Dennis Meers, Lead Consulting Engineer, Novell
Date Created: 2002-05-28 18:13:00.000
  Introduction
introduction
Download the sample code for this article.

So, you wrote the world's greatest component and you want to share it with everyone. How do you do it?

In the good old days of ePortal, you probably zipped up the source (or maybe just a JAR) and sent it off to your friend. She simply unzipped the component, used the PAC to register it, and BAM - instant component! Well, in the brave new world of J2EE and eXtend Director, life ain't so simple. We now have JARs, WARs, EARs, LibPaths, ResourceSets and more to contend with.

In order to share components with my colleagues, I decided to use the template facility inside Director. Director's template facility uses an existing directory structure that contains code. The template wizards decide which pieces of the template you need, and copy or massage the data into your project. Whenever you create a new Director project using the "Director EAR" wizard, you're really using the template facility. You can modify any existing Director project by using the "Project->Director Ear->Setup" menu in SilverStream eXtend Workbench. Again, you're using the template to do this. The template is merely a disk directory that holds all (or part) of a Director project.

When a template is used in Director, the system scans the template directory for wizards. When one is found, it is instantiated. So, for my purposes, I decided it would be useful to create my own wizard for sharing components. I wanted my wizard to be able to do the following:
  • Add a subproject to any project inside the Director project
  • Copy files from the template directory to a directory inside the Director project
  • Modify the LibPath and ResourcePath (for vulturing)
  • Add dependent sub-projects to the Director project
  • Add J2EE artifacts to the project (WARs, JARs, etc.)
  • Be flexible enough to accept new components without having to change the wizard code

My ultimate goal was to allow the developer to pick from a set of components that could be delivered ready-to-go to the Director project. The developer would not have to make any changes to the project. He could just re-deploy and begin using the components.

Now that you have a better understanding of my design goals for this tool, let's take a look at how to use it. First, take the zip file that's attached to this article and unzip it somewhere on your system. I've stored mine in "C:\DirectorTemplates".

Next, either create a new Director project or open an existing one. Then use the menu item "Project->Director Ear->Setup" to begin the process as shown in the following window:



You will then get the "setup option" window, which will let you add or remove subsystems from your Director project. Select "add".



When you click "next", you will get the "template location" window. By default, the template location shown will be the last template you used. Use the button to browse to the location where you stored the template. When you click next, you'll see a message telling you the name of the template you've picked. You should see something like the following:



Now, simply click on "yes" to continue. The next window will present a list of components. These are simply the entries from "components.xml". You can add new components to this file and they will appear in this window. The zip file attached to this article contains three components, so you'll see the following window:



You can click on any (or all) of the checkboxes to add the component(s) to your project.

Once you've made your component selection, you will get a window with a "finish" button. Click finish and watch the magic happen; the selected component(s) will be added to your project.

Once the components are added, an automatic rebuild of your project will begin. It should build successfully and the components should be ready to use. Here's what my project looked like after I added all the components.



You can see that five JARs have been added to my ResourceSet, even though I only requested three components. The dependent projects were automatically added, resulting in the extra two. In fact, an entire WAR (AccuWeatherLoad.war) was added to my project because the "weather" component must have the weather loaded into tables. AccuWeatherLoad.war contains a servlet that loads the weather tables with data from the weather source. This WAR was listed as a dependency for the weather component, so the wizard automatically included it. Everything that was needed for the components to function correctly was added to my project. I didn't have to add anything else or change any settings.

The attached sample contains three components: a calendar component, a search component, and a weather component. The calendar component has ended up in more than a few portals. I've included the newest version here, which now allows for multiple calendars. This version also uses the content management system to store events and built-in security to handle calendar updates. The search component uses the Autonomy search engine, and the weather component, which is meant for sample use only, connects to a weather service to provide the current weather outlook in US cities. (To use the weather component in a production environment, you must sign up with AccuWeather, the weather service provider.)

Now that you've seen how my wizard functions, let's take a look inside it. To allow for maximum flexibility, I opted to control the wizard through XML files. There is a main XML file called "components.xml". This file contains a list of components that can be added to the director project. This enables the wizard to separate the user-selected components from those that are added automatically, enabling it to handle cases where one or more components depend on a framework component. I didn't want the user to have to add a framework component in order to add a calendar component rather I wanted the framework component to be added automatically.

For each component there is an XML file that describes the following:
  • Dependent components
  • Files that should be copied
  • Modifications that need to be made to the LibPath or ResourcePath
  • The target project
  • The target directory
  • The project file
  • The archive location
  • Any miscellaneous files that may need to be copied
  • Any other projects that may need modification

Following is the XML I created to add a calendar component to the Director project: 




<component>

    <dependencies>

        <depends>framework</depends>

    </dependencies>

    <target-project>ResourceSet</target-project>

    <target-subfolder>/WEB-INF/lib/</target-subfolder>

    <folder>calendar</folder>

    <project-file>calendar\build-calendar-components.spf</project-file>

    <archive-location>calendar.jar</archive-location>

    <resource-vulture>data</resource-vulture>

    <lib-vulture>build/calendar-components-classes</lib-vulture>

    <misc>

                <copy-file>

                                <source>misc/calendar/jsp</source>

                                <target>Portal/jsp</target>

                </copy-file>

                <copy-file>

                                <source>misc/calendar/portal-page</source>

                                <target>ResourceSet/data/portal-page</target>

                </copy-file>

                <copy-file>

                                <source>misc/taglib</source>

                                <target>Portal</target>

                </copy-file>

                <add-to-project>

                                <project>Portal</project>

                                <source>Portal/WEB-INF/tag</source>

                </add-to-project>



    </misc>

</component>


This component depends on a "framework" project that must be included. The wizard will check to see if the framework project already exists in your Director project. If it does, it won't be added again. The "target-project" tag specifies that this component should be added as a sub-project in the "ResourceSet" project. The "target-subfolder" tag instructs the wizard to add the files to the "/WEB-INF/lib/" directory under "ResourceSet". You can specify additional actions for the wizard in the "misc" tag. Here the misc tag is telling the wizard to copy some JSPs into the "Portal/jsp" directory and some portal pages into the "ResourceSet/data/portal-page" directory. It is also specifying that some "taglibs" be copied and added to the portal project.

So, what would you have to do to add your own components to this tool? Well, you would change "components.xml" so your component shows up. Then you would create an XML file (like the calendar.xml file above) that describes what to copy, where to put the sub-project, etc. Then, you would put the actual files (spf, XML, Java, etc.) from your component into the template directory. In the calendar example, there are files in the following:
  • C:\DirectorTemplates\Components\WEB-INF\lib\calendar - the build, data, and src directories for the component, as well as the project file(s)
  • C:\DirectorTemplates\Components\misc\calendar - the jsp and portal-page subdirectories for sample jsps and HTML pages for this component
  • C:\DirectorTemplates\Components\misc\taglib - the tag library directories for using the portal tags in jsps

You'd also have to make sure that there are no hard-coded paths in the classpath of your component. These directories might not be available on the developer's machine. In other words, always use relative paths.

Hopefully, this tool gives you an easy way to share your components with others. It removes the burden of having to walk someone through a setup process, so they can use your components right out of the box. Maybe the good old days aren't gone yet!