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

[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    itai@c3works.com              - Kermit the Frog

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