Excellent,<br><br>I took a look at the way it is used in the sample Chandler app.... I tried to implement a MVP structure in an older app, it felt great until my lack of discipline kicked in and ruined a big chunk of code. The implementation that I see in the demo is very nice, very nice... much nicer than my feeble attempt.
<br><br>If the right planets are aligned this weekend.... maybe my dream app will also use Trellis.<br><br>Congratulations!<br>Peter<br><br><div class="gmail_quote">On Dec 1, 2007 1:14 AM, Phillip J. Eby <<a href="mailto:pje@telecommunity.com">
pje@telecommunity.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The new algorithm is now in SVN, as Trellis-0.6a1dev-r2436
, if you'd<br>like to experiment.<br><br>The documentation is practically untouched from the old version, and<br>is thus out-of-date and *materially misleading*. The code examples<br>of course work, but you can't trust the explanatory text. And there
<br>are important APIs that aren't documented at all.<br><br>In practice, however, most existing trellis code should only need two<br>kinds of changes:<br><br>* @action rules should switch to @rule, @observer, or a combination of the two
<br><br>* Tasks can no longer observe discrete or receiver cells, and require<br>an active EventLoop to run<br><br>When converting @action rules, you must separate your code into code<br>that makes trellis changes, and code that does non-trellis things
<br>(like GUI updates, I/O, etc.). The former should become @rule, and<br>the latter should become @observer.<br><br>The only exception is when you have an @action that really intends<br>that its changes should take effect in the *future*, instead of in
<br>the current recalculation. If you intend your changes to take place<br>in the future, you should use a @task or EventLoop.call() to schedule them.<br><br>Also, note that rules can now be run more than once during the same
<br>recalculation pass -- if your rule has side-effects (other than<br>setting cell values, or using trellisized data structures) it *must*<br>use trellis.on_undo(func, *args) to register undo functions to be<br>called in the event of an error or the need to recalculate due to an
<br>out-of-order modification.<br><br>And speaking of undo and trellis data structures, please note that<br>Dict, List, and Set do not actually support undo yet, which means<br>they're not safe for modification via rules at the present
<br>moment. I'll be fixing this soon, I hope, but in the meantime,<br>please be aware of it.<br><br>By the way, if you'd like to see a cool wxPython demo app built on<br>the Trellis, take a look at:<br><br><a href="http://svn.osafoundation.org/chandler/branches/rearchitecture/" target="_blank">
http://svn.osafoundation.org/chandler/branches/rearchitecture/</a><br><br>It's an experimental and in-progress refactoring of the Chandler<br>application UI to run on the Trellis and other PEAK technology such<br>as AddOns, PlugIns, etc.
<br><br>In order to actually run it, you'll need to install this first, though:<br><br><a href="http://svn.osafoundation.org/chandler/trunk/chandler/" target="_blank">http://svn.osafoundation.org/chandler/trunk/chandler/
</a><br><br>as we're using Chandler's custom wx, PyICU, and various other<br>libraries including Twisted.<br><br>(Oh, and yes, it works with the new Trellis algorithm.)<br><br>_______________________________________________
<br>PEAK mailing list<br><a href="mailto:PEAK@eby-sarna.com">PEAK@eby-sarna.com</a><br><a href="http://www.eby-sarna.com/mailman/listinfo/peak" target="_blank">http://www.eby-sarna.com/mailman/listinfo/peak</a><br></blockquote>
</div><br><br clear="all"><br>-- <br>There is NO FATE, we are the creators.