needs to mention readline/history in n2 (and n2's help looks maybe broken in a couple of areas, which I should bug Ty about) (RDM: done, but I may not have mentioned everything you wanted mentioned)
more about n2's functions/abilities (RDM: I added some more stuff, but not much)
Ty is n2 author (RDM: note added to text)
Use n2 \python mode to illustrate SQL calls from Python, so it's not new in the DM usage (RDM: done)
URL is "scheme:body", body is not a "path" (RDM: fixed)
URL schemes are effectively "private" (E.g.: "What kind of a URL is sqlite:foo? It doesn't work in my browser", etc.) (RDM: done)
Use example.com instead of server.com (RDM: done)
Connection isn't a config key/component key - the name is (RDM: reworded, but may still not be clear enough)
Use hello.db instead of test.db (RDM: I purposely used test.db rather than hello.db because it is supposed to be a test database, representing the "real" corporate database. But if you want to change it, I've no huge objection.)
More LinkRef explanation: when you can or can't use it
Put global.ini in PEAK_CONFIG, explain loading order again
First cut SQL usage is BROKEN; forCmd will load/save customer rather than group
i.e., won't work unless the for user is in both the SQL db and the text one (RDM: actually, it does work, as I now explain in the text, but the fact that it works is an accident.)
text should be called message, since aGroup.text doesn't make sense (RDM: fixed. Used 'greetingtemplate')
referenceType is a typo (RDM: fixed)
DM's and commands need to use get() instead of __contains__ (RDM: fixed)
Lesson 2
Recap is missing info about storage.DMFor
All the examples use print, but should use print >>self.stdout,
Should we fix this in the early lessons, so folks aren't misled about good practice? (RDM: I've already fixed this in lessons 1 through 4)
Should we encapsulate the actual greeting code?
Need an IGreetingService or some such, so we can demo the [Component Factories] configuration
This would then be usable by UI's like web, XMLRPC, etc.
Might be a good way to encapsulate certain aspects, including both greetings and edits
Create a "hello world" socket service, that you connect to and are greeted by (then disconnected); this would let us demo several things, including:
EventDriven
ZConfig schemas
PEAK+Twisted
accessing the IGreetingService to get the greeter
Need for commands to write where they're told (self.stdout)
Maybe adaptation from IGreetingService to a Twisted protocol or factory?
Kind of hard to show in context of EventDriven, though.
Minimal CGI using print >>self.stdout w/generic greeting
Add PATH_INFO parsing to greet a specific person
Use CGI and FastCGI containers to launch the app
(Maybe other containers, too, if PyWCI standard catches on by then...)
Move up to peak.web
Adapt the IGreetingService to a Web UI wrapper
Unfortunately, peak.web is a huge leap, since it requires path/hierarchy and adaptation
Perhaps there's a less steep area we can find to introduce those concepts in first
'peak.security' might also need a gentler introduction, so it's familiar by the time you get to peak.web
Maybe the socket "hello service" could grow a bit of a protocol with user/password, so we can show security there