I have written a manual for the EPF Composer, containing installation and
configuration instructions, tutorials and a user manual. It is a draft
version, created from the help files and from the experience gathered while
experimenting with the application. I have tried to send it twice over the
last ten days but it does not seem to get through. One point
bothered me in the EPF Composer. I would have found it more natural to
have the Plug-ins split into two different types: Method Plug-ins and a Process
Plug-ins. It does not seem natural, once the subject area has been nicely
decomposed into an hierarchical model with sub-areas having their own plug-ins
and content packages, to have to have processes in one of these plug-ins access
the method content in the other plug-ins. The need for the processes to
use the services of an outside service, i.e. a default configuration, to be able
to access the content in the other plug-ins, makes it even more
convoluted. It would be more logical to separate out the processes code
from the method content plug-in into a process plug-in type and move/copy the
code from the configuration’s "Plug-in and Package" selection over to this new
plug-in type so that the process by its very nature can access other method
content plug-ins/packages. The Configuration would then no longer have the
hybrid functions of both providing access assistance to processes and
configuration for publishing. It would seem to be a cleaner separation:
the method content plug-in provides static method content, the process plug-in
provides processes and configuration provides configurations for
publishing. It seems that the authors of EPF Practices have made
the same observation, since they have created a method plug-in with the name of
"Process", accessing content packages in the "Practice" method content
plug-in.
Regards,
Bjorn
|