[Zope-dev] zpatterns-0.4 ?

[Phillip J. Eby]

At 08:21 PM 6/6/00 +0400, Jephte CLAIN wrote:
>Hello,
>
>I have used ZPatterns-0.3.0 to complete a project that I shipped
>yesterday.

Congratulations, you're even braver than I am.  ;)


>Although I had to write a CatalogAwareRack/Specialist to allow me to
>search for rackmountables, I can say that ZPatterns has saved my life! I
>would like to thanks Philip for this great contribution. (too bad I no
>longer remember the url of that site where you can send so-called
>"virtual beers" to fellows on the internet :-))

That's okay, I don't drink.  :)


>Now, for a project I have to ship by the end of june, I would like to
>use zpatterns-0.4.0. I especially want to use the new search interface.
>Does Philip know when ZPatterns-0.4.0 is out? If it is until the middle
>of june, I can certainly wait. In the other case, I wonder if the search
>plugin (in the case it has already be written) can be used with
>zpatterns-0.3. In that case, I can do the work of adapting the code to
>zpatterns-0.3

I'm shooting for release by the end of next week.  Search plugins have not
been finished yet, but in any case they will NOT work with prior versions;
there is no place to plug them in, nor will any of the old code call them. :)


>Also, for that project, I will have to write a sql attribute provider.
>If one can give me advices on how Ty wants to implement SQL Attribute
>Provides after he's done with LDAP Attribute Provider, perhaps I can
>start the work (since I have a use for it) and let Ty continue the work
>when he has more time / have finished LDAP Attribute Provider. I already
>have some ideas on how to do it, but I lack to view how far the concept
>have to be pushed. Without any help, I will end up writing a SQL
>Attribute Provider that work only for me...

Ty and I just finished the first "real" attribute provider, an "ExprGetter"
provider, which is designed to work with SQL, LDAP, and other "method"
objects available in Zope.  It takes a "source expression" and a list of
"target expressions".  The source expression is evaluated whenever any of
the attributes provided by the provider are requested.  Then the target
expressions are evaluated in order, each one having the variable RESULT
equal to the result of the source expression.  An example:

Source expression:
  (SomeSQLMethod(searchkey=self.id) or [NOT_FOUND])[0]

Target expressions:
  myAttr1=RESULT.field1
  myAttr2="(%s)" % RESULT.field2
  myAttr3=RESULT.field3 * self.someOtherAttr

The above example will call SomeSQLMethod() (searched for in the Rack or
Customizer's acquisition tree) whenever myAttr1, myAttr2, or myAttr3 are
requested for the DataSkin/RackMountable.  It will be passed the DataSkin's
"id" attribute (note the self.attr notation for referencing data from the
skin in the source expression).  If the SQLMethod returns no rows, the
special NOT_FOUND value will be substituted, which tells the attribute
provider to pretend none of the attributes exist.  If it returns rows, the
first row ([0]) will be returned as RESULT for use in the target
expressions as shown.  The results of all three expressions will be cached
in the DataSkin's attribute cache for the remainder of the current
transaction, thus preventing a recurring call to the database.

"NOT_FOUND" and "self" are also available for use in the target
expressions, so one can conditionally simulate the existence or
non-existence of a given attribute, as well as do "computed attributes".
All expressions are VSEval-based (DocumentTemplate expr's) and "safely"
editable through the web.  Also, "self" is in its acquisition context
(either its folder or its Specialist) and you can freely reference other
provider-driven attributes or propertysheets (from the same or different
providers) in your expressions so long as you don't create an infinite
recursion loop.

This particular expression-based attribute provider is the first of a set
of defined mappings from attributes and events into expression calls.  We
have in fact designed a "little language" (tentatively called SkinScript)
which will let you render statements like the above as:

USE (SomeSQLMethod(searchkey=self.id) or [NOT_FOUND])[0]
TO COMPUTE
  myAttr1=RESULT.field1,
  myAttr2="(%s)" % RESULT.field2,
  myAttr3=RESULT.field3 * 10

And other things like:

NOTIFY some_expression AFTER ADDING, CHANGING, DELETING

USE expr TO SET attr1,attr2,attr3 

etc.

But it's not clear whether an actual SkinScript compiler will make it into
0.4.0.  The plan is to first make a provider class for each of the
SkinScript constructs, to debug them.  We can then replace them later with
a single "SkinScript provider".

We came up with SkinScript because we realized that configuring a gazillion
individual Attribute and SheetProviders was terribly tedious and messy, not
to mention that it was hard to see what was going on with your object in
one place.  Also, it eliminates the need for having specific kinds of
Providers for different databases.  (Note: we are not eliminating the
provider mechanism; we just plan to add a SkinScript attribute/sheet
provider to the things you can plug in to DataManagers.)

Anyway...  so yes, 0.4.0 *is* suffering a bit from feature creep, why do
you ask?  :)  Hooks will be there for indexing and other triggers, but here
is a list of some things that will definitely NOT be in 0.4.0:

* Index/trigger agents will not be guaranteed to work correctly without the
absolute latest Zope 2.2 stuff, due to transaction processing issues.  The
hooks will be there to play with, however.

* There is not yet any interface defined for Racks, Specialists, and other
DataManagers to actually ask indexes to *search* for anything, so if by
some miracle you get a trigger set up to properly catalog things, you'll
have to manually put methods in your Specialist to search the catalog for you.

* Attribute setters will be on the ugly side, especially for SQL, as you
will have to have SQL methods that can update one field at a time.  (This
is less of an issue for LDAP because the ZLDAP stuff already has provisions
to batch updates to the LDAP server.)  By 0.5.0, we hope to have an
extended form of SQLMethods (or some other way to do this) that will cache
the updated fields until a subtransaction (or full transaction) commit
takes place, then throw them to the server all at once.