Edmund Lian wrote:
> Website design aside, that issue of Webware not going anywhere is a
> thorny one. It is a great, easy to use platform, but we are all
> reinventing the wheel in that there is no easy way for us to build
> reuseable, modular applications in the same sense that Zope has (maybe
> this is a bad example).
I don't think it's that bad an example. Zope is component-oriented, after
all. However, I do agree that in certain respects, it can be unclear...
* Where to develop certain functionality. The repeated
discussions on user handling seem to underline this.
* How to reuse other people's contributions. Zope is arguably
a lot clearer on this - distribute Zope Products and others
may be able to integrate them cleanly into their solutions.
> What I mean is that the very flexible, open nature of Webware that
> attracted each of us to it also means that each of us uses different
> bits and pieces to suit our (legitimate) project needs. But building
> Humpty-Dumpty requires more than finding pieces and trying to fit them
> together. It actually requires a higher level understanding of what
> the whole looks like and how current and future pieces can and should
> fit together. It is this higher level framework that seems to be
Yes, Webware puts everything onto the Python level, meaning that application
development experience in Python can be used more effectively, and with
integration into the Webware framework at the correct level (my favourite
point is the servlet factory) you can make Webware fit your own code to a
However, since there are many different points at which integration can
occur (servlet factory, Page subclasses, PSP resources, other things I
haven't looked into), there is arguably a dilemma about how and where in the
framework code should be developed and deployed to encourage widespread
reuse. Moreover, the plug-in mechanism doesn't seem to go far enough in
encouraging extensions which work across all these points of deployment, at
least as far as I can tell.
> I, for example, am using Webware, FunFormKit, Cheetah, and PostgreSQL
> because flexibility and data integrity matters to me.
> Somebody else might use Webware, PSP, MiddleKit, and MySQL, because
> ease of development and deployment matters to him. When this happens,
> we can't use each other's model or controller logic (I'm using the MVC
> paradigm as a basis of discussion here) because we don't even have a
> consistent way to reuse basic stuff like user authentication,
> security, etc. And we can't reuse the view level logic because we
> don't use the same presentation level techniques.
Indeed. If someone introduces authentication/authorisation as a mix-in
class, that method may not be appropriate for other application
architectures. How would I cleanly employ such a mix-in in an architecture
which has its own kinds of servlets, for example? There is a certain
argument for pushing certain kinds of functionality as deep as possible into
Of course, database systems can sit behind a layer of abstraction, and this
could be a reasonable approach for other pieces of functionality.
Potentially, the plug-in concept could be employed to introduce such things
in a manner similar to that exhibited by Zope Products, but I think that the
Application class (which seems to be where most integration action really
takes place) needs more attention to support such ideas.
> It seems to me that for Webware to go anywhere in terms of developing
> a rich selection of ready-to-run packages and universally useful
> things like authentication and security, we need to agree to some
> standard application-level framework, API, database, etc.
Some things can be done easily. For example, the CGI-style API can be
extended to include things like support for content encoding and agent
languages. However, other things do not necessarily have easy answers. In
effect, Webware gives a degree of architectural freedom that other
frameworks might not permit, but defers the addressing of the hard questions
that come with that freedom.
P.S. I haven't been following the list for over a week, so I hope these
issues haven't already been discussed in depth.