Re: [Zope-dev] ZPatterns question

2001-01-05 Thread Chris Withers

Christian Scholz wrote:
 
  yeah, this is exactly what I'm after too. I'd like the virtual objects
  the specialist is responsible for to have normal Zope management
  screens.
 
 Well, I think this shouldn't be too difficult to create. Just a subclass
 of Specialist and add some Contents-Tab, define objectIds() etc. in the
 Methods tab and call it in the management screen of "Contents".
 Though the more advanced things like Copy/Paste/Rename might then not
 be available.. But for me actually it would be sufficient to get the
 contents.

:-S

I was hoping for something along the lines of subclass from Specialist
and Folder, and override objectIds (+ whatver else?) in my new class to
do 'the right thing'

I wonder how that would pan out?

  Also, much mroe trickily, I'd like them to be able to contain each
  other, although Steve A's __bobo_traverse__ trick might help with this
  bit...
 
 What do you mean? Nesting Specialists (or these virtual folder specialists)?

The DataSkins stored in the specialist ;-)

cheers,

Chris

___
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 )




Re: [Zope-dev] ZPatterns question

2001-01-04 Thread Chris Withers



Christian Scholz wrote:
 
 Well, virtual in the sense as a specialist is no real folder but can
 provide content from different sources. Thus what I mean is some mechanism
 which emulates objectIds() etc. so it looks to the user (and the ones
 using it via dtml) like a normal folder object.
 Somehow like the Customizer but without the need for actually creating
 Zope objects. Something inbetween Specialist and Customizer this would be
 I guess.

yeah, this is exactly what I'm after too. I'd like the virtual objects
the specialist is responsible for to have normal Zope management
screens.

Also, much mroe trickily, I'd like them to be able to contain each
other, although Steve A's __bobo_traverse__ trick might help with this
bit...


cheers,

Chris

___
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 )




Re: [Zope-dev] ZPatterns question

2001-01-04 Thread Christian Scholz

Hi!

  Well, virtual in the sense as a specialist is no real folder but can
  provide content from different sources. Thus what I mean is some mechanism
  which emulates objectIds() etc. so it looks to the user (and the ones
  using it via dtml) like a normal folder object.
  Somehow like the Customizer but without the need for actually creating
  Zope objects. Something inbetween Specialist and Customizer this would be
  I guess.
 
 yeah, this is exactly what I'm after too. I'd like the virtual objects
 the specialist is responsible for to have normal Zope management
 screens.

Well, I think this shouldn't be too difficult to create. Just a subclass
of Specialist and add some Contents-Tab, define objectIds() etc. in the
Methods tab and call it in the management screen of "Contents".
Though the more advanced things like Copy/Paste/Rename might then not
be available.. But for me actually it would be sufficient to get the
contents. 

 Also, much mroe trickily, I'd like them to be able to contain each
 other, although Steve A's __bobo_traverse__ trick might help with this
 bit...

What do you mean? Nesting Specialists (or these virtual folder specialists)?

cheers,
  Christian

-- 
COM.lounge  http://comlounge.net/
communication  design   [EMAIL PROTECTED]

___
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 )




Re: [Zope-dev] ZPatterns question

2001-01-03 Thread Christian Scholz

Hi!

Actually should answer to these posts... ;-)

On Thu, Dec 28, 2000 at 03:11:37PM -0500, Steve Spicklemire wrote:
 
 Hi Christian,
 
 Well, nobody else answered that I saw... so I'll take a crack
 at your questions 
 
  "CS" == Christian Scholz [EMAIL PROTECTED] writes:
 
 CS Hi there!
 
 CS Finally I managed to get a basic understanding of how to do
 CS things with ZPatterns ;-) So seems quite cool :) (and
 CS hopefully I find some time to write some basic howto about it)
 
 CS But I have some little questions:
 
 CS 1. Is it possible to retrieve the set of known IDs from a
 CS specialist?  Or would I need to add my own method to it which
 CS does this (and change it accordingly if I switch to another
 CS storage method)?
 
 If you store persistently you can use the Rack's method:
 
 "defaultRack.getPersistentItemIDs()"

Thanks, also found this out in the meanwhile.

 but a couple of notes: 1) this returns a BTree object, not a simple
 list, so you can't iterate through it in DTML. You'll need to copy
 it to a simple list for that.. and 2) If you change to a different
 storage you'll need to create your own method (ZSQL Method?). What I've
 found is that if you have a large number of objects you'll either want
 to query a Catalog, or an SQL database to get Ids that match some criteria
 that limit the number of hits to something that makes sense to display 
 in a browser.

I am now using some method I create inside the specialist for it.

 CS 2. Is it planned to provide something like a virtual folder
 CS which acts like a normal object manager but is controlled via
 CS ZPatterns (so actually something like Folder with Customizer
 CS Support just without the "anchor" in ZODB.  (would also
 CS require some mechanism asked for in 1.)
 
 Hmmm... I'm not sure what you're after here. Why not just use
 a Specialist? In what sense do you want it to be virtual?

Well, virtual in the sense as a specialist is no real folder but can
provide content from different sources. Thus what I mean is some mechanism
which emulates objectIds() etc. so it looks to the user (and the ones
using it via dtml) like a normal folder object.
Somehow like the Customizer but without the need for actually creating 
Zope objects. Something inbetween Specialist and Customizer this would be
I guess.

 (Are you looking for a dynamic traversal interface that 
 would allow you to map URLs to objects that are managed by
 ZPatterns? Can you give an example?)

yes, something like this comes close I guess.

e.g. I have some sql database consisting of people's addresses and
I want to create some specialist which queries this database (or how
ever this specialist is configured right now in order to get the
object ids) and shows it as if it's a normal folder.
(seems to me more transparent at some point).

But I assume it's not suited for all applications e.g. if the number
of objects gets a little bigger.

And I guess I can create this myself if I subclass from Specialist and
add the rest of the ObjectManager's interface to it.

 CS 3. Is it possible to use ZPatterns also without some exta
 CS ZClass defined in a Product? At least if I don't need methods
 CS for my objects but simple want to define the attribute they
 CS know.  Would be nice as I could then hold everything together
 CS in one place (the specialist that is) without requiring to
 CS install something also in the Products folder of the Control
 CS Panel.
 
 I believe you need to either create a Python subclass, or a ZClass
 subclass of DataSkin. "Raw" DataSkins don't have the right permissions
 to allow for TTW access. If you're creating a 'product' anyway... just
 make a 'dummy' class that you can use for storage.

ok, but I still need to define the attributes I want to handle inside a
propertysheet of this ZClass, right?
Actually what I would like is something which directly resides inside the
Specialist and not somewhere outside in some Product folder.
So everything is close together in one place.

 CS That's it for now, I will keep experimenting then.. :)
 
 Good Luck!

Oh, it's working better than I thought :)

but thanks,
  christian

___
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 )




Re: [Zope-dev] ZPatterns question

2001-01-03 Thread Christian Scholz

Hi Steve!

On Thu, Dec 28, 2000 at 10:45:46PM +, Steve Alexander wrote:
 Steve Spicklemire wrote:
 
  
  CS 2. Is it planned to provide something like a virtual folder
  CS which acts like a normal object manager but is controlled via
  CS ZPatterns (so actually something like Folder with Customizer
  CS Support just without the "anchor" in ZODB.  (would also
  CS require some mechanism asked for in 1.)
  
  Hmmm... I'm not sure what you're after here. Why not just use
  a Specialist? In what sense do you want it to be virtual?
  (Are you looking for a dynamic traversal interface that 
  would allow you to map URLs to objects that are managed by
  ZPatterns? Can you give an example?)
 
 Reading this just after reading the source to Specialists.py, I had a 
 thought; and tried it out; and it works! :-)
 
 You can use SkinScript to define __bobo_traverse__ for a particular kind 
 of DataSkin in a Specialist.
 
 For example:
 
WITH SELF COMPUTE __bobo_traverse__=traversal_method

that's very cool :)
I just created some base class for this from which my ZClasses are derived
but nice to know that it's also possible without this base class.
(though for this application it's easier with this base class as
it's easier to configure then)

cheers,
  Christian


___
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 )




Re: [Zope-dev] ZPatterns question

2000-12-28 Thread Steve Spicklemire


Hi Christian,

Well, nobody else answered that I saw... so I'll take a crack
at your questions 

 "CS" == Christian Scholz [EMAIL PROTECTED] writes:

CS Hi there!

CS Finally I managed to get a basic understanding of how to do
CS things with ZPatterns ;-) So seems quite cool :) (and
CS hopefully I find some time to write some basic howto about it)

CS But I have some little questions:

CS 1. Is it possible to retrieve the set of known IDs from a
CS specialist?  Or would I need to add my own method to it which
CS does this (and change it accordingly if I switch to another
CS storage method)?

If you store persistently you can use the Rack's method:

"defaultRack.getPersistentItemIDs()"

but a couple of notes: 1) this returns a BTree object, not a simple
list, so you can't iterate through it in DTML. You'll need to copy
it to a simple list for that.. and 2) If you change to a different
storage you'll need to create your own method (ZSQL Method?). What I've
found is that if you have a large number of objects you'll either want
to query a Catalog, or an SQL database to get Ids that match some criteria
that limit the number of hits to something that makes sense to display 
in a browser.

CS 2. Is it planned to provide something like a virtual folder
CS which acts like a normal object manager but is controlled via
CS ZPatterns (so actually something like Folder with Customizer
CS Support just without the "anchor" in ZODB.  (would also
CS require some mechanism asked for in 1.)

Hmmm... I'm not sure what you're after here. Why not just use
a Specialist? In what sense do you want it to be virtual?
(Are you looking for a dynamic traversal interface that 
would allow you to map URLs to objects that are managed by
ZPatterns? Can you give an example?)

CS 3. Is it possible to use ZPatterns also without some exta
CS ZClass defined in a Product? At least if I don't need methods
CS for my objects but simple want to define the attribute they
CS know.  Would be nice as I could then hold everything together
CS in one place (the specialist that is) without requiring to
CS install something also in the Products folder of the Control
CS Panel.

I believe you need to either create a Python subclass, or a ZClass
subclass of DataSkin. "Raw" DataSkins don't have the right permissions
to allow for TTW access. If you're creating a 'product' anyway... just
make a 'dummy' class that you can use for storage.

CS That's it for now, I will keep experimenting then.. :)

Good Luck!
-steve

CS cheers, Christian

CS -- Christian Scholz MrTopf@IRC COM.lounge
CS http://comlounge.net/ communication  design [EMAIL PROTECTED]

CS ___ Zope-Dev
CS maillist - [EMAIL PROTECTED]
CS http://lists.zope.org/mailman/listinfo/zope-dev ** No cross
CS posts or HTML encoding!  ** (Related lists -
CS http://lists.zope.org/mailman/listinfo/zope-announce
CS 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 )




Re: [Zope-dev] ZPatterns question

2000-12-28 Thread Steve Alexander

Steve Spicklemire wrote:

 
 CS 2. Is it planned to provide something like a virtual folder
 CS which acts like a normal object manager but is controlled via
 CS ZPatterns (so actually something like Folder with Customizer
 CS Support just without the "anchor" in ZODB.  (would also
 CS require some mechanism asked for in 1.)
 
 Hmmm... I'm not sure what you're after here. Why not just use
 a Specialist? In what sense do you want it to be virtual?
 (Are you looking for a dynamic traversal interface that 
 would allow you to map URLs to objects that are managed by
 ZPatterns? Can you give an example?)

Reading this just after reading the source to Specialists.py, I had a 
thought; and tried it out; and it works! :-)

You can use SkinScript to define __bobo_traverse__ for a particular kind 
of DataSkin in a Specialist.

For example:

   WITH SELF COMPUTE __bobo_traverse__=traversal_method

Then, define a method in the specialist (or rack) called 
traversal_method. I used a PythonScript, and gave it the parameter list 
"REQUEST, name".
Make your method return the appropriate object to traverse to from your 
DataSkin, depending on the name passed. Something like

   return getattr(container.path.to.somewhere, name)

That's the simple version, and it won't give the traversed-to object the 
correct context most of the time. To do that, I'd need to use an 
external method, and use the __of__ method to give the returned object 
an appropriate context.

However, it is a start, and proves that it can be done.

Take a look in the __bobo_traverse__ method of Specialists.py (from 
ZPatterns) for a good algorithm for traversal. The variable _marker is 
almost always a class attribute initialized to [], to make a unique 
object, as a sentinel.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net





___
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 )




Re: [Zope-dev] ZPatterns question

2000-12-28 Thread Steve Alexander

Steve Alexander wrote:


   return getattr(container.path.to.somewhere, name)
 
 That's the simple version, and it won't give the traversed-to object the 
 correct context most of the time. To do that, I'd need to use an 
 external method, and use the __of__ method to give the returned object 
 an appropriate context.

However, if all you are doing is saying "does this object have the named 
attribute? if not, get it from another specialist", and you're using 
Specialist.getItem() to do the latter part, then the object you want 
comes ready-wrapped in the appropriate context, courtesy of the Rack 
that gives it to you!

-- 

Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net



___
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 )




Re: [Zope-dev] ZPatterns Question

2000-08-10 Thread Phillip J. Eby

At 11:58 PM 8/9/00 +0100, Steve Alexander wrote:

1: ZClass instances can have PropertySheets added to them, independently
of any sheets declared in the ZClass class definition.

I've been working with Zope for a while, but this had never occurred to
me. I guess this is just another one of those hangovers from writing in
Java for so long.

It's not a very well-known feature of Zope.  AFAIK, it was implemented to
support WebDAV, which requires the capability to add arbitrary propertysets
to an object, which must NOT interfere with one another or the object's
base properties.


2: If, in a dataskin-derived ZClass class definition, I define a "common
instance" propertysheet, values in that propertysheet for instances get
stored in the ZODB just like any other ZClass instances' propertysheets.

Not exactly.  What happens is that __getattr__ never gets called for those
attributes, so you can't have a provider give a value for them.
__setattr__ and __delattr__ *do* get called, so if you modify those values
on an instance, the providers will get called.  However, since they never
get called for attribute retrieval, you will never see the effects of the
change.  In short, "common instance" property sheets are *broken* with
respect to DataSkins and should be avoided in favor of DataSkin
propertysheets which are built so as not to have this problem.


However, if I define a "dataskin" propertysheet for my ZClass, I can
provide the content of these sheets to my ZClass instances using
AttributeProviders.

Yes.


However, because of the way Attributes work, I cannot supply data for a
dataskin-propertysheet as a separate independent sheet object. The sheet
comes from the ZClass, the data comes from an Attribute Provider.

Yep.  To supply an independent sheet object, you need a sheet provider.
And ZPatterns "out of the box" only includes a Persistent Sheet Provider,
primarily to support WebDAV's requirement for adding arbitrary property sets.


3: If I want to use a SheetProvider, and thus use some of the important
features of ZPatterns, I need to use
object.propertysheets.manage_addPropertySheet() on each ZClass instance
that should have a sheet from a SheetProvider. One way of doing this is
with a Trigger.

Yes.  Another way is that if you write your own SheetProvider, you can
define its _objectAdding() and _objectDeleting() methods to automatically
create the sheet.  Or, if existence of the sheet is predicated upon
something else, you can simply answer the getSheet/getSheets() method calls
by checking to see if that sheet exists, and if so, returning it.  This is
useful when, for example, you need to provide an object with a
propertysheet that presents and/or updates data from a legacy database or
other external system.



4:
 If you needed to add this atop a class which needed to
 be "final" (in the Java sense, i.e. no modifications allowed), then the
 best route would be a custom SQL sheet provider.

..because the SQL sheet provider can provide sheets to ZClass-dataskin
instances, even though the original ZClass was not defined to have this
propertysheet. But I'd also have to add sheets to each applicablt
instance, as in learning point 3 above.

Right, unless you write your sheet provider to just provide the sheet
anyway.  Sheet providers get asked what sheets are available for an object,
and can simply provide some whether they've been "added" or not.  The
"manage_addPropertySheet" step is optional if you're creating custom sheet
providers which can either add the sheet automatically, or have the sheet
just always exist.


___
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 )




Re: [Zope-dev] ZPatterns Question

2000-08-09 Thread Steve Alexander

Thanks for your answers, Phillip.

Here's what I've learned. I still need to try these out on a test
system, to prove to myself that they work the way I think they do.

1: ZClass instances can have PropertySheets added to them, independently
of any sheets declared in the ZClass class definition.

I've been working with Zope for a while, but this had never occurred to
me. I guess this is just another one of those hangovers from writing in
Java for so long.


2: If, in a dataskin-derived ZClass class definition, I define a "common
instance" propertysheet, values in that propertysheet for instances get
stored in the ZODB just like any other ZClass instances' propertysheets.

However, if I define a "dataskin" propertysheet for my ZClass, I can
provide the content of these sheets to my ZClass instances using
AttributeProviders.

(Are the above two paragraphs correct? Or can I use AttributeProviders
to supply data for common instance propertysheets also, but I can't use
default values for such sheets?)

However, because of the way Attributes work, I cannot supply data for a
dataskin-propertysheet as a separate independent sheet object. The sheet
comes from the ZClass, the data comes from an Attribute Provider.


3: If I want to use a SheetProvider, and thus use some of the important
features of ZPatterns, I need to use
object.propertysheets.manage_addPropertySheet() on each ZClass instance
that should have a sheet from a SheetProvider. One way of doing this is
with a Trigger.


4:
 If you needed to add this atop a class which needed to
 be "final" (in the Java sense, i.e. no modifications allowed), then the
 best route would be a custom SQL sheet provider.

...because the SQL sheet provider can provide sheets to ZClass-dataskin
instances, even though the original ZClass was not defined to have this
propertysheet. But I'd also have to add sheets to each applicablt
instance, as in learning point 3 above.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net

___
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 )




Re: [Zope-dev] ZPatterns Question

2000-08-08 Thread Phillip J. Eby

At 06:07 PM 8/8/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
 
 Actually, neither relates.  Property sheets created on ZClasses always have
 their data stored in attributes of the object itself, so if you want to
 control those property sheets you would not use a sheet provider at all.

 Sheet providers are only used to provide property sheets whose data is
 stored external to the object.

I'm confused here. Please excuse me if these questions seem silly.


What does "Property sheets created on ZClasses" mean, exactly?

I mean, if you go into the management screens for a ZClass, and add a
property sheet to the *class*, the sheet's definition is stored in the
class, and its contents are stored as attributes on the instances.  Sheet
providers have no effect on such property sheets, as they are defined in
the class.  However, if you use a "DataSkin Property Sheet", the attributes
of the sheet are stored in the instance in a way that is compatible with
attribute providers.  Thus, you can use attribute providers to provide the
content of the sheet.  But you cannot provide the sheet object itself.
This may seem a subtle distinction, but it is an important one for some
applications.  Sheet providers are primarily intended to add sheets outside
the scope of the class of object being used.


If I use some DataSkin-derived ZClass instances inside a Customizer
folder, and if I want to store the data in the ZODB, do the
propertysheets for one of these ZClass instances come from
PersistentAttributeProviders or PersistentSheetProviders?

If you create the sheets *in* the ZClass itself, then the *data* for the
sheets comes from an AttributeProvider (actually, it's just stored in the
instance, but the storage is controlled by an AttributeProvider).  The
sheet *itself* would come from the class.

If you create the sheet with
object.propertysheets.manage_addPropertySheet(), then the sheet will be
created and managed by a SheetProvider.


What is the difference between a Common Instance Propertysheet and a
Dataskin Attribute Propertysheet when added to a Dataskin-derived
ZClass?

The difference is that a Common Instance property sheet stores default
values in the class under the original attribute name, which makes
__getattr__ unusable on the instances.  A DataSkin property sheet stores
default values in the class under the name "class_default_for_X" where "X"
is the attribute name.  This lets the DataSkin instances give an
AttributeProvider a chance to supply the value of an attribute before
falling back to a class-level default.


Is the following true, part true, false, or irrelevant?

If I want to add a propertysheet that contains information from an SQL
database query to a ZClass-dataskin instance, I have to :

* Declare in my Product that the ZClass has that propertysheet (unless I
do clever stuff with triggers to add the sheet if it isn't there
already)

* Use a custom SQL SheetProvider? Or an AttributeProvider? Or some
skinscript that calls various methods in my specialist?

You can do any of the above.  Currently, the easiest way to do it would
probably be to add the sheet to the class, and then use attribute providers
to supply the data.  If you needed to add this atop a class which needed to
be "final" (in the Java sense, i.e. no modifications allowed), then the
best route would be a custom SQL sheet provider.


___
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 )