So why shouldn't I use a Web Dynpro Project?
The project type "Web Dynpro Project" was developed before SAP had any development infrastructure software. The drawback with this type of project is that it behaves like a sealed, non-reusable container.
Nowadays, we have the NetWeaver Development Infrastructure (NWDI) to manage source versions, build dependencies and transports. This means that unless you are writing a very simple training or demo application, you should not use a project type of "Web Dynpro Project".
OK, what should I use instead?
The answer is that you should always use Development Components (DCs) of type "Web Dynpro". Even if you do not have a working NWDI installed, you can still create Local Development objects. In the ABAP world, this is equivalent to creating objects of package (formerly Development Class) $TMP.
The point here is that a DC is a reusable entity. If you have already created a Web Dynpro Project, then for comparison purposes, it is useful to create a DC of type Web Dynpro, and then expand the first level of the project hierarchy. You will notice that the Web Dynpro Project has three nodes directly under the project branch, but the DC of type Web Dynpro has four. The extra branch is critically important. This is the "DC Metadata" branch, and it is here that you can declare both the usage dependencies to other DCs (under "DC Definition"), and those parts of your DC that will be publicly available (under "Public Parts").
How should DC's be used then?
The DC of type Web Dynpro represents a reusable unit of code. This concept gives you a high level of flexibility over how your DCs should be structured, so it is not possible for me to give any exact rules about how much code should be put into one DC. However, there are some general principles to follow:
- A DC should be structured such that it represents a self contained unit of business processing.
- If a DC is made too small, then you will have highly fragmented reuse situations and end up with a complex network of inter-DC dependencies.
- On the other hand, if you make a DC too big, then you restrict its reusability because it will contain more functionality than is required for an individual reuse case.
- DCs expose their internal functionality through the concept of Public Parts (PPs). The PP is a compiled and delivered as a separate .jar file.
When you create the Web Dynpro Components within the DC, you should decide which functionality will be publicly visible, and which will remain hidden within the DC.
When you have identified a unit of functionality (for instance, a particular component) that needs to be publicly available, you should right mouse click on that entity, and select "Add to Public Part".
If you have not created a PP before, then the first screen you will see asks you to create the PP. Give some meaningful name that describes the exposed object or functionality, and then the PP will be created and the entity added to it.
That's pretty easy. Is that all there is to it?
N O !
Remember I said that the PPs of a DC are implemented as separate .jar files? Well, the PP jar files need to be built - this is a second, independent build process from the "Rebuild Project" option that you normally use. You must therefore select "Development Component" from the right mouse click menu on the DC node, and then select "Build" from the side-menu. Only then will the PP jar file be built.
If you forget to do a DC build, then you'll probably be able to deploy your application (though without the PP jar files), but you'll experience runtime dependencies failures.
So how do I reuse this functionality?
Once you have developed a DC and built its PPs, you can then declare a usage dependency from another DC. A very useful example here is to split the model objects required by a Web Dynpro application into a separate DC. In this model DC, you create only the model objects - no Web Dynpro components. Then you add each model object to its own PP (don't forget to do a DC build each time a PP changes).
Lets say that you are now writing another DC that wishes to use one of the model objects in the model DC. So under the "DC definition" branch of "DC Metadata", you will find the "Used DCs" branch. Here is where you can add a usage declaration to the model DC. Once you have done this, when you want to add a model usage to your Web Dynpro component, you will see all the models in the model DC when you select the "Add" option from the Used Models branch (if you don't see any model objects when you select "Add", its probably because you haven't built the PPs of the model DC.
By putting the model objects into a separate DC, the model object source code only needs to be compiled once (usually a time consuming process), and then the DC that has declared a usage of the model DC only needs to reference the compiled code. This greatly speeds up development time!
