[00:05:42] --> easy__ has joined #peak [00:05:58] <-- easy__ has quit #peak [00:10:48] --> easy has joined #peak [00:10:51] <-- easy has quit #peak [00:11:05] --> easy has joined #peak [05:51:34] --> aloisius has joined #peak [09:14:33] --> jack-e has joined #peak [10:15:01] * jack-e is gone (12:15PM): .. autoaway .. [10:17:41] --> easy has joined #peak [12:21:56] --- jack-e is now known as jack-e|brb [13:01:13] --> Maniac has joined #peak [13:50:10] * Maniac notes that dizzyd has muchly improved the hemp code for jabber [13:50:34] * Maniac notes it also breaks all his test scripts, but that's life in cvs [13:51:39] maniac: do you thing hemp will soon be in a usable state ?? [13:51:53] (e.g. replace the jabberpy lib) [13:52:57] and how permormant will it be .. i doubt that the xpath stuff that is used right now, will perform very well (except they implement it in C) [13:53:46] jack-e|brb: well, it's in a 'useable' state, just in a state of flux :) [13:54:12] it seems he will NOT be implementing a server though. NDA's and such as I think he works(?) for jabber.com [13:54:27] i'm not sure on performance [13:55:00] keep in mind that jabberpy is not an active project at all [13:55:42] but at least, jabberpy seems to work for many cases fairly well ;-) [13:55:54] but jabberypy's 'event' loop is borked [13:56:08] but yes, it does 'work' [13:56:22] i'm more interested in a well done jabber-client than a python-based jabber-server .. so i'm fairly interested in hemp (or jabberpy built on top of twisted) .. [13:56:53] i'm not sure if someone could take xmlstream from jabberpy and use twisted instead somewhere [13:57:18] i've looked at the jabber-py 's socket handling .. and it wouldn't be too hard to build it in an asyncore/twisted way .. allthough you'ld have to fork it [13:57:23] a python based jabber server i think would be good for test cases, a server also would be neat to poke at [13:57:34] by 'fork' you mean fork the code? [13:57:40] yup [13:58:29] make it so :) [13:58:49] * Maniac add's it to jack-e|brb's 'todo' list [13:59:46] i'll first have to do some research with twisted tcp/protocol stuff before taking that one on my todo (which is way too long) .. and i won't start that before beginning of september [14:00:35] * Maniac was joking [14:00:47] i'm going to use hemp for my 'playing' [14:00:53] it works well enough [14:00:57] * jack-e|brb needs not to stop chatting and clean up his desk, finish paperwork and prepare for the upcoming weekend where he needs to turn the tables .... [14:01:05] and performance isn't a concern [14:01:09] turn the tables? [14:01:21] * jack-e|brb is a spare-time DJ ;-) [14:01:27] ah! [14:01:30] ok WORK! [15:02:01] * jack-e|brb is gone (5:02PM): .. autoaway .. [16:50:51] nice WE [17:28:23] damn-- I just missed jack-e. I was going to tell him that taking xmlstream from jabberpy and hacking it into twisted's event loop is what I've done. So he needn't do that part. This post is for his perusal later. [17:37:40] oh! [17:38:01] jolby: and which way do you like better? dizzd's or your hacked xmlstream? [17:42:05] I think dizzyd's approach is much nicer/cleaner. I'm a little worried about the performance of it, but he said it could easily be optimized if need be. [17:42:05] Unfortunately, I may not be able to use it because its GPL, and I need to be able to reserve the right to create non-OS extensions for clients. That's why I would like to release as LGPL. [17:42:25] ah, and xmlstream.py is lgpl? [17:42:42] ya [17:42:45] ic [17:43:17] I think twisted is as well. [17:43:57] twisted is lgpl, so if dizzyd wants hemp to be 'core' twisted i would think he'd have to re-license [17:45:48] That'd be great!. My dispatch code is fairly pluggable, so it wouldn't be hard for me to put a new dispatcher in should it become available. [17:46:38] if :) [17:47:18] he refactored hemp last night quite a bit.... rapidly changing still so using xmlstream etc. is probably much more stable [17:47:29] when does jolby show off some code? [17:51:48] well, probably not for a couple weeks at least, because I'm going on vacation next week for a week or so, and I won't have time to do some basic cleanups+set up project page +cvs+etc before I leave. [17:57:48] --> Maniac has joined #peak [17:57:48] --> _Maniac has joined #peak [17:57:48] --> yarcat has joined #peak [17:57:48] --> als has joined #peak [18:27:37] --> pyniac has joined #peak [18:28:13] <-- pyniac has quit #peak [18:36:57] --> pyniac has joined #peak [19:03:25] --> _jpl_ has joined #peak [19:03:28] <_jpl_> Hi all [19:10:36] --> pje has joined #peak [19:10:47] Guten tag. [19:12:17] <_jpl_> God dag [19:12:35] Hm, that's almost a palindrome. :) [19:12:52] Gad, dog! :) [19:12:57] hello [19:13:15] <_jpl_> Almost. Just thought I'd add to the language collection we have going here. ;) [19:14:33] * pje is trying to sort out the skins issue for peak.web [19:14:52] I thought I'd come see if you guys had any ideas. :) [19:15:28] <_jpl_> I've only had a chance to glance at your post so far. I'll try to find a few minutes to give it a closer reading. [19:16:10] * als is not going to use peak.web [19:17:53] It seems to me that PEAK already contains enough layering/namespace abstractions to be able to do something as "simple" as skins... [19:18:16] But none of them seem to be *quite* right. [19:18:50] * Maniac greets pje [19:19:08] what we are doing is xslt-based system: xsl transformations make UI forms from session state data, and those forms are then rendered to HTML by one big xsl transformation [19:19:15] The tricky part seems to be in the idea that you can have bindings that are context sensitive... which means the context needs to be extracted. [19:19:27] als: sounds like you might be interested in "maki". [19:19:59] (A Python framework for XML-transforming webapps) [19:20:38] * als did look at maki last autumn [19:21:15] pje: From your post it seems that the definition of a "skin" would basically be a container for a set of parameters, that get injected into the page templates at render time. Is that close? [19:21:23] Pretty much. [19:21:46] Zope 3 defines a skin as an ordered collection of "layers"... [19:21:54] Where layers are a namespace for "resources" [19:22:09] And resources can be things like images, templates, macros, etc. [19:22:53] and layers would be like: Site-->sub-site(search, nav) [19:22:56] ? [19:23:20] I was thinking layers are sets of reusable resources. [19:23:45] For example, one might have common icons that are used by more than one skin. [19:24:09] I don't so much care about an exact mapping to Zope 3, though... [19:24:39] I just want to support the idea of a skin: something that can be determined on a per-hit basis, that controls the presentation used. [19:25:06] E.g. for browser-specific rendering... for "themes"... for "branding"... [19:25:16] per-hit? why not per-session? [19:25:25] pje: what do you mean by "per-hit"? [19:25:30] peak.web has no intrinsic concept of a session. [19:25:47] It only deals in "interactions" which are a single HTTP request. [19:26:03] als: hit = HTTP request/response [19:26:05] How is conversational state maintained? [19:26:13] = one invocation of runCGI() [19:26:21] Jolby: what conversational state? [19:28:01] I.e. user logs in, sets a variable in their user preferences (i.e. whatSkinIWant), and that state is maintained for the rest of their travels thru the site. [19:28:18] Well, that's a cookie. And the cookie is available in each hit. [19:28:28] So, for each hit you read that cookie and select the skin. [19:28:53] You could call that a session, if you wanted to, but why? :) [19:28:55] right -- but the cookie is just a "key" that maps to data maintained on the server. [19:29:14] Maybe... and maybe you just set a cookie for what skin they want. [19:29:29] That's a lot more scalable if that's all you need, and you have lots of visitors. [19:29:55] Point is, this kind of thing varies from one app to the next, which is why there will probably never be a generic "Session" existing in PEAK. [19:30:31] Maybe some components to help manage session cookies or session lifetimes, but any *data* will be something application-specific that you put in a DM. [19:31:34] right. [19:32:04] <_jpl_> Ah, speaking of DMs, are any of the existing DMs oriented to anything other than an RDBMS? [19:32:21] Ulrich has some that map to IMAP and LDAP. [19:32:22] <_jpl_> Or are they all generically usable with whatever backend you want? [19:32:44] JPL: The peak.storage DM base classes are totally generic. [19:33:12] Actually, that reminds me... the XMI DM in peak.storage.xmi is XML-based... [19:33:33] Anyway, if you can write a _load() and _save() method for it, you can use it with a DM. [19:34:02] <_jpl_> Great, that's what I was beginning to suspect. [19:34:40] <_jpl_> Oooh, didn't know about peak.storage.xmi, sounds nice. [19:35:27] JPL: it doesn't save data yet. [19:35:34] It can only read existing XMI files. [19:35:56] Which isn't too bad a thing, if you're using it to read UML or other metamodels from a modelling tool export. [19:35:58] <_jpl_> That's probably ok for now for the vague ideas I had in mind. [19:36:05] <_jpl_> nod. [19:36:46] <_jpl_> Though it would be nice to be able to take an existing set of classes using peak.model and turn them into XMI. [19:37:27] Indeed. But I pushed that back on the schedule to PEAK 0.6, because peak.web (and solidifying documentation) are more important for the 0.5 cycle. [19:38:38] <_jpl_> Agreed. I [19:38:53] <_jpl_> (oops) I'd be pretty interested in using peak.web for some real work. [19:41:28] Ditto. :) [19:41:43] Which is why I need to sort out how skins will work, so I can finish the templating part. :) [19:41:51] Or really, start the templating part. :( [19:42:10] <_jpl_> 'fraid I don't have any ideas at the moment. Have too much on my plate at the job right now. [19:42:32] <_jpl_> And don't know enough about how things currently work, and zilch about Zope3. [19:42:39] I'm thinking I'm going to just go with the properties idea. [19:43:12] Last night I was worried that it would scale poorly since it seemed to require scanning resource directories at startup... [19:43:43] But I think I can work around that with load-on-demand rules. [19:44:12] speaking of DMs, is there any query interface planned, in addition to accessing an object by oid? [19:44:31] als: currently, one uses QueryDM's for that. [19:44:59] But ultimately (maybe in 0.7?) I'd like an OQL/SQL query language. [19:45:57] Truly though, the query language would just be a way of expressing a QueryDM... [19:46:06] Just less awkward than having to make the component. [19:47:03] * als doesn't get the idea how to pass a query to QueryDM [19:47:24] Think of it this way... if you had an SQL query that you used in code, it has some set of parameters... [19:47:37] Oleg is now experimenting with using AddressContext for queries [19:47:41] If you take those parameter values as a tuple, you can use it as an oid... [19:48:04] A QueryDM maps a parameter-tuple to a PersistentList-like object that contains the objects retrieved by the query. [19:48:36] So, if you have a "find X for Y" query, you'd have a QueryDM that used Y as its OID, and returned a persistent list of X's. [19:48:51] pje: but that would allow only equality comparison, wouldn't it? [19:49:01] als: No. [19:49:20] You could have a "find X where Y You just have to have a fixed number of parameters. [19:50:05] As I said earlier, in a way, a query language is just shorthand for constructing a one-time use query DM... :) [19:50:23] ah. so, QueryDM contains the query hard-coded, with placeholders for parameter values. right? [19:50:57] Effectively. [19:51:07] Of course, the actual mechanics may vary, depending on the back-end. [19:51:15] <_jpl_> With a separate QueryDM for each type of query? [19:51:19] For example, a queryDM based on XML may look very different. :) [19:51:37] JPL: yes. [19:52:53] Hm.. I think I have an idea on the properties thing, that might work... [19:53:10] No, not quite. Darn. [19:53:49] Locations are child components of the "root" starting point of traversal... I was thinking I could make that root supply the properties... [19:53:53] what we did with Oleg, is naming.lookup(self, "db:dbmodel/dm?query=and(eq(tree,larch),gt(distance,short way away))") [19:54:18] it seems to be somewhat working yet [19:54:54] als: Note that using URLs for queries has a lot of overhead each time, especially if you have to connect to the DB again. [19:55:03] dm is a data manager and dbmodel is a set of DMs [19:55:37] pje: we use single persistent connection to rdbms [19:55:47] Btw, 'self.lookupComponent(x)' is a shortcut for 'naming.lookup(self,x)' [19:56:21] As long as self is a binding.Component, of course. [19:56:32] (or subclass) [19:57:50] I suppose I should say alternate spelling, rather than shortcut, since it's neither fewer in characters nor shorter in execution. :) [19:58:26] pje: that mail about not promoting PEAK, does it concern the protocols package also? [19:59:02] No... protocols is decently documented, and is reasonably "finished" (note 0.9 version, vs. 0.5alpha for PEAK) [19:59:37] While there's more that can be done with it (and will be), it's usable now. [19:59:54] * als is going home [19:59:54] That's why I announced it to python-announce and the like, whereas I have not made such announcements re: PEAK. [20:00:06] bye, ppls [20:00:08] * pje waves [20:00:12] * Maniac waves [20:00:30] * Maniac grabs a coffee [20:01:49] * pje yawns [20:02:04] <_jpl_> Hey, that's contagious you know. [20:02:27] * pje shrugs [20:03:00] I think I need to give up on making the top of the location tree an actual component root. [20:03:16] Instead, it should get the skin as its suggested parent. [20:03:36] Then, the skin will supply properties for all locations down the traversal path. [20:04:09] * pje normally has these one-sided conversations with Ty, but he's not around right now. [20:04:16] <_jpl_> That sounds interesting. [20:04:50] So... if actual page templates, or anything else "resource"-ish is accessed by binding to properties... [20:04:57] Then they will automatically be skin-specific. [20:05:40] That takes care of mapping from locations -> resources, but not resources -> resources. [20:06:02] So, we can say that a method of some location is a particular template, but how does the template know what view components to use? [20:06:23] * Maniac is not smart enough for any imput so he'll be the quiet side of a one side conversation [20:06:43] Maniac: you can always ask questions. That's often very helpful. [20:06:52] :) [20:06:55] It forces me to expose my assumptions. [20:07:06] Or to clarify my goals. Or whatever. [20:08:13] Anyway, I suppose that the mechanism that loads a template could make the skin a parent component of the template... [20:08:29] So it would access the same properties. [20:08:59] <_jpl_> I was going to ask if that would be a possibility. [20:09:12] And, over time, a given skin would end up caching these properties. [20:09:30] Default values seem a little trickier... [20:09:37] Maybe a lot trickier. [20:09:50] Let's say I have a template in my module... [20:09:58] That I want to use as the default, if the app has no skins... [20:10:22] The normal default mechanism for binding to a property, requires a constant. [20:10:52] But, if the template is a constant object, there's no way for it to access any properties. [20:11:07] (It has no parent component, certainly not one in the same app root as the running app) [20:11:29] <_jpl_> Why doesn't it? [20:11:44] _jpl_: If I define it in code, e.g.: [20:11:54] myTemplate = Template('filename') [20:12:02] and then do: [20:12:06] class Foo: [20:12:25] template = binding.bindToProperty('some.template',default=myTemplate) [20:12:46] Then, either myTemplate has no parent, or it picks up some random instance of Foo as its parent, [20:12:49] permanently... [20:12:57] Regardless of what app-root it's used in. [20:13:30] If we allowed you to have a default *factory* instead, that would do what we'd want, semantically. [20:13:43] <_jpl_> When you instantiate the default, can't you make it a child of the current component? [20:14:01] But, it would be inefficient, because the template would load and parse on each hit (because the location is a per-hit component) [20:14:26] _jpl_: but that's just it, there is no *instantiation* of a binding's default; it's just the default. [20:14:43] And, even if we had that capability, it would be inefficient, as I just noted. [20:15:09] What seems to be needed instead, is a way for the property to "offer up" the default value... [20:15:10] <_jpl_> But a minute ago you did instantiate it with "myTemplate = Template(..." That's where I meant. [20:15:30] _jpl_: that was module-level code... there is no current component to attach to. [20:15:40] And there will be a new "current component" to attach to on each hit. [20:15:59] Really, we want it to attach to the *skin*, which will live across hits. [20:16:02] <_jpl_> Ok, I think I'm seeing the problem now. [20:16:13] <_jpl_> nod. [20:16:19] And is therefore a good place to cache the parsing, etc. [20:17:04] If I were using Zope 3 architecture thinking, I would say, well, you just have to define all the pages in an .ini or other config... [20:17:31] But frankly, that sucks from a usability perspective. [20:18:37] Speaking as a developer, I would rather be able to define a simple in-code binding definition to specify a template... [20:18:56] And have that template be used *unless* a skin is configured to override it. [20:19:20] Not having skins is the common case (in that when you start developing every app, you will likely have only the "default" resources) [20:19:33] So, you shouldn't have extra stuff in front of you getting started. [20:20:40] I think this will need a special binding function, like 'web.bindTemplate()'. [20:21:13] pje: In your example above: template = Template(filename) -- wouldn't the template itself be part of a skin? [20:21:14] The value of the binding will be some kind of object that is a proxy for the real template. [20:21:29] jolby: No, not the default template. [20:21:44] The default template is for when the skin doesn't define a replacement. [20:21:52] gotcha. [20:21:58] Thus, you can distribute a component as package of .py's and .pwt's or whatever... [20:22:07] And somebody can just plug it in, boom, and run the app... [20:22:22] But, if they want themes, etc. they can just add config to overlay it. [20:22:33] and then if they want to overlay their own skin, they would do that in a separate deployment step? [20:22:41] Yes. [20:22:54] By creating other .pwt's or config vars, and setting up config for a skin. [20:23:18] k. that sounds reasonable. [20:23:54] Hmmm... I think I know of a way to fix the defaults problem. [20:24:23] If the property names used have a fixed mapping to the location where the default template can be found... [20:24:48] Then we can have a built-in global default property rule at the root of the template property space. [20:25:13] So, it won't be necessary to specify a default value. You'll just say bindTemplate('some.name')... [20:25:40] And, if that rule's not overridden, then the default location would apply. [20:26:40] And, it would still be able to use the skin as a parent, and cache the loaded template in the skin. [20:27:40] Hmmm. This is going to be a fair amount of work to get right. [20:28:42] The list of questions includes things like, "what's the property namespace for this?" "What's the mapping between names and template locations?" "What if component X wants a different template class?" [20:29:29] Of course, I suppose we could do this such that if a package has non-default needs for its template properties, it can specify these in an .ini loaded as part of the app's root config. [20:31:41] Okay, this is sounding workable from an overall architecture POV. [20:33:32] Except... [20:33:59] I'm wondering how easy it'll be to configure a skin for multiple components... [20:34:27] First, I assume you won't have components' files in the same directory... [20:34:41] --> easy has joined #peak [20:34:43] Because two components might have 'editForm.pwt', for example. [20:35:08] So, each component needs an .ini rule to specify the directory where its templates are held... [20:37:19] Unless of course, there is a naming convention for the directories, in which case, there's just one rule for the whole skin. [20:37:44] Except that then there's no way to do layering, unless you have a layered rule that looks in multiple directories. [20:37:55] I guess that must be it. [20:38:16] You define one rule, '* = layeredTemplateDirectories(dir1, ...)' [20:38:26] And now it does all the dirty work. [20:38:54] Maybe it even loads 'layer.ini' files from each of the directories in the right order, to set up other properties. [20:39:16] * pje waves to easy [20:39:16] Don't mind me, I'm just talking to myself. :) [20:43:08] --> easy has joined #peak [20:43:08] --> pje has joined #peak [20:43:08] --> _jpl_ has joined #peak [20:43:08] --> Maniac has joined #peak [20:43:08] --> _Maniac has joined #peak [20:43:08] --> yarcat has joined #peak [20:43:08] --> als has joined #peak [20:43:27] Hardcoding in the sense of requiring them to be directories, not what directories. [20:43:57] I mean, what if somebody wants to use zipfiles for some crazy reason, or load templates from a database? [20:44:34] Probably what I need instead is to have a layered(whatever) function, based on IConfigSource. [20:45:00] e.g. foo = config.layered(...) [20:45:27] config.layeredRule, maybe. [20:45:38] Or multiRule. Whatever. [20:46:17] And then the lTD() function would translate to multiRule([skinDirectory(x) for x in args]) [20:46:30] So, what do you guys think? [20:46:37] * pje looks around at all the sleeping figures in the room [20:47:01] looks good. But right now its too abstract for me to fit it all together. [20:47:40] seems like all the parts you need are there (In abstract space!) tho' ... :-) [20:47:53] In the concrete, what will happen is there will be some kind of default rule that will look up templates in the directory where their modules are... [20:48:14] And you won't touch any of this until you want to make skins. :) [20:48:18] using a naming convention for the template dir? [20:48:24] * pje nods. [20:48:54] sounds good. The easy default case doesn't make you do much. That's always good. [20:49:01] Static resources are another tricky case. [20:49:25] (Because I don't want to assume that module directories are web-accessible.) [20:49:50] So, if your UI uses images, either we will need to serve them (inefficient, compared to letting Apache do it) [20:49:58] Or have some way to install them. [20:50:27] But, doing the latter adds complexity in a major way. [20:50:38] You could do something like j2ee does there. It will serve files out of a directory under a web.jar- but not in the WEB-INF dirs (that's where classfiles go) [20:51:06] Maybe it would be better to take the trouble to implement all the If-Modified-Since and ETags stuff, just so that people can bundle static files with their modules. [20:51:49] That would actually have less complexity than trying to find a good static location to install to. [20:52:32] For skin-supplied images, of course, one would have the option of using the web server to do it. [20:53:38] Grrr. [20:53:45] This is all way too damn complicated. [20:54:05] Unfortunately, Zope 3's solution is even more so, just in different ways. [20:57:54] Let me try to get back down to basics.. [20:57:54] When you create a skin, you are presumably doing so for some set of components. [20:57:54] But, a given skin/layer might be for different groupings of components. [20:57:54] E.g., person A bundles a "theme" for components B and C, and I install that... [20:57:56] And person D extends that same theme for components E and F, so I install that too... [20:58:30] So we have 'A-themes/theme/B' and 'A-themes/theme/C', and 'D-themes/theme/E'... [20:59:11] So, my layering must list 'A-themes/theme' and 'D-themes/theme'... And this is just one layer. [21:00:35] It also doesn't address various other issues, such as mapping of file-extensions to object types, etc. [21:01:15] These are all solvable problems, just not all at once. :) [21:01:22] * pje sighs [21:01:40] [Global Notice] Hi all. Just a reminder. We are down to a single hub in Europe, and it's probably not our most reliable machine. If you've been considering offering a server as a hub, please take a look at http://freenode.net/sponsoring_servers.shtml .... thanks, and thank you for using freenode! [21:03:46] * Maniac wonders when pje is working on his example app 'bullitens' [21:04:04] I'll start the UI as soon as I have templates. [21:04:27] I'll state templates, as soon as I have this template/layer/access to views thing sorted out. [21:04:32] Er, start templates. [21:04:38] ah [21:04:46] so it will have a web ui? [21:04:52] Yep. [21:04:57] commandline? [21:05:00] GUI? [21:05:05] No GUI. [21:05:16] The command line stuff is just to bootstrap the web application. [21:05:39] I really do intend to use the bulletins app in production at some point. [21:06:47] * pje sighs again. [21:07:03] Alright, here's what I have so far... [21:07:35] The skin is used as the traversal start object's parent. [21:07:47] So that all locations can receive properties from the skin. [21:07:50] --> als_ has joined #peak [21:08:25] You'll access templates via bindToProperty or some equivalent. [21:08:53] And a default rule in peak.ini will ensure that templates bundled with code are found. [21:10:29] Templates use the skin as their parent also, and are cached in the skin. [21:11:15] Unless there is no skin, in which case the top-level config root will be used, both as parent and as cache. [21:12:00] (Hm, that means that the skin component needs to have the same rule as in peak.ini, or default templates will not be instantiated per-skin.) [21:12:55] I guess that's reasonable enough, all in all. It's only when you start to consider skin configuration, layers, bundles, etc. that things start getting hairy. [21:13:31] * Maniac notes the pyprotocols documentation does not print with adobe 5.x [21:14:01] Maniac: nothing made with LaTex prints with 5.x :( [21:14:08] Try 4.x, or 6.x [21:14:20] I know 4.x works; haven't tried 6.x. [21:14:32] * pje doesn't want to upgrade his working 4.x to try! [21:14:44] i have 4.x which i just printed with [21:14:54] pje: ah (the latex thing) [21:15:57] I wonder if I need to rethink views/view stacks for this property-oriented model. [21:17:08] Maybe view components should just be a property space under (say) 'peak.web.views' or 'peak.web.tags'... [21:17:08] And no need to have a view stack. [21:18:02] That might be more verbose than Woven is. [21:18:15] Probably should YAGNI, for now. [21:18:44] Anyway, a custom view component then could be accessed with view="myapp.myview" in an HTML tag. [21:19:30] And the default might be set up such that it is an import, instantiate, and parent to the skin. [21:19:45] Hm. I'm starting to like this. [21:21:29] So, it looks like the view namespace won't be based on locations, which is just as well. [21:21:36] * Maniac prints out the internet [21:21:49] * pje raises an eyebrow [21:21:50] Eh? [21:22:45] so i can read it on the weekend [21:22:55] * pje groans [21:23:05] <_jpl_> You must be a fast reader. [21:24:08] Yeah, in TB/hr. :) [21:25:06] * pje notes 2.3rc1 just came out. [21:26:54] <_jpl_> Excellent [21:29:30] I think I was premature in adding that 'forUser' argument to getSublocation(). Now that views aren't locations, it's unneeded. [21:29:52] It was also going to be used for the root of the model namespace, but I can as easily do that with a simple wrapper over the interaction. [21:30:53] So I guess I'll back that change out, since it's now YAGNI. [21:31:21] * pje observes that there is no course of action so fraught with danger as to undertake to create a new order of things. [21:31:36] I think that's Machiavelli, actually. [21:33:23] --> pyniac has joined #peak [21:34:12] %seen jack-e [21:34:14] last heard jack-e: Thu Jul 17 11:14:16 2003 UTC (about 1 day ago) [21:34:22] ok now we have seen support :) [21:34:54] Eh? [21:35:31] %seen pje [21:35:33] Why, pje is right here! [21:35:53] standard IRC fare. if you jump into a channel and you want to know when someone was last 'seen' [21:36:07] i.e. either spoke or was present in the channel [21:36:57] <_jpl_> (YAGNI?) [21:37:01] Oh... "now we have 'seen support'"... [21:37:10] I thought that parsed as "now we have seen (support)" [21:37:39] * pje was confused [21:37:41] ah [21:37:50] _jpl_: YAGNI = You Ain't Gonna Need It. XP term. [21:38:12] Means that 90% of the time, the fancy framework you think you need, you really don't. [21:38:29] And that if you build it ahead of time, you'll probably wind up needing something else when you get to where you *do* need it. [21:38:45] Something that happens to me with some regularity, in fact. :) [21:39:42] Like that forUser argument I added, thinking I Was Gonna Need It. [21:39:42] But, turns out I don't. [21:39:42] So, the time I put into it was wasted. [21:40:26] do you use PEAK @ work yet pje? [21:40:44] Yes. [21:41:01] Mostly peak.config and peak.naming. [21:42:00] pje: peak.binding ? [21:42:42] Not at work, no. [21:42:51] anyone use emacs for python programing? [21:42:54] Not yet, anyway. [21:43:00] Maniac: nope. [21:43:08] pje: what do you use? [21:43:09] PFE, jEdit, and IDLE. [21:43:15] PFE? [21:43:34] ew java [21:44:58] Programmer's File Editor. [21:45:12] It's a Windows editor; very small, fast, easy. [21:45:31] jEdit's only real weakness is that it's a memory hog and slow to load. [21:45:44] Er, its two real weaknesses are... [21:45:48] * pje grins. [21:45:52] I'll come in again. :) [21:46:04] c-u [21:46:11] * Maniac has to go home [21:46:17] * pje waves [21:46:22] <-- Maniac has quit #peak [21:51:54] <_jpl_> I'm about halfway through reading XP Explained. I've read through it a bit here and there before, but we're now getting serious about adopting some/most of it at work. Tried our first pair programming experiment yesterday. [21:52:54] <_jpl_> I wholeheartedly agree with his points about YAGNI. Yesterday I had to keep telling my co-worker that we should keep things simple and get what we're doing to work rather than go off into architecture orbit. [22:08:06] * pje is posting the new p.w.t design to the list [22:11:45] Y'know, I think this template thing is going to be really interesting... [22:12:00] I can see each tag in the input literally translating to a binding.Component... [22:12:25] Where the 'view=""' determines the class (or else defaults to a plain-text class) [22:13:11] And the plain-text classes will "optimize" themselves if they contain only static contents, so they just return one big string (Unicode, actually) [22:14:01] This means views can offer properties or utilities to contained tags... [22:16:19] Hmmm.. and I can use assembly events to notify views of their "pattern" subcomponents! [22:17:11] Well, not exactly. The parser technically will do the notification, I think. [22:18:02] Finally, this is all clear enough that I can start hacking, and drafting interfaces for various parts of it. [23:27:04] And so ends another week. [23:27:17] Guten abend, all. [23:27:27] Or is that gute nicht? [23:27:29] Ah well. [23:27:33] * pje waves