History for SummarizedVersion

??changed:
-
**Inherit !ZPattern classes when creating !ZClass**

  roche:
  well maybe i can now ask my first question to the real pje, why can't one inherit from !ZPattern classes when you create a !ZClass? Is that still a remnant of a zope bug?

  pje: Which !ZPattern classes are you talking about?

  roche: well !PlugIn for a start or !PlugInContainer

  pje: Some aren't registered as !ZClass bases because they wouldn't do you much good at present. !PlugIn is actually a base as of 0.4.0a5, but doesn't work yet.

*!PlugIn Registry*

  pje: The plugin registry is seperate from the regular Zope class registry, so plugins have to be registered from Python

*Storing data in different databases*

  !JeffH: I know one of the goals of ZPatterns (well, Racks, specifically) was to allow data to be stored in RDBMS or ODBMS, as appropriate for each application. Is ZPatterns "there", now, or is there more work to be done before that goal is a reality?

  tsarna: I think it's a reality now. People are doing SQL with Generic Attribute Providers and Generic Triggers now, and I've been doing LDAP with it the last few weeks. LDAP is a bit more of a pain because the ZLDAP products don't work quite the way they need to. They don't have the power and flexibility of SQL Methods

*PlugIns and PlugInContainers*

  roche: Should a !PlugIn always live within a !PluginContainer

  pje: it doesn't have to. You can have a !PlugIn that behaves as a !PlugIn when in a container, but as an ordinary zope object when someplace else.

*Book*
  pje: The key to ZPatterns is O-O design patterns. Specifically, the work of Peter Coad in the "Object Models" book, and the Business object books by Eeles and Sims.

  pje: The what, Chris?
  !ChrisW: containment vs context

*PlugIns in the core system*

  pje: Yeah, especially if I ever get !ZClass sheets for PlugInGroups and all that, PlugIns would be a really cool thing to have in the core system.

  tsarna: (by "more obviously useful", I mean that they're more likely to be recognized as useful... more people understand the problem they're trying to solve)

*Sheet Providers*

  pje: No time estimate, but implementing a sheet provider is pretty straightforward if you want to do one by hand... In that all you need to do is call on another Specialist to give you an object you can return as a sheet.

  But as soon as I get to work on SkinScript, there'll be an easier way.
You'll be able to specify sheet attributes as well as object attributes.

*Making ZPatterns approachable to the great unwashed masses*

  pje: 

   * The first audience is my own development team... 

   * The second audience is developers in my company...

   * The third audience is Zope *framework builders*

   * And the fourth is Zope developers in general

*What are predicates*

  Predicates: objects that represent a logical condition to be used as a filter against some set of objects.

  Example: 

    Attribute('x',LessThan(3))

  tsarna: predicates and the area of 
  searching is kind of on the back burner for now. 
  we have ideas about what we could implement, but 
  we don't yet know enough about what would actually be useful.

  Example: 

    Attribute('x',LessThan(3)) & (Attribute('y',GreaterThan(7)) 
    | Attribute('z',Equal(9)))

  stevea: how about: anything you'd put in a "where" caluse in an SQL statement?

  pje: Possibly more restrictive than that, Steve.

  roche: They almost seem like gatemasters?

  pje: SQL allows comparison of attributes, but in the simplified 
  predicate models we have done thus far we've focused on 
  constant AVA's (attribute value assertions)

  !JeffH: predicate: something that is affirmed or 
  denied of the subject in a proposition in logic "m-w.com"

  stevea: Will the predicate language be pluggable? 
  If I wanted to do one based on Z Schemas, would I be 
  able to plug it in without rooting around in the code?

  pje: That question's a bit premature.

 *Parrallel matching research*

  pje: We've been doing some research into what we 
  call _parallel matching_ - a connectionist technique for 
  doing _reverse_ searching... The idea is that when somebody 
  posts an item to a portal, the system can quickly apply hundreds of users' stored search criteria against the new item and then carry out notifications, etc.

  pje: We only have a theoretical model, not an implementation design.

  !ChrisW: Surely the loading on that might not be sensible? What if you have lots of dormant users? You carry out their searches even though they'll never use the results :(

  pje: Actually, Chris, the algorithm we've come up with is actually linear relative to the number of attributes which the object to be matched has.

  tsarna: Another reason they're on the back burner is that people 
  find the current set of ideas and terms confusing enough, so 
  introducing more now seems bad :)

  pje: The only dependency on the other end 
  is how many rules end up firing (i.e., how many e-mails 
  to send or whatever)

  pje: And those can be queued, to be sent out for example 
  by our metadaemon system.

*Using fromexpr and attrsxprs fields of !GenericAttributeProvider*

  stevea: Can you explain a bit about ways of using the fromexpr 
  and attrsexprs fields of a !GenericAttributeProvider?

  pje: The idea of having two sets of expressions is based on the idea that
  attributes often come in sets. For example, an SQL result row or an LDAP entry. So you will often want to retrieve that whole row or entry, whenever any one of its fields is asked for.

  pje: The fromexpr is the expression which is called to retrieve 
  that record, whenever any of the attrsexprs is asked for. And then the
  result of *all* the attrsexprs are loaded into the DataSkin's attribute cache. Unless the result of the fromexpr is NOT_FOUND. In which case, the asked-for attribute is cached as NOT_FOUND, but asking for any of the other attributes will cause the fromexpr to be called again.

  pje: (That latter behavior may be a bug or a feature. :) )

  tsarna: And asking for any of the attrs maskes them all available. 
  The idea is that the fromattr is probably expensive to computer 
  (means hitting SQL, LDAP, etc), while the attrsexprs are cheap to 
  compute (putt an individual item from the results)

  tsarna: so if you have to do the expensive part anyway, might as well
  make all the attributes availaible since there's a good chance you'll 
  need them later anyway, and you'll save re-running the expensive part

  stevea: Thanks. It's sometimes difficult to reverse-engineer 
  the rationale from the code :-)

  tsarna: It's a bit clearer in the skinscript version. I'm not sure
  exactly what syntax we settled on, but it's something like: 

    FROM expression COMPUTE attr1=..., attr2=...

   pje: Two bits at best. :) 

   tsarna: (hence the name "fromexpr")

*what is skinscript?*

   pje: SkinScript is a declarative scripting language which will 
   let you define attributes, triggers, and propertysheets 
   for a !DataSkin. It will be a "Data Plug-in".

   pje: You basically add a SkinScript object to your Rack, 
   Specialist, Customizer, or whatever, then fill in what you 
   want it to do.

   !ChrisW: P&T, do you ever worry that with the sprawling complexity 
   of ZPatterns, people might just not get it and ignore 
   it/ get frustrated by it?

   pje: No.

   !JeffH: I am frustrated. But, I *need* ZPatterns. I can't 
   afford to give up.

   tsarna: Instead of adding a bunch of GAP's, GT's etc, 
   you can add one thing with a nice big textarea, and have several
   statements in it. Each statement is equivalent to a single GAP, GT, 
   etc.

   pje: As with all Open Source projects, this is first 
   and foremost a "scratch your own itch" effort.

*Generic Triggers, the fields Execute, Keeping and Set Attrs*

 *Generic Triggers*

   tsarna: Basically, GT's and GAP's were designed to test out the
   implementation of those before we have a skinscript parser done. 
   You can think of SkinScript as removing complexity  
   instead of adding it, really :). The idea with the 
   generic trigger is that you want to do something when a condition
   occurs...

   But, in order to know if the condition has occurred, 
   you may need a previous value of some attribute or expression. 
   So, the "keeping" field is a list of names or expressions 
   to snapshot *before* a change takes place.

   Each line is either a "name" (which is interpreted the way 
   names are interpreted in DTML). Or an "expression" (name=expr),
[304 more lines...]