THE PROBLEM
-------------------------------------------------------------------------------------------------------
Webware's package layout / component system needs refactoring for
the following reasons:
* it relies too heavily on a particular directory structure, which
will cause problems with a system-wide install via distutils.
* it will lead to namespace pollution of PYTHONPATH when the
transition is made to system-wide installs.
* it dictates too much about how components/plugins should be
packaged and documented.
* some of the kits should really be part of WebKit's core. For
example, COMKit functionality can easily be coded directly into
the AppServer (or MultiPortServer in the redesign code I've
been working on). It took 8 lines in the redesign code, rather
than 93 lines in 2 extra files and 4 directories with COMKit.
Ditto for TaskKit. The code for managing SessionStores in the
redesign code was more compact, more efficient and much simpler
without TaskKit.
* my old objection to the name WebKit: for marketing and ease of
introduction reasons it is better to position Webware as
"A Python-Powered Application Server, that comes with a
object-oriented library of useful components" than as
"a suite of software components for developing object-oriented,
web-based applications." WebKit is the heart of Webware, so
why not get rid of the extra name to explain? Also see my
proposed package structure below for more reasons.
Its sounds like Webware will eventually be packaged using distutils.
At that time all the Webware components will be sitting in
/usr/local/lib/Python-x.x/site-packages. Think of how MiscUtils,
WebUtils, etc. will look there. Chuck has mentioned the use of a
Webware.pth file to group all the Webware components into a 'Webware'
sub-directory that gets added into PYTHONPATH; thus requiring no
major change to the existing Webware directory structure. I'd argue
that this is hack to avoid. Sure it's a quick solution, but it's
really no different than putting all the Webware subdirs directly
into site-packages. It solves none of the issues listed above.
Instead of just having 'Webware' in the PYTHONPATH namespace we'll
have:
[internally developed components]
- WebKit
- MiscUtils
- WebUtils
- UserKit
- COMKit
- TaskKit
- MiddleKit
- PSP
[externally developed components]
+ Cheetah
+ FunFormKit
+ etc.
THE SOLUTION
-------------------------------------------------------------------------------------------------------
1) Refactor the directory/package layout:
Make all the components that are developed in the main Webware CVS
subpackages of the main 'Webware' package:
[internally developed components]
- Webware (with all the WebKit classes at the top-level)
Webware.MiscUtils
Webware.WebUtils
Webware.PSP
Webware.UserKit
Webware.MiddleKit
[externally developed components]
+ Cheetah
+ FunFormKit
2) Refactor the component/plugin loading system:
It currently operates through the file system. It is better to have
the plugins loaded as live Python classes and leave where they come
from upto the launcher script, or whatever is loading the system.
This is much more flexible and suited for growth!
3) Merge COMKit into the core as I've done in the redesign code I've
been working on.
4) Get rid of TaskKit. It's better to do this sort of stuff on a
case-by-case basis, as illustrated by the implementation of
SessionStore in the redesign code. Simpler, faster, smaller.
ADVANTAGES
-------------------------------------------------------------------------------------------------------
* no namespace pollution: only 1 name is exposed in PYTHONPATH
rather than 8!
* simpler to explain and document
* more flexible as it uses Python's package system rather than
relying on a particular directory layout.
* easier to customize Webware for new uses
* no mangling of PYTHONPATH or sys.path is required.
QUESTIONS & ANSWERS
-------------------------------------------------------------------------------------------------------
Q: But won't this break existing code?
A: No! I've written some code to make sure that import statements
that rely on the existing structure will continue to work.
Q: Where would the docs and examples go for the components?
A: For the internally developed components they would go either in
the main Users' Guide (my pref), or in the package dir of each
component. NB: I've written some distutils code that allows
the docs to be installed centrally in site-packages as
'data-files'.
For externally developed components, such as Cheetah, they
would go wherever the components' developers want to put them.
Note, I'm also advocating that the Webware docs be written in
LaTeX, like Python's and Cheetah's, so they can be output in
multiple formats. Rather than having separate docs for each
component, I'd suggest having a Beginners' Guide, an Users'
Guide, and a Developers' Guide. Each internally developed
component would have a chapter in the relevant Guides.
Q: But won't it take too much effort to change?
A: No, most of the work is already done. Besides a little effort
now will pay off big-time in the future as Webware grows. It's
better to do this sort of refactoring while Webware is still
young.
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
