Petru Paler wrote:
Hi eveyone.
While playing around with the development version of ACS (ArsDigita Community
System), I noticed a very nice feature they introduced, namely page contracts.
I've been working with the ACS quite a bit lately (day-job:). its a nice
a system that offers a lot utility functions that would be nice to see
ported over to zope. most of its value lies in its data models. zope and
the acs have vastly different semantic models. i honestly see a lot of
the acs work as hacks around some of the problems of the programming
paradigms enforced by aolserver, that have little meaning in a system as
expressive and customizable as zopes(object publishing v. page
publishing sql apps).
with regards to the page_contract.
IMO its def. useful from the standpoint of documentation and error
checking for your variables. implementing this as a folder of utility
methods and simply calling them from any doc that acquires from them,
passing in the request and optional args (props of doc?a nd this()?),
achieves the needed effect without much effort, and offering quite a bit
by way of customization.
its also possible to do this as a python mixin class for objects. but it
would require a alot more work to do it transparently to the developer.
Kapil
In ACS, this means that every tcl page starts with a call to ad_page_contract.
In the parameters passed, you specify:
- general page documentation (what it does)
- author(s)
- creation date (not needed for Zope since we have bobobase_modification_time)
- CVS ID (not quite applicable for Zope (yet?))
- the expected input variables (from forms) along with their default values
(where applicable) and types (having a couple of types like "integer" and "string"
predefined and an easy-to-use plugin system to add custom types)
- an optional validation block in which you can check the input data ranges
and validity (you can also make validation rules depend on each other so if
one fails, the rules which depend on it aren't tried)
- an optional custom error messages section (to use when one of the required
input variables is not there or does not match the format, or when a validation
block fails). If you don't provide this some reasonable defaults are provided.
IMHO, such a feature would be very useful for Zope too. I find myself quite
often doing input validation and error handling in DTML, which is (to say the
least) painful.
I would be interested to give a try at implementing this, but before starting
I wanted to hear community's opinion on:
- whether this would be useful
- how this should be aproached (the two possibilities I have in mind until
now are either a separate manage tab for the page contract, and there a
HTML-based interface for building it, either a dtml-contract tag which
surrounds the page contract (written in python probably) and placed at the
top of DTML documents/methods).
--
Petru Paler, mailto:[EMAIL PROTECTED]
http://www.ppetru.net - ICQ: 41817235
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
