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

[Steve Spicklemire]

Hi Itai,

>>>>> "Itai" == Itai Tavor <itai@optusnet.com.au> 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