At 12:50 PM 10/7/00 -0700, Michael Bernstein wrote:
"Phillip J. Eby" wrote:
Presentation logic lives with an object's class, and deals with what that
object knows about presenting itself. UI implementation is "glue"
presentation that lives in a Specialist for use by any object that needs to
"Phillip J. Eby" wrote:
How (and why) do you distinguish between UI implementation
and presentation logic?
Presentation logic lives with an object's class, and deals with what that
object knows about presenting itself. UI implementation is "glue"
presentation that lives in a Specialist
Steve Spicklemire wrote:
- How does this product (simple though it is) exemplify the
RIPP approach?
pje I'm not sure that you can say it *exemplifies* the RIPP
pje approach, although it certainly goes along with that
pje approach. My hesitation is mainly that it
I should point out a couple of things that might not be
obvious (that I noticed only on a second 'read' of the explaination):
1) getPersistentItemIds() can be a pain.
dtml-in "defaultRack.getPersistentItemIDs()" sort
is straightforward enough... but what if I don't care if they are
sorted, or
Ack.. sorry... I was making little changes last night to make sure the
ZClass was completely consistent with my explaination, and to make
sure I could start 'from scratch'. I created a 'new' ZClass, and a
'new' rack. This confused the 'old' Rack. (I didn't update the
ToDoManager.zexp, so if you
Steve Spicklemire wrote:
Ack.. sorry... I was making little changes last night to make sure
the ZClass was completely consistent with my explaination, and to
make sure I could start 'from scratch'.
Ok, I just got through stepping through the walkthrough. Thanks! That
*was* a really simple
At 07:59 AM 10/5/00 -0700, Michael Bernstein wrote:
"Phillip J. Eby" wrote:
Domain logic: methods which implement the basic behavior of an object, by
manipulating its attributes and by calling methods on itself or other
objects. (Including delegation to a Specialist, its own or another.)
At 03:44 PM 10/6/00 -0500, Michael Bernstein wrote:
Steve Spicklemire wrote:
Ack.. sorry... I was making little changes last night to make sure
the ZClass was completely consistent with my explaination, and to
make sure I could start 'from scratch'.
Ok, I just got through stepping through
"pje" == Phillip J Eby [EMAIL PROTECTED] writes:
- Propertysheets: You don't expressly say that Shared needs to
be a 'Common Instance Property Sheet'.
pje Actually, if it's intended to be shared across all instances,
pje there seems to me to be little reason to have it in
At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
While I wouldn't say that there has been an actual 'paradigm
shift' between the original RIPP presentation and ZPatterns,
What's happened is that there's been a lot of "implementation shift". The
goals of RIPP have never changed, but they are
"Phillip J. Eby" wrote:
At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
While I wouldn't say that there has been an actual 'paradigm
shift' between the original RIPP presentation and ZPatterns,
What's happened is that there's been a lot of "implementation shift". The
goals of RIPP
OK.. here's the dumbest example I could cook up. It was
my first experiment with ZPatterns in July of last summer.
It was based on a really early release, I don't remember which,
but it seems to work with the latest.. (I just barely
testted it... ) Load the Product ToDoProducts.zexp
into the
Ack.. of course I forgot to test creating new instances there
was a snippet of code for editing and creating that didn't work with
the new propertysheet stuff. I fixed it just now... so it really
works. ;-)
-steve
"Steve" == Steve Spicklemire [EMAIL PROTECTED] writes:
Steve OK..
Steve Spicklemire wrote:
Ack.. of course I forgot to test creating new instances there
was a snippet of code for editing and creating that didn't work with
the new propertysheet stuff. I fixed it just now... so it really
works. ;-)
I didn't get a chance to play with this today, but
Again.. this is an embarrassingly trivial example.. but here it goes:
First of all there is a ZClass 'ToDoClass'.
It needs to have a base class of ZPatterns:DataSkin.
You don't need constructor methods, but I don't think they hurt anything
if you leave them in.
The ToDo needs methods:
Steve Spicklemire wrote:
Again.. this is an embarrassingly trivial example.. but here it goes:
[snip details]
That's it. I can't imagine anything simpler. ;-) Really!
Thanks, I'll be trying this out at work tomorrow.
Michael Bernstein.
___
First, some context... I'm working on a new data storage system for a
related set of (primarily) Zope sites. The data will be kept in ZODB and
mirrored out to a RDB (MySQL) to provide read-only access to some non-zope
stuff. One other thing to note, all of this will be done via python code
(no
Phillip J. Eby wrote:
If I can offer a suggestion...
Please...
It sounds to me like you don't need SheetProviders at all, if you
effectively define the property sheets as part of your class, and make
the attributes direct attributes on the DataSkin. You then need only set
Ok, I'm
18 matches
Mail list logo
