You are not logged in Log in Join
You are here: Home » Zope Documentation » #Zope » Zope Page Templates » zpt_chat_log

Log in
Name

Password

 
**** BEGIN LOGGING AT Fri Apr 6 11:52:19 2001

--- Topic for #zope is www.zope.org :: Chat with Evan Simpson in #zope, today at 1:00 pm EDT (17.00 GMT) about ZopePageTemplates -- http://www.zope.org/Wikis/DevSite/Projects/ZPT
<DC_Evan> Ok, first the chat intro:
<DC_Evan> The purpose of this chat is to introduce Zope Page Templates to members of the Zope community who would like to learn more about them, and to discuss the features and future development of ZPT.
<DC_Evan> I'm basically going to briefly describe our goals, then open up for questions
<DC_Evan> Zope Page Templates were created with a very specific audience in mind: teams of designers and programmers who work closely and iteratively to design sites.
<DC_Evan> ZPT is not a replacement for DTML in any sense. It is an alternative that is meant to be attractive to designers who use WYSIWYG editors, and the programmers who work with them.
<DC_Evan> This means that we place a premium on round-trip between Zope and the editor, and on not breaking code with presentation changes, and vice-versea.
<DC_Evan> There's a lot of work to be done to bring ZPT up to full strength, but we have a good start in 1.0
<DC_Evan> What we need now is *lots* of feedback from the people who ought to be most interested in using this tool.
<DC_Evan> So, all that said, I'm ready for questions.
<ChrisW> Where would you see DTML still being used in a year's time?
<et> Do you think Java people will use the ZPT specs for a Java implementation?
<DC_Evan> Any place where you want to generate text that isn't tag-structured: SQL, structured text, etc.
<gotcha> By good start, do you mean ready for production sites ?
<mindlace> ok
<mindlace> please let evan answer a Q before posting yours
<gotcha> ok sorry...
<DC_Evan> I'd love to see the basic ideas of ZPT (TAL, TALES, METAL) used in non-Zope projects.
<DC_Evan> As much as possible, we've tried to make the parts usable in Python without Zope.
<DC_Evan> As much as possible, we've tried to make the parts usable in Python without Zope.
<DC_Evan> done.
<DC_Evan> Next q: production
<DC_Evan> I'm using it on one simple site, where it has worked well.
<DC_Evan> Also, I'm preparing a ZClass-intensive Quiz sample application
<DavidS> Are there any good tutorials on using ZPT? I can't find much besides the specs.
<DC_Evan> in which Scripts and Page Templates are used pretty much exclusively - no DTML.
<DC_Evan> I hope to be able to release it early next week.
<DC_Evan> done.
<kedai> with ZPT - we need to know more - TALES,TAL,METAL - will there/is there a side by side eg of doing something in DTML and in ZPT. (i've seen the examples in the Wikis, but that is still not enough, methinks)
<DC_Evan> So far, only the DTML unit tests that Jim translated for use with ZPT.
<faassen> and you'd just more Python Script to do it in TAL anyway, I suspect, than with the common DTML patterns.
<DC_Evan> One of the big tasks still outstanding is to produce tutorial and example materials.
<DC_Evan> done.
<TheJester> Doesn't ZPT spell the end of extending zope by writing custom tags for zope?
<DC_Evan> Not really, since DTML will still be alive and well. Also, there is a feature that several
<faassen> TheJester: now you have your whole attribute language namespace. :)
<DC_Evan> people (myself included) badly want to add to ZPT, which would allow you
* faassen shuts up for now. :)
<DC_Evan> to write Scripts (or whatever) that could be called from a template in order to manipulate
<DC_Evan> the contents of the template in a DOM-like fashion. Eg. you could write a Script
<DC_Evan> that scans your template for forms, and inserts JScript validation based on what it sees.
<DC_Evan> done.
<gotcha> I have been trying to find in the source code the properties/attributes available for the tal:repeat variable, but did not succeed. Can you help us now ?
<TheJester> it's 3am I'm off to bed..
<DC_Evan> There was a bug, fixed in CVS, where the code was out of sync with the spec. "repeat" used to be "loop" and the namespace variable was still called that.
<DC_Evan> There was also a security bug with access to the repeat variable contents, now fixed.
<Monchauxx00> Evan, we are all extremely impressed with the work you've done with ZPT. How did you come up with such an awesome idea? Where did it all begin, what did you try that had to be scrapped?
<DC_Evan> The repeat variable also needs to be extended and rationalized, since it was put together
<DC_Evan> rather hastily to support Jim's unit tests.
<DC_Evan> done.
<DC_Evan> For me, ZPT started as the feature I described earlier, which we still haven't got :-)
<rdmurray> Will docs on repeat and its sub-variables be added to the wiki soon?
<DC_Evan> I wanted a dtml-render tag that would let me pre-process HTML in a structured way.
<DC_Evan> This led me to think about parsing and markup difficulties.
<DC_Evan> Then HiperLogica came along and sprang HiperDOM on us, which implemented a lot of what we
<DC_Evan> had been tossing around. This gave us the impetus to buckle down and really do it.
<DC_Evan> done. Next:
<mindlace> And my small contribution (I think) was that they should be attributes of existing nodes
<gotcha> I was not clear : in the repeat statement, a variable is assigned on each iteration. Does this variable has some special properties a la sequence-item in DTML ?
<mindlace> because I was tired of fugly HTML
<DC_Evan> More docs are definitely on their way. Feel free to add a proposal, if you like.
<DC_Evan> done. I need to go away for 2min. BRB, talk amongst yourselves :-)
<DT> yada yada
<rdmurray> aday aday
<Zadig1> I'm pleased with the turnout. Lots more folks here for this chat than in the past.
<rdmurray> With pythonscripts part of the core, I'm using a lot less dtml these days anyway.
<gotcha> How many of us already tried ZPT with something else than toy problems ?
<mindlace> that variable is pretty much equivalent to sequence-item, gotcha
<faassen> I was using lots of tiny external methods first, but tiny python scripst are easier. :)
<rdmurray> But I'd also like to see some examples of using ZPT *without* zclasses, as that's the way I'd prefer to work :)
<mindlace> if i understand you correctly.
* faassen only did toy problems.
<et> Who is using ZPT in a framework different than Zope?
<ChrisW> Will DTML will still be developed and improved for the forseeable future?
<mindlace> et noone has implemented it elsewhere yet.
<faassen> ChrisW: that's what they said somewhere on a web page. So yes.
<DC_Evan> Back now.
<rdmurray> All I've done so far is convert a simple header/footer combo to a zpt template. But it looks good.
<faassen> ChrisW: there are also some proposed projects on dev.zope.org involving TALES-ing DTML.
<gotcha> then I am tring to speak of sequence-start, sequence-end, ... of dtml-in ?
<ChrisW> WTF is TALES?
<mindlace> ChrisW: lots of the nice stuff from ZPT (like paths) will prolly make it into dtml
<Zadig1> one of my clients has a "traditional" interbase backed Zope e-commerce site. He wants another site distributable on CDROM.. 1500 objects entirely in Zope.. I'd like to use ZPT for this, but still thinking about it.
<DC_Evan> Yes, I'm going to be working on getting the best features of ZPT into DTML
<ChrisW> Coool
<ChrisW> <dtml-var /something/here> would be nice :-)
<DC_Evan> Repeat variables will be extended to include all useful info that dtml-in has, except batching
<faassen> ChrisW: TALES -> http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TALES
<rdmurray> How does one handle batching in a zpt setup?
<ChrisW> one line summary (me lazy and tired rigth now :-S)
<DC_Evan> Batching will be handled by a separate batch object, that should make them much more flexible and useful in both realms.
<faassen> ChrisW: that is the one line summary on that page. :)
<rdmurray> "will be" means that isn't implemented yet, right?
<DC_Evan> In a nutshell, TALES in DTML will mean being able to write "python:code" or "path:a/b/c" in pretty much any DTML tag attribute.
<DC_Evan> Jim made a first stab at batching, but it needs work.
<DC_Evan> done.
<condor> will CMF be build upon ZPT?
<DC_Evan> I don't know about built upon; I don't think that decision has been made.
<DC_Evan> Compatible with, yes, definitely.
<ChrisW> :-)
<DC_Evan> It remains to be seen how well ZPT meshes with the CMF layering model.
<DC_Evan> Could be great, could be messy.
<DC_Evan> done.
<gotcha> Where should we look if we want to help you extending repeat variables ?
<DT> there's been a lot of talk about getting ZPT added into what we deliver as CMF product right now though
<DaJoker> Will the zope default objects be migrated to ZPT? And if so, will it be done faster than the switch from <!--# syntax to <dtml- syntax?
<DC_Evan> Heh. 1:
<DC_Evan> If you want to help with anything, the Wiki is the place to go. Feel free to add pages! That's what Wiki is all about.
<moshez> Hi, Evan
<DC_Evan> 2: Form of a question, please?
<DC_Evan> 3: Again, no commitment has been made, but I will definitely be rooting for ZPT in the core, wherever it makes sense.
<DC_Evan> done.
<moshez> sorry I couldn't make it earlier.
<moshez> I wanted to ask you about error handling.
<DC_Evan> Go ahead.
<moshez> The direction the discussion *seems* to have been going in was alarming.
<moshez> My classical use case for error handling, like I said in the wiki, was something like tal:content="request/myname"
<moshez> I don't have any good suggestions, unfortunately :(
<DC_Evan> That particular case is being kicked around on the zpt mailing list.
<moshez> The best I can do is try to suggest emulating dtml-try/dtml-except...
<DC_Evan> Right now, we have the exists: prefix, which lets you test whether a path will resolve,
<mindlace> I vote for "lazy" which does if it can but doesn't otherwise.
<moshez> Evan: hmmmm.....but that works only for path:
<DC_Evan> a proposed lazy: prefix, which I think causes the statement it's used in to simply do nothing
<DC_Evan> if the path doesn't resolve.
<gotcha> What is the location of the ZPT mailing list ?
<moshez> Hmmmm......that's not good for that use-case.
<DC_Evan> These capabilities will need to be exposed to python: code, of course, and you can always
<mindlace> http://lists.zope.org/mailman/listinfo/zpt
<DC_Evan> place exception-prone code in a Script.
<DC_Evan> Thanks, ethan.
<DC_Evan> done.
<moshez> Yah, but it does seem an overkill for simple stuff that might raise KeyError.
<faassen> moshez: is your use case a non existent request variable?
<moshez> faassen: yes.
<faassen> what may be a good idea to address that is a way to call preprocess code from the top of a TAL page.
<mindlace> right, which is why lazy is good: leave default if not found
<faassen> that makes sure the thing is there in REQUEST or whatever. It could look at the TAL and dig out any request/foo.
<faassen> and list them in there, so you can supply defaults or whatnot.
<moshez> faassen: I don't think of it as default.
<faassen> oh, lazy has a default?
<moshez> Let me clarify my use-case:
<DC_Evan> You can call anything you like, by putting a tal:define="foo here/myProcessing" at the top of your template.
<moshez> Take the classical CGI, where it is both the page that executes the code, and the form.
<moshez> The ideal for me would have a python-like try/except/else
<moshez> Was that considered?
<DC_Evan> Example of lazy: use -- <p tal:content="lazy:request/spoon">There is no spoon</p>
<moshez> hmmmm......with tal:replace, that might do exactly what I want....
<DC_Evan> You can do try/except-type stuff with on-error; The original exception is saved and handed
<faassen> would lazy only work with paths then or am I missing smoething about TALES?
<DC_Evan> to the on-error handler, which can choose to handle it, re-raise it, or raise a new exception
<moshez> Evan: Yeah, that's what I thought I'd use (the on-error).
<DC_Evan> The lazy: currently proposed is path-specific, but it doesn't have to be.
<mindlace> or <input type=text tal:attributes="value lazy:request/something">
<moshez> Evan: My problem with on-error style solutions is that I don't get to specify the exceptions I want to catch.
<DC_Evan> We could easily write a prefix that can be added to any other, that triggers on traversal-type errors in whatever expression it's added to.
<MrTopf> sorry..
* moshez didn't understand the last sentence...
<moshez> Oh, nm
<moshez> I think I did.
<DC_Evan> I may be wrong, but I think you can do what you want by examining the exception passed to on-error and re-raising it if you don't want to handle it.
<moshez> like not:?
<DC_Evan> Yes, like not:
<moshez> Evan: That what Perl always said about eval/die. It just seems to encourage catching too much.
<moshez> Actually, the prefix sounds pretty cool to me.
<rdmurray> It'd make more sense from a language perspective to have the error-type-checking built in, but maybe that isn't possible here?
<DC_Evan> Guiding principle note: We don't want to put too much code in templates. That's what Scripts are for.
<mindlace> Amen!
* moshez agrees with guiding principle.
<Charle_C> Zustimmung!
<DC_Evan> ZPT stuff should be fairly minimal, mostly naming objects.
<DC_Evan> done.
<gotcha> a la Phillip Eby: Do it if you need it but it looks like a design problem :-)
<mindlace> As soon as you're checking multiple conditions or doing error handling, is it really about presentation anymore?
<moshez> Yeah, which is why something that *only triggered on KeyError* would be fine.
<moshez> mindlace: but what I want is not to catch all errors, because some may be bugs.
<moshez> mindlace: and presentation can have bugs too...
<bigdaddy_> DC_Evan: I read earlier that there were some performance issues... have you started to optimize yet?
<DC_Evan> So, is anyone out there part of the target audience ;-). By that I mean, who here works with a non-technical person who designs pages?
<gotcha> I do�
<twinpics> me too
<DC_Evan> No opt yet,
<mindlace> right, well, lazy (or something like it) should get you what you want. This issue is being debated as we speak on the ZPT list
<faassen> I sometimes do, but my not-so-technical people tended to learn DTML. :)
* dc0e has worked with such people, but tries not to
* macIvyer is a non-technical person who works with bigdaddy and DaJoker
<DC_Evan> though we've tried to be pretty efficient where it didn't slow down implementation.
<moshez> Evan: I'm part of the people who need some solutions for the graphic designers they worked with.
<faassen> they were HTML hand coders anyway.
<apoirier> Did you make some edition tests with HTML editor ? What is the more "compliant" with TAL ?
<moshez> Evan: So I understand the problems designers face.
<rdmurray> I work with people who do html and don't want to learn dtml. But I haven't exposed them to ZPT yet, since it's so new :)
<DC_Evan> We're targeting DreamWeaver and GoLive, since those seem to be the biggest targets.
<ChrisW> What version of DW?
<rdmurray> Does Frontpage (excuse me for mentioning it) fail miserably?
<DC_Evan> Hmm, DW4 personally, though it should be fine with any recent design program, I hope.
<DC_Evan> No idea about FrontPage, I hear it's gotten better, but I still won't touch it :-)
<ChrisW> Does DW4 play nice with the WebDAV sourceport then?
<Charle_C> DC_Evan: I'm an HTML king struggling mightily with Zope and have DW3
<DC_Evan> There's a DW patch for WebDAV that seems to work well.
<dondi> I'm a non-technical designer who is working with ZPT. I just figured out basic dtml. ZPT looks interesting but the learning curve looks steep right now.
<DC_Evan> It's not much better than FTP right now, tho.
<ChrisW> heard that ebfore :_S
<mindlace> i believe the patch is only for DW4
<DC_Evan> ZPT ought to be easy to get started with, once we have an example or two for you to follow.
* moshez is more interested in ZPT as something that will let JS coders and server-side coders work together. Yes, I know I'm weird...
<rdmurray> Once the docs have solidified, I expect the learning curve on zpt will be shorter than the one for dtml.
<DC_Evan> That's my current task, with the Quiz example.
<rdmurray> a lot shorter
<gotcha> dondi: do you work with technical zopists ?
<DC_Evan> At the very least, ZPT is much more "regular" than ZPT.
<ChrisW> ?
<apoirier> Could TAL help the internalization process ? Perhaps a TAL attribute to look-up into dictionnaries and replace the content ?
<rdmurray> I think he meant dtml :)
<mindlace> I think one of the "big ideas" is that you can write your pages as straight HTML and *then* go in and mark it up... or have a coder do that.
<dondi> Yes, I do work with people trying to create thier own products and some python scripters.
<rdmurray> mindlace: that fits perfectly into our development model, so I'm hoping it will work.
<DC_Evan> I have no idea whether ZPT would work well for internationalization, but suspect it may.
<mindlace> so at least you can (if you're like me) separate the designer and coder parts of your brain.
<DC_Evan> Especially if we can make "modes" work.
<apoirier> what are "modes" ?
<DC_Evan> Modes are a somewhat vague idea that we have had for a long while, that would
<DC_Evan> let you treat a ZPT as having several modes of operation.
<DC_Evan> The point would be to take large chunks of the page,
<dondi> Where is the best place to start in ZPT, what is a good tutorial right now?\
<DC_Evan> such as a table which can be empty, have few elements (no batching), or have many (batching)
<gotcha> dondi:I have found no tutorial at this moment...
<mindlace> dondi: no tutorial right now, but it is being worked on
<moshez> dondi: there isn't a tutorial, but try the TAL/TALES/METAL specs. They are very readable.
<DC_Evan> and design a mode of the page for each alternative.
<rdmurray> Read the wiki
<dc0e> DC_Evan: earlier you said "We're targeting DreamWeaver and GoLive" -- what does that mean? Will there not be DTDs (or whatever they're now called) to make it work with any SGML/XML editor?
<rdmurray> there are some useful examples in there
<faassen> could you do that with prefixes?
<faassen> like, mode 0: python: 1 + 1
<faassen> mode 1: python: 3
<faassen> though you'd have multiple attributes of the same name then.
<faassen> bad thing, I guess.
<faassen> you'd need to put the information in the attributes.
<moshez> yes.
<apoirier> hmm, for me, seems to be more like a multi views-model problem for me than a TAL one
<DC_Evan> Implementation details are hazy, as yet, but would essentially require several ZPT objects yoked together.
<Charle_C> Does ZPT require WebDAV for non-coders?
<faassen> yoked together? what do you mean with ZPT objects in this case?
<moshez> faassen: ZPT already has the problem that the attributes are too much structured.
<DC_Evan> Targeting: We test ZPT with DreamWeaver and GoLive, to make sure they play nice. We expect
<mindlace> Charle_C: you can use FTP but it's not as bright.
<DC_Evan> that any reasonably-behaved HTML editor should be fine, but we want to test the most prominent tools.
<dondi> What's the equivalent in ZPT to DTML Document Properties?
<faassen> moshez: how do you mean that, too structured?
<gotcha> I would like to stress the point that no tools can solve all problems
<faassen> dondi: I always put them on folders anyway. :)
<Charle_C> So DW4 or GoLive5?
<Phill> emacs ? ;)
<DC_Evan> Right now, Page Templates can't have user-defined properties. I hope to see this addressed
<factor> Phill:heh,cool.
<rdmurray> faassen: the stuff in the attributes is very dense semantically.
<gotcha> So trying to put too much responsability on ZPT would risk to leave the main goal : easing presentation work.
<moshez> faassen: take tal:attribute
<DC_Evan> by a future proposal that would provide a framework for adding property sheets to just about any object in Zope.
<apoirier> So, with DW or GL, you can design the page, then add some TAL, then go back to the design without losing any TAL attributs and so on ..., is it ok ?
<moshez> faassen: it has multiple layers of structure, with ugly rules like "double ;s"
<DC_Evan> That the idea, yes.
<DC_Evan> Preserving the code without intruding on the design experience is the primary motivation behind ZPT.
<Charle_C> apoirier: thank you, that helps me understand it better
<DC_Evan> Round-tripping rules! Done.
<moshez> Evan: re: round-tripping via server side.
<DC_Evan> Yes?
<faassen> moshez: ah, right, I hadn't noticed the double ;; bit. ick.
<moshez> Evan: I thought it would be cool if the output could be made a valid input, whenver possible
<dondi> Is ZPT replacing DTML?
<moshez> Evan: e.g., make tal:replace=nothing on all the output from a repeat except the first.
<moshez> dondi: for the correct definition of "replace"
<DC_Evan> That was an early idea, but we moved away from it.
<ChrisW> why?
<factor> heh
<ChrisW> :-)
<DC_Evan> Issues with making the round-trip really work kept cropping up. Consider tal:condition.
<moshez> Evan: yeah....
<DC_Evan> done.
<DC_Evan> Bueller?
<ChrisW> [OT]: Evan, have you had any 'weird shit' with calling PS from DTML?
<apoirier> Is it easy to extend the TAL attributes (like adding a new tag in dtml) ?
<mindlace> OK, folks, it's been an hour.
<DC_Evan> ChrisW: apart from a recent bug with namespace binding, no.
<mindlace> I have to sigy off, so this will be the end of the official chat,
<ChrisW> When was that fixed?
<DC_Evan> Extending: Sort of.
<ChrisW> 2.3.1b1 or 2.3.1
<mindlace> but whoever wants to continue may.
<ChrisW> Bye Ethan :-)
<moshez> mindlace: will there be an official place the log will be posted?
<DC_Evan> Seeya Ethan. I'll stay on for ~15min more.
<dondi> Where is ZPT, TAL, TALES, METAL heading?
<seb> aw crap, i got the time difference wrong ;)
<macIvyer> DC_Evan: Is ZPT a product or built directly into Zope?
<mindLog> /Documentation/Chats
<DC_Evan> dondi: That's for y'all to help decide. We're just beginning to get feedback, mostly on the zpt mailing list.
<moshez> thx
<DC_Evan> ZPT is a standalone Product at the moment, though
<DC_Evan> I fully expect it to become part of Zope.
<ChrisW> Does it work on Windows out-of-the-box yet?
<DC_Evan> I have a report that it does, but haven't tried, myself.
<dondi> How does ZPT mix with XML?
<moshez> dondi: ZPT pages are supposed to be valid XHTML pages.
<moshez> that was phrased wrong
<DC_Evan> Very well, I hope. The tal: and metal: namespaces are designed with XML in mind.
<faassen> I wasn't sure how/if ZPT hooks into ParsedXML, if at all.
<moshez> You can write ZPT so it will stay valid XHTML, if what you started with was valid XHTML
<faassen> I saw you could install ParsedXML etc, but does it just reuse the expat parser?
<faassen> or what is up with that?
<DC_Evan> ZPT uses pyexpat, currently by looking for it in ParsedXML first.
<faassen> right, okay.
<DC_Evan> I *really* want to move that to Shared/DC/xml
<faassen> is there any other use of ParsedXML in combination with ZPT?
<DC_Evan> Not off the top of my head.
<faassen> okay, I figured there wasn't, but I wasn't sure.
<apoirier> "ZPT pages are supposed to be valid XHTML page". ZPT working only with XHTML ?
<DC_Evan> They started off looking synergystic, but then we went all HTMLy
<DC_Evan> Once, but no more. It has an HTML parser now.
<moshez> apoirer: hence my "this is phrased wrong"
<faassen> apoirier: ZPT works with any HTML code that is XML compliant. That's not necessarily XHTML.
<faassen> DC_Evan: or am I wrong and doesn't it even need XML compliant HTML anymore?
<Phill> what happened to the 4DOM stuff? Did that die?
<dtml-if> .
<faassen> Phill: $DOM died long ago, ParsedXML contains a good standards compliant DOM though.
<faassen> that's 4DOM.
<DC_Evan> You can't put TAL or METAL on non-XHTML tags (unclosed paragraphs), but otherwise should be fine.
<apoirier> so, "not even need XML compliant HTML anymore", right ?
<Phill> faas : I assume the same for the other 4thought stuff?
<rdmurray> I believe the html has to be xml compliant.
<condor> FYI, ZPT works on Windows but not the XML part
<rdmurray> At least, it complained when I tried to write <dtml-var "PARENTS[0]"> :)
<faassen> Phill: yup.
<apoirier> hmm, ok. So, when a TIDY integrated ZOPE wrapper ?
<DC_Evan> Could you put something in the tracker about the Windows XML failure, please?
<Charle_C> Thank you for an informative session. Have a nice weekend
<Phill> bye CC
<dondi> Has ZPT been tested on Mac OS X?
* ChrisW waves... off home for food :-)
<moshez> bye, chrisw
<DC_Evan> Not to my knowlege. We'd love to know, tho.
<dondi> thanks chrisw
<ChrisW> moshez: You ahd a Squishdot question?
* ChrisW sniggers
<moshez> ChrisW: Go home, eat ;-)
<Zadig1> When is the next ZPT "release" going to be?
<moshez> food's important
<dondi> I'm on Mac OS X now, and I don't notice any issuess. Are there python tests?
<ChrisW> I got a Worms team made up of famous Python people
<DC_Evan> We thought about using Tidy to make HTML into XHTML, but decided that could break round-trip.
<ChrisW> moshez: Whassup? What was the question? ;-)
<zxc0> 17:00 gmt is like in 2 hours ?
<DC_Evan> Zadig1: Next week.
<moshez> ChrisW: Oh, I basically just wanted to know where is swishdot, if at all.
<moshez> Is it just an idea, or did you start writing something?
<ChrisW> That's my task for thsi weekend :-)
<ChrisW> I have started
<DC_Evan> dondi: there are unit tests you could try
<ChrisW> But I was waiting for CMF to sort its life out ;-)
<faassen> Swishdot uses XML and ZPT and amazing adapter interfaces buzzword compliance!
<faassen> RDF!
<faassen> just making this up, Moshe. :)
<moshez> ChrisW: cool. I'm always here, and really interested in CMF
<moshez> faassen: I know you ;-)
<ChrisW> faassen: you may be, I'm not ;-)
<faassen> I know you know me, Moshe!
<faassen> I said 'hi' to you before.
<dondi> What unit tests could I try?
<ChrisW> No XML, but ZPT is high up my list :-)
<faassen> I know ChrisW isn't, I just like to make stuff up for other people.
<moshez> faassen: No, I meant "I know youm I guess you made it up" ;-)
<faassen> ah, okay. :)
<factor> heh
<faassen> that too.
<faassen> I tend to make things up. Except on April 1, when I'm curiously silent.
<faassen> for me, april 1 is the only day I'm serious in the year.
<moshez> faassen: what did you think about my April 1?
<faassen> what was yours, Moshe? :)
<DC_Evan> dondi:TAL includes docs on how to run its unit tests, ZPT has a tests directory that hopefully is self-explanatory
* ChrisW is pissed that I won't get a DC hat, t-shirt & mug from the CMF skins competition :-(
<faassen> I probably saw it but then I saw so much.
<moshez> faassen: Guido moving to active state.
<factor> ChrisW:What future plans,directions do you have for Squish.
<faassen> ooh, was that yours? That was an excellent one, and fitted quite well with the Parrot one. :)
<dondi> Thanks DC_Evan.
<moshez> factor: Squish is going nowhere
<moshez> faassen: completely by accident!
* faassen nods.
<kedai> evan - will/is there good docs, apart from the APi and zope help about python scripts?
<faassen> who was behind the Parrot one? Guido and Larry really or some other folks?
<moshez> faassen: Guido claimed ignorance.
<faassen> that's what I'd do as well. :)
<ChrisW> Squish is going to Swish
<DC_Evan> kedai:yes, as time permits :-/
<faassen> Tim wrote the code samples though, so he must've been in on it.
<ChrisW> I'm writing a data-mover thing when I get near 1.0 of Swishdot
<moshez> faassen: Yeah, I suspect Tim and Laura
<faassen> ChrisW, are you going to componentize it all?
<ChrisW> 1.0 of Swishdot will not take as long as 1.0 of Squishdot ;-)
<faassen> moshez: Laura?
<ChrisW> faassen: yup
<moshez> faassen: Laura Lewin, the Python person at O'Reilly
<DC_Evan> Time for me to evaporate. It's been fun, thank you all for being here!