[ZPatterns] ZPatterns Extensions

[Roché Compaan]

Steve Spicklemire wrote:
> I am also use ZPatterns heavily on projects. Unfortunately (or 
> fortunately, depending how you see it) I've been too busy with a couple 
> of projects to work much with PEAK.

>> 1.Are you still actively using ZPatterns?
> 
> 
> Yes.. I can't imagine using Zope without it, or something like it (PEAK?)

That's really good to here and more than enough to convince me to write
up some documentation and release extensions that can potentially aid
newcomers and existing users in ZPatterns.

>> 2.Do you think we are wasting our time writing some howtos and releasing
>> extensions that can benefit especially newcomers, even though Zope3 and
>> Peak are on the horison?
> 
> That's harder to answer. I personally think that it would not be a waste 
> of time, since I'm guessing that many of the concepts of ZPatterns are 
> important enough that they will find their way into PEAK/Zope3, so that 
> any work done in this area will be a step ahead in documenting the newer 
> systems. Also, if like you, folks needs something today, they will be 
> immediately useful.

And although developers are greeted with a lot of complicated concepts 
when they first meet ZPatterns, there is often enough hooks to make them
persist until they find great joy - we can make this easier though, by 
just sharing what we know.

> 
>>
>> Now our add-ons.
>>
>> The first was basically taking Steve Spicklemire's idea of "levers" that
>> generate SQL and SkinScript further and making a file system product of
>> it.  A SQLRack (as we call it) can generate SQL and SkinScript from
>> ZClass propertysheets or a filesystem Dataskin's "_properties".
> 
> 
> Cool! I've also been pushing levers into a filesystem based product, but 
> nothing usable by anyone but me at this point. They do make building 
> complex systems a lot more manageable. I was thinking of having 
> specialized levers that can be configured to produce either catalog 
> queries, or database queries, or ???, based on configuration. I was also 
> toying with expanding _properties to include things like indexes and 
> more specific type information that RDBs tend to prefer.

I think we should just start throwing everything in a pot and those
with the time can refine and document it.  Our SQLRack is also still
relatively basic in that it does not cater for SQL features specific
to different RDBMS's but mostly for MySQL.  It does however build
SkinScript and SQL for relations between different classes if you
use a certain naming convention.

I'll put a tarball of our extensions on zope.org by week-end - I still
want to refine it a bit more.

> The way I'm 
> working now, I have filesystem dataskins that work with my levers to do 
> query/skin script generation. I also have a sub-class of Specialist that 
> creates a sort of default, crude, "Object ZMI" so you can dig into the 
> application without writing a full UI.

We've done something similar.  We also realised that there are a lot of 
methods like addInstances, delInstances and ui-snippets like 
selectInstance(s), etc common to a lot of Specialists and made a 
subclass that provides these methods by defaults.

> 
>>
>> The second one I find quite exciting since it solves the difficult time
>> one generally has to make a ZPatterns app customisable by 3rd party
>> developers.  We basically made Specialists and Racks skinnable by
>> subclassing them from the CMF's SkinnableObjectManager.  To that we
>> added FSSkinScript, short for filesystem skinscript.
>>
> 
> This sounds like a great addition! I'm sure that both of these would be 
> welcome additions.
> 
> I was also thinking that perhaps either Phil/Ty might permit some folks 
> to commit to the CVS tree (at least the ZPatterns part) or maybe one of 
> us should make a ZPatterns patch/CVS to keep up with issues that crop 
> up. I've been fairly happily developing with Steve A's Transaction 
> Agents, but with time, little things accumulate. ;-)

We've also been using Steve's Transaction Agents but I would like to see
all things ZPatterns in a CVS repository that more people can work on. 
If Phillip find that this will require to much maintenance I'm more than
willing to set up a CVS repository on our server.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za