Re: [Zope-dev] ZPatterns example update....

2001-01-02 Thread Phillip J. Eby

At 03:08 PM 1/2/01 +1100, Itai Tavor wrote:
Hi Steve,

Steve Spicklemire wrote:

   "Itai" == Itai Tavor [EMAIL PROTECTED] writes:

 Itai Maybe with this
 Itai SkinScript: WITH Doers.getItem(self.doerID) CALCULATE
 Itai self.doerID=RESULT.id or '' ?  But I'm not really sure about
 Itai this...

Ahh.. I think my brain just imploded in a recursive death spiral,
but I get intent of the idea. This would work I think:

WITH Doers.getItem(self.doerID) COMPUTE self.myDoer=RESULT or 
Doers.getItem('doNothing')

where there is a default 'doer' named 'doNothing' in one of the Doers
Racks.  This guy would 'fill in' for the ToDo's doer when no 'real'
doer can be found... I like that. ;-)

Yeah, this looks good... whether it's appropriate or not depends on 
how you expect the case where there's no Doer to behave - if you 
needed to know explicitly that a Doer doesn't exist, returning a 
'nothing' doer could confuse things. BTW, I can't see the recursion 
in my script... but maybe my brain is still in vacation mode :)

Your script uses an attribute (doerID) in the WITH clause that is provided
by the COMPUTE clause.  This is infinitely recursive in theory.  In
practice, it will result in the non-existence of the doerID attribute, as
ZPatterns treats recursive attribute references as non-existence of the
attribute.  The WITH clause will fail with an AttributeError.


___
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 example update....

2001-01-01 Thread Itai Tavor

Steve Spicklemire wrote:

Hi Folks,

The Dumb ZPatterns example is updated. Now there is some more
realistic object referencing going on, borrowing of code snippets
between Specialists and suchlike. There is also more in the way of
reasonable documentation, though everything is in flux, and it still
doesn't resemble a truly completed product. I just feel the need to
get things finished enough that I can stop thinking about them for a
while. ;-) In particular there the ToDos now hold references to Doer
and Deliverable, and no 'lists' are maintained. One thing I need to do
is to have these references automatically 'fixed' when a 'referred to'
entity is removed or modified in such a way that the link should be
broken that's for the next version. If I'm not careful.. it won't
be a 'simple' example anymore. There's got to be a line here somewhere
(in the sand?).

Nice work, Steve.

Removing id lists looks good. I started building objects using 
getXForY(y_id), but the last one I made used an id list following the 
Dumb Example. I've just changed it to use getXForY, and it's much 
cleaner, plus it makes adding X from Y/editInstanceForm easier.

I like the idea of naming all UI methods with '_html' - now, if you 
find yourself referencing a method which doesn't end in '_html' in 
your html code, you know you need to add an interface method. I just 
need to decide if I like it enough to change all my existing code...

Some thoughts about the broken links handling problem: If an object 
depends on the existence of another (for example, if you wanted a 
ToDo to be tightly linked to a Deliverable) then it should be deleted 
when the Deliverable is deleted, right? You'd have WHEN OBJECT 
DELETED CALL ToDos.deleteInstances(myToDoIDs) in the Deliverable 
SkinScript, and you would never have ToDos floating around without a 
Deliverable. As for the Deliverable changing and invalidating the 
link, I think it would be solved if you used immutable ids for all 
objects, and stored the Deliverable title in a separate property. In 
case of weaker links, such as between ToDo and Doer, I guess it 
should be ToDo's responsibility to return None if the Doer referenced 
by doerID doesn't exist - treating it the same way as the case where 
no doer has been assigned. Maybe with this SkinScript: WITH 
Doers.getItem(self.doerID) CALCULATE self.doerID=RESULT.id or '' ? 
But I'm not really sure about this...

I think you've managed very well to stay on the right side of the 
line in the sand... the problem is that complex real world 
applications have a lot of stuff on the other side of the line, and 
the challenge is to pull that stuff over the line. My personal 
problem is figuring out if the stuff I have on the wrong side of the 
line is necessitated by the complexity of the application, or if I'm 
just making things unnecessarily complicated...

Itai
-- 
Itai Tavor"Je sautille, donc je suis."
C3Works[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you haven't got anything"


___
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 example update....

2001-01-01 Thread Steve Spicklemire


Hi Itai,

 "Itai" == Itai Tavor [EMAIL PROTECTED] writes:
Itai Steve Spicklemire wrote:

 Hi Folks,
 
 The Dumb ZPatterns example is updated. Now there is some more
 blah blah blah

Itai Nice work, Steve.

Thanks! 

Itai Removing id lists looks good. I started building objects
Itai using getXForY(y_id), but the last one I made used an id
Itai list following the Dumb Example. I've just changed it to use
Itai getXForY, and it's much cleaner, plus it makes adding X from
Itai Y/editInstanceForm easier.

Yup.. this is working nicely for me. 

Itai I like the idea of naming all UI methods with '_html' - now,
Itai if you find yourself referencing a method which doesn't end
Itai in '_html' in your html code, you know you need to add an
Itai interface method. I just need to decide if I like it enough
Itai to change all my existing code...

Right... I was on the lookout for something natural, and sorta
obvious. I liked the fact that there are already examples of 
'standard' interface methods that have '_html', so I wouldn't
have to change *them*... sometimes laziness can be inspiring. ;-)

Itai Some thoughts about the broken links handling problem: If an
Itai object depends on the existence of another (for example, if
Itai you wanted a ToDo to be tightly linked to a Deliverable)
Itai then it should be deleted when the Deliverable is deleted,
Itai right? You'd have WHEN OBJECT DELETED CALL
Itai ToDos.deleteInstances(myToDoIDs) in the Deliverable
Itai SkinScript, and you would never have ToDos floating around
Itai without a Deliverable. As for the Deliverable changing and
Itai invalidating the link, I think it would be solved if you
Itai used immutable ids for all objects, and stored the
Itai Deliverable title in a separate property. In case of weaker
Itai links, such as between ToDo and Doer, I guess it should be
Itai ToDo's responsibility to return None if the Doer referenced
Itai by doerID doesn't exist - treating it the same way as the
Itai case where no doer has been assigned. 

Yes.. I like this.

Itai Maybe with this
Itai SkinScript: WITH Doers.getItem(self.doerID) CALCULATE
Itai self.doerID=RESULT.id or '' ?  But I'm not really sure about
Itai this...

Ahh.. I think my brain just imploded in a recursive death spiral,
but I get intent of the idea. This would work I think:

WITH Doers.getItem(self.doerID) COMPUTE self.myDoer=RESULT or 
Doers.getItem('doNothing')

where there is a default 'doer' named 'doNothing' in one of the Doers
Racks.  This guy would 'fill in' for the ToDo's doer when no 'real'
doer can be found... I like that. ;-)

Itai I think you've managed very well to stay on the right side
Itai of the line in the sand... the problem is that complex real
Itai world applications have a lot of stuff on the other side of
Itai the line, and the challenge is to pull that stuff over the
Itai line. My personal problem is figuring out if the stuff I
Itai have on the wrong side of the line is necessitated by the
Itai complexity of the application, or if I'm just making things
Itai unnecessarily complicated...

Thanks... don't want to mix metaphors, but I'm fearing that the line
in the sand may be on a slippery slope ;-). Seriously though. It would
be really easy to make this 'dumb' example so complex that a beginner
in ZPatterns couldn't make it through without brain damage but never
fear.. I've already squandered all my free time for the next three
months on this... so it will very likely stay stuck where it is for
some time now... I hope that some ZPatterns beginners find it useful
as a starting place.

take care,
-steve






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