[00:01:49] ? [00:02:19] does that note mean anything to u? [00:12:04] <_jpl_> I'm not a big fan of ZPT [00:57:13] ** pje has joined us [00:57:20] p.w.t = peak.web.templates [00:58:05] And I expect that if you dislike ZPT, you might like pwt even less. :) [01:00:06] * pje yawns [01:00:10] I should be in bed. [01:01:56] * pje waves [01:02:05] ** pje has left us [01:02:07] <_jpl_> Hello [01:02:21] <_jpl_> Actually I like p.w.t a lot better than ZPT. [01:04:04] ** pje has joined us [01:04:12] So what do you like about Cheetah, then? [01:04:24] It seems at the far opposite extreme from p.w.t. [01:10:56] <_jpl_> I like Cheetah for completely different (i.e. non-web) templating needs. [01:11:55] <_jpl_> My primary users are sysadmins, and I'm giving them the ability to build scripts and system configurations using Cheetah. [01:12:08] <_jpl_> Something like ZPT or PWT wouldn't work. [01:12:46] <_jpl_> I also like Cheetah's placeholder magic. [01:13:51] <_jpl_> I also also like the object-oriented nature of Cheetah templates. [01:15:41] Doesn't cheetah's $ notation conflict with shell scripts? [01:16:17] (Also, PWT's domlets don't *have* to be XML.) [01:16:25] That's just how the current parser works. [01:16:47] <_jpl_> Most of the time it shouldn't get in the way, since you can do (and would usually want to do) all the variable substitution at the Cheetah level. [01:16:57] * pje nods [01:17:19] Suppose you had a PWT syntax like... [01:17:51] {define=foo text:bar} [01:18:22] Or maybe more like {define foo text:bar} or {text:bar} or {define foo} [01:18:36] <_jpl_> hmmm [01:18:54] Contained text would be in nested {}, or maybe separate the main bit from the rest with a | [01:19:12] So you might have... [01:19:18] {list:things| [01:19:43] {define listitem|echo {text:blah} [01:19:44] } [01:19:48] Yuck. [01:19:53] Okay, even I don't like that. :) [01:19:58] <_jpl_> That's pretty far from what a shell/perl scripter would consider intuitive, I think. [01:20:32] It does rather seem that you could get close to cheetah, though... [01:20:51] # for things { [01:20:55] # } [01:21:08] Hmm.. [01:21:12] # for things { [01:21:18] <_jpl_> But curly braces... [01:21:20] * _jpl_ grimaces [01:21:34] echo {text:blah} [01:21:40] # } [01:21:58] I'm probably being hampered by trying to make the syntax uniform. [01:22:44] That is, have a PWT-like standard way to specify a domlet and/or define label. [01:23:12] * _jpl_ nods [01:23:38] It probably needs a *less* uniform syntax, that then gets mapped back into domlet+define. [01:24:11] So that $blah is short for domlet="text.notag:blah", in effect. [01:25:15] <_jpl_> hmm [01:25:23] <_jpl_> That would be interesting. [01:25:34] I wonder if you could reuse shell ${} syntax... [01:25:37] e.g. [01:25:49] ${for things do [01:25:56] echo $blah [01:26:04] } [01:27:44] I guess I keep looking for a magical mapping to and ... [01:28:21] like ${text:blah} ==> [01:28:44] <_jpl_> Besides it's implementation, what do you not like about the Cheetah approach? [01:29:05] and ${for things|...|} ==> ... [01:29:13] It's ugly. [01:29:17] (Cheetah syntax) [01:29:30] <_jpl_> Yes, it is somewhat. [01:29:34] Too Perlish for me. [01:29:56] For text generation, it seems easier just to use Python. [01:30:15] For *ML generation, PWT leaves it in the dust. [01:30:30] But, I could go for a good way to do PWTish things in plain text. [01:31:06] Hmmm... [01:31:16] <_jpl_> I wouldn't say plain Python is easier... the placeholder magic is a lot friendlier to non-programmers (or programmers not terribly familiar with complex data structures). [01:31:30] * pje nods. I see your point there. [01:32:07] What if we made the syntax ${label: verb value|nestedcontent|} [01:32:19] where the simplest form is just $value [01:32:25] <_jpl_> Plus not needing to concatenate variables or literals, since you're in text mode by default. [01:33:04] Variations... ${label:value|content|} [01:33:14] ${label: verb} [01:33:21] ${label: verb value} [01:33:27] ${verb value} [01:33:46] ${label:|content|} [01:34:25] e.g. [01:34:35] ${for things [01:34:41] |echo $blah [01:34:44] |} [01:34:50] Or... [01:34:51] ** gpciceri has joined us [01:34:55] ${for things| [01:35:00] echo $blah|} [01:35:14] depending on whether you want the linefeed before or after each item... [01:35:20] Or of course... [01:35:25] ${for things|echo $blah [01:35:29] |} [01:36:04] hello [01:36:11] Hi. [01:37:26] Whaddya think, JPL? Is that even in the ballpark of being competitive? [01:37:53] I'm little confused about peak domain models and components support, is there a sample showing their interaction ? [01:38:14] gpcieri: have you looked at bulletins.commands? [01:38:27] no, but now I go [01:38:56] I'm not sure if it's what you mean, but it certainly is components accessing domain model objects. [01:39:08] exactly [01:39:17] <_jpl_> The sysadmin in me would still be more inclined to Cheetah... [01:39:27] <_jpl_> Especially since | looks like a pipe. [01:39:54] Alternative suggestions? [01:40:49] <_jpl_> Aren't you trying to avoid logic in PWTs? [01:40:52] One problem with shell scripts is that pretty much *all* the characters are taken. :) [01:41:07] JPL: yep. [01:41:36] Primarily by bundling logic into smart components. [01:41:59] E.g., if I was using this to generate SQL, I'd want verbs that could handle things like IS NULL vs. =someValue... [01:42:11] Automatic AND insertion if/when needed... [01:42:11] pje, THX, it's exactly what I mean. I'll look at it *carefully*. I searched for this kind of information on the wiki but with no success. I think it would be interesting put a link on the wiki for this. [01:42:40] gpciceri, the IntroToPeak also covers that sort of thing, by lessons three and four. [01:43:33] I'd want a "comma-separated list" command, and so on. [01:43:45] So you see, I want to avoid coding stupid things like: [01:44:15] <_jpl_> Cheetah has filters that could do things like that, but it's not an ideal solution. [01:44:29] , [01:44:42] I have code now that does that over and over and over again... [01:45:01] It'd be nice to say ${commalist somelist} and be done with it. :) [01:45:38] Or ${commalist somelist|$foo|}, to make a list of the foo attributes of the items in somelist. [01:46:01] <_jpl_> That's pretty nice, yes... [01:46:19] That's the sort of high-level construct PWT "wants" to do, rather than being a plain ol' text spitter-outer. :) [01:46:26] <_jpl_> Though the smalltalk-ish syntax would still be confusing to shell/perl scripters. [01:46:43] Yeah... so if you have a better syntax, I was hoping you could suggest it. :) [01:47:01] <_jpl_> What's wrong with parens? [01:47:13] <_jpl_> ${commalist somelist($foo)} [01:47:32] So the content in the parens has to be balanced then... [01:48:05] You can't do e.g. ${if foo ( ( )} [01:48:21] (output a parenthesis if foo) [01:49:05] It'd need to be another character plus the paren, the way the real terminator in the other syntax was |}, not '|'. [01:50:04] I suppose there's always < ${commalist somelist < $foo [01:50:17] EOF [01:50:19] } [01:50:22] heh. [01:50:33] <_jpl_> That's beautiful. [01:50:38] <_jpl_> ;) [01:50:43] Yeah, right. [01:51:03] <_jpl_> So what's "somelist" in this example, versus $foo? [01:51:09] I suppose << and >> are actually out. [01:51:31] somelist would be a variable in the current context, and foo would be an attribute of the current item in somelist. [01:52:09] You could make $_ map to the current item itself. :) [01:52:58] Actually, the more we talk about this, the more I see how much the current PWT domlet architecture is tied to peak.web. [01:53:13] Because the default domlets manage navigation using PWT navigation techniques. [01:53:42] OTOH, it really doesn't matter in that the DOMlets used for text don't have to be implemented the same way. [01:54:22] AFAICT, there would be incredibly little overlap in what DOMlets you'd use for text with those used in HTML, just as the ones you might use for XRC are different from what you'd use for HTML. [01:54:49] Indeed, it's likely you'd use different DOMlet sets for SQL vs Latex vs Shell vs Apache config file vs... [01:55:11] * pje yawns [01:55:23] Ah well, this isn't really going anywhere. [01:55:55] <_jpl_> Sorry I'm not offering more input, I'm trying to finish some deliverables for tomorrow... [01:55:56] It'd probably be better to try to design domain-specific templating languages as they're needed. [01:56:23] No, it's not you, it's that the approach isn't going to lend itself to just coming up with "one syntax for all text domains". [01:57:03] It'd be better to design specific domain syntaxen, and then simply use PWT techniques to implement their parsers. [01:57:24] I was just curious whether it was possible to have a clean "one syntax for text". [01:57:37] And I think I'm pretty clear now that there isn't. :) [01:57:58] <_jpl_> That approach would be really nice, I think. [01:58:12] <_jpl_> (different syntaxes on top of one architecture) [01:58:25] What's nice though is that text-oriented domlets are at least *potentially* reusable in different domains. [01:58:27] E.g. commalist. [01:58:53] However, you could call it different things in different domains, e.g. 'inlist' for SQL. [01:59:08] Just set the properties to point to the same class/factory object. [01:59:10] * _jpl_ nods [01:59:15] <_jpl_> I like the sound of that. [01:59:44] Actually, for SQL you'd really want an "in list", that checked for length 1 and replaced it with an =value clause. :) [01:59:57] Well, gotta head for bed... 'nite all. [02:00:08] <_jpl_> Good night [02:00:12] * pje waves [02:00:14] ** pje has left us [03:31:26] ** vlado_ has joined us [03:31:38] morning [04:12:24] ** vlado_ has joined us [05:37:55] ** vlado_ has joined us [05:52:53] ** _jpl_ has joined us [07:02:32] {server notice} Hi guys, that server is you. Sponsor will reboot the box in a min [17:42:39] [disconnected at Fri Jan 16 17:42:39 2004] [17:42:43] [connected at Fri Jan 16 17:42:43 2004] [17:42:43] <> *** Looking up your hostname... [17:42:43] <> *** Checking ident [17:42:43] <> *** Found your hostname [17:43:14] <> *** No identd (auth) response [17:43:14] <> *** Your host is kornbluth.freenode.net[kornbluth.freenode.net/6667], running version dancer-ircd-1.0.32 [17:43:14] [I have joined #peak] [17:43:14] ** kornbluth.freenode.net set the topic to PEAK http://peak.telecommunity.com || WikiPages at http://peak.telecommunity.com/DevCenter || IRC-Logs: http://peak.telecommunity.com/irc-logs/ [18:14:59] <_jpl_> Hi logbot. [18:40:48] <_jpl_> You're pretty quiet, logbot. Unlike all the other chatterboxes here. [18:54:47] given that peak-logbot's only purpose is to log [18:54:52] it seems sensible [18:55:06] just wait until my multi-protocol bot comes to life [18:55:14] it will do all kinds of stupid tricks [18:56:32] <_jpl_> Don't forget to add a sarcasm attachment. [19:03:31] what bot are you referring to? [19:03:38] any in particular? [19:03:56] how did pje know you are a cheetah fan is he stalking you ? ;) [19:06:23] <_jpl_> He reads the IRC logs daily, it seems. [19:06:32] <_jpl_> (maybe more than daily) [19:07:00] <_jpl_> So he's stalking all of us. :) [19:08:16] :) [19:08:26] * Maniac wonders when jpl spoke of cheetah [19:09:17] also totally off-topic. i think that bittorrent downloads should d/l faster u/l [19:09:33] i'll end up u/l'ing waaay more than i d/l [19:10:06] oh, and roundup rocks! [19:10:07] http://randomthoughts.vandorp.ca/syncato/WK/blog [19:10:42] <_jpl_> We've been using JIRA lately and really like it. [19:10:53] i have no idear what JIRA is ? [19:11:22] http://www.atlassian.com/software/jira/ [19:11:33] $$ [19:12:15] <_jpl_> Free for open source projects, though. [19:12:22] bah java [19:12:35] what projects are you working on opensores? [19:12:52] <_jpl_> Agreed, but they really did a good job. It's one of the most functional, well-thought-out interfaces I've ever used. [19:13:19] <_jpl_> And a really great example of a good web interface. [19:13:34] cool [19:13:36] <_jpl_> Our PEAK-based configuration management system will be open source. [19:13:41] i'm not really anti java [19:13:46] configuration management? [19:14:11] i just know 1 language kinda-sorta and thats python (oh i guess object-pascal ala delphi) [19:15:37] <_jpl_> Take a look at www.cfengine.org for reference. [19:16:31] so your' duplicating in python ? [19:16:35] where do you work? [19:17:04] i am loosely familiar with cfengine but never needed it myself [19:17:23] * Maniac is bored [19:17:31] <_jpl_> Our system will do what Cfengine does, plus a lot more (like system builds, package management, basic batch job management, object-oriented configurations). [19:17:55] <_jpl_> I work at LookSmart (looksmart.com) [19:25:24] <_jpl_> So roundup handles multiple projects? [19:25:55] <_jpl_> Does it handle components within projects (like "documentation", "infrastructure", "database", etc.)? [19:26:20] <_jpl_> How about project versions? [19:42:23] <_jpl_> (He must've found something to relieve him of his boredom) [19:44:22] (kids) [19:44:40] _jpl_, roundup handles whatever you want to customise it for [19:45:00] my roundup tracker tracks products, nonconforming items, customer complaints (manufacturing) [19:45:43] <_jpl_> In other words, there's extra work involved. [19:45:59] but of course [19:45:59] :) [19:46:10] so you work for a search engine-ish company [19:46:27] interesting [19:46:58] <_jpl_> In a small programming group within the operations department whose task is to automate systems management. [19:47:50] hence the cfengine-ish stuff [19:48:04] <_jpl_> Yep. [19:48:27] see i'm an office type who does this python-peak stuff to make my day job easier [19:48:49] <_jpl_> Yes, you once said you were a PHB. [19:49:12] using the term loosely [19:49:27] boss anyways, my hair is not pointy [19:50:08] <_jpl_> That part doesn't matter so much. :) [19:53:33] ooo my bittorrent sped up ! [20:17:19] grr it slowed down again [20:41:00] <_jpl_> Python 2.3's zipimporter is quite nice. [20:50:45] <_jpl_> er, zipimport [21:21:03] to save space?