Strategies for building ZPatterns applications as python Products?
Hi, I'm thinking about migrating my ZPatterns-based application, which is currently built from standard Zope components, into a python Product. I'm looking for ideas on the best way to organize the application. I'm not trying to build a general-purpose application that can be instantiated easily, but I do need to consider reusing the application in the future, which will require customizing features, UI, etc. My main confusing is whether I should put everything in the python product, or also have methods in the application instance. Putting some methods (especially UI) in the instance will make it easier to customize, but then large pieces of the application are out of the product and I lose the advantages that made me want to use a product in the first place. OTOH, keeping everything in the product requires creating a new, modified product every time I need a new instance with different UI or features (this might not be so bad considering that it does not get instantiated very often, and that a lot of customizing work is expected anyway - but it would make it hard to merge in code updates that are relevant to all instances). Also, when the app is built as a product it will define its own DataSkin classes, so ZClasses will not be used at all - but then there's no place for customizable object methods. Another issue is that for the product to provide all the code I need to create my own Racks - every Rack in the application has to be a separate class which adds methods and SkinScripts specific to that Rack. And every Specialist needs a customized Racks management form that allows for adding the appropriate Racks for that Specialist. This seems like a huge amount of work compared to managing a standard objects and ZClasses application. I'd appreciate any suggestions or description of how people are dealing with these decisions. TIA, Itai P.S This is starting to sound a lot like the problems the PTK^H^H^HCMF is dealing with using skins... but implementing that kind of functionality is waaaay beyond the amount of work I can afford to put in... also, skins would help to customize UI, but not features, so actually copying and modifying the product might be something I just can't avoid. -- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --
Hi Itai, You might be able to steal some code from EMarket for this. It doesn't set up custom Racks, but it does set up Specialists with custom methods. Note that EMarket is in serious flux, and that 'the basic way things are done' is changing. ZPatterns Zen takes a bit to grok, and my first pass at EMarket for ZPatterns was a tad on the early side of Zen building. But.. with that caveat.. I think it may represent a useful approach for your Product.. take care, -steve
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
Itai> Hi, I'm thinking about migrating my ZPatterns-based Itai> application, which is currently built from standard Zope Itai> components, into a python Product. I'm looking for ideas on Itai> the best way to organize the application. Itai> I'm not trying to build a general-purpose application that Itai> can be instantiated easily, but I do need to consider Itai> reusing the application in the future, which will require Itai> customizing features, UI, etc. Itai> My main confusing is whether I should put everything in the Itai> python product, or also have methods in the application Itai> instance. Putting some methods (especially UI) in the Itai> instance will make it easier to customize, but then large Itai> pieces of the application are out of the product and I lose Itai> the advantages that made me want to use a product in the Itai> first place. OTOH, keeping everything in the product Itai> requires creating a new, modified product every time I need Itai> a new instance with different UI or features (this might not Itai> be so bad considering that it does not get instantiated very Itai> often, and that a lot of customizing work is expected anyway Itai> - but it would make it hard to merge in code updates that Itai> are relevant to all instances). Also, when the app is built Itai> as a product it will define its own DataSkin classes, so Itai> ZClasses will not be used at all - but then there's no place Itai> for customizable object methods. Itai> Another issue is that for the product to provide all the Itai> code I need to create my own Racks - every Rack in the Itai> application has to be a separate class which adds methods Itai> and SkinScripts specific to that Rack. And every Specialist Itai> needs a customized Racks management form that allows for Itai> adding the appropriate Racks for that Specialist. This Itai> seems like a huge amount of work compared to managing a Itai> standard objects and ZClasses application. Itai> I'd appreciate any suggestions or description of how people Itai> are dealing with these decisions. Itai> TIA, Itai Itai> P.S This is starting to sound a lot like the problems the Itai> PTK^H^H^HCMF is dealing with using skins... but implementing Itai> that kind of functionality is waaaay beyond the amount of Itai> work I can afford to put in... also, skins would help to Itai> customize UI, but not features, so actually copying and Itai> modifying the product might be something I just can't avoid. Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper -- Itai> _______________________________________________ Zope Itai> maillist - Zope@zope.org Itai> http://lists.zope.org/mailman/listinfo/zope ** No cross Itai> posts or HTML encoding! ** (Related lists - Itai> http://lists.zope.org/mailman/listinfo/zope-announce Itai> http://lists.zope.org/mailman/listinfo/zope-dev )
Hi Steve, Thanks. I've looked at all the ZPatterns-based products I could find when I started thinking about making this transition - and EMarket was the first I looked at. The problem is that there are some things in the way EMarket is organized that I don't like - which is why I'm looking for a strategy that would work better for me. When you create a new EMarket instance, all dtml methods get installed in the instance, and from then on all customization gets done ttw on the instance. This is fine for a product that users who are not experienced in python product editing are expected to take and use as-is and only customize the UI. But in my case, the application is expected to be heavily customized for both features and UI for every instance, and does not need to be simple enough to be managed by a non-programmer. So moving a large part of the application into the instance doesn't make sense to me. Also, I'd like to keep UI code that displays class instances where I think it belongs - in the class, rather than in the Specialists as in EMarket. So I either create ZClasses and place the UI methods in them, or keep the UI in the product. And requiring ZClasses, the way EMarket does, is another thing I want to avoid, when I can have the product manage all classes on its own. So... I guess I either need to be convinced that the EMarket structure is indeed good... or get some confirmation from anyone that a more product-centric approach is appropriate (and workable). What really bothers me is that if I end up with a lot of methods in the instance, I lose much of the benefit of using a product. For example, I can't make changes on a test server and then upload the new product to the live server while retaining existing data - I need to copy individual methods instead. Itai The Infinitely Confused Steve Spicklemire wrote:
Hi Itai,
You might be able to steal some code from EMarket for this. It doesn't set up custom Racks, but it does set up Specialists with custom methods. Note that EMarket is in serious flux, and that 'the basic way things are done' is changing. ZPatterns Zen takes a bit to grok, and my first pass at EMarket for ZPatterns was a tad on the early side of Zen building. But.. with that caveat.. I think it may represent a useful approach for your Product..
take care, -steve
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
Itai> Hi, I'm thinking about migrating my ZPatterns-based Itai> application, which is currently built from standard Zope Itai> components, into a python Product. I'm looking for ideas on Itai> the best way to organize the application.
Itai> I'm not trying to build a general-purpose application that Itai> can be instantiated easily, but I do need to consider Itai> reusing the application in the future, which will require Itai> customizing features, UI, etc.
Itai> My main confusing is whether I should put everything in the Itai> python product, or also have methods in the application Itai> instance. Putting some methods (especially UI) in the Itai> instance will make it easier to customize, but then large Itai> pieces of the application are out of the product and I lose Itai> the advantages that made me want to use a product in the Itai> first place. OTOH, keeping everything in the product Itai> requires creating a new, modified product every time I need Itai> a new instance with different UI or features (this might not Itai> be so bad considering that it does not get instantiated very Itai> often, and that a lot of customizing work is expected anyway Itai> - but it would make it hard to merge in code updates that Itai> are relevant to all instances). Also, when the app is built Itai> as a product it will define its own DataSkin classes, so Itai> ZClasses will not be used at all - but then there's no place Itai> for customizable object methods.
Itai> Another issue is that for the product to provide all the Itai> code I need to create my own Racks - every Rack in the Itai> application has to be a separate class which adds methods Itai> and SkinScripts specific to that Rack. And every Specialist Itai> needs a customized Racks management form that allows for Itai> adding the appropriate Racks for that Specialist. This Itai> seems like a huge amount of work compared to managing a Itai> standard objects and ZClasses application.
Itai> I'd appreciate any suggestions or description of how people Itai> are dealing with these decisions.
Itai> TIA, Itai
Itai> P.S This is starting to sound a lot like the problems the Itai> PTK^H^H^HCMF is dealing with using skins... but implementing Itai> that kind of functionality is waaaay beyond the amount of Itai> work I can afford to put in... also, skins would help to Itai> customize UI, but not features, so actually copying and Itai> modifying the product might be something I just can't avoid. Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper --
Itai> _______________________________________________ Zope Itai> maillist - Zope@zope.org Itai> http://lists.zope.org/mailman/listinfo/zope ** No cross Itai> posts or HTML encoding! ** (Related lists - Itai> http://lists.zope.org/mailman/listinfo/zope-announce Itai> http://lists.zope.org/mailman/listinfo/zope-dev )
-- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --
I'm trying to port a very small portion of a php script i used to have. the concept is quite easy, but I dont see how to accomplish it at zope. let' see if anyone can understand this php code and tell me which function at zope may I use for it: print "<table>"; print "<tr>"; while ($item = current($array)) { for ($n=0 ;$n<3;$n++) { print "<td>$item</td>"; next($array); } print "</tr>"; } print "</table>"; what this code does is to print all the contents of an array in a table of 3 columns, using a cell for each element. I'm trying to do this same thing but using a <dtml-in expr="objectValues('Folder')"> instead of the array. Can someone provide a dtml sample on how to do this? Thank you so much, (and sorry for the offtopic code) Alex
On Tue, 6 Mar 2001 00:48:00 -0300 Alex Verstraeten <alex@quad.com.ar> wrote:
I'm trying to port a very small portion of a php script i used to have. the concept is quite easy, but I dont see how to accomplish it at zope.
let' see if anyone can understand this php code and tell me which function at zope may I use for it:
print "<table>"; print "<tr>"; while ($item = current($array)) { for ($n=0 ;$n<3;$n++) { print "<td>$item</td>"; next($array); } print "</tr>"; } print "</table>";
what this code does is to print all the contents of an array in a table of 3 columns, using a cell for each element. I'm trying to do this same thing but using a <dtml-in expr="objectValues('Folder')"> instead of the array.
Can someone provide a dtml sample on how to do this?
I'd do it as a PythonMethod or PythonScript: output = '<table>\n' column = 1 for item in array: if column == 1: output = output + '<tr>\n' output = output + '<td>%s</td>\n' % item if column == max_column: output = output + '</tr>\n' column = 1: else: column = column + 1 output = output + '</table>\n' return output This code is written off the top of my head, so I don't know if it works. I do know that it won't do too well when the number of elements in the array isn't a muliple of max_column; I'll leave that as an exercise for the reader :-) John
On Tue, 6 Mar 2001, Alex Verstraeten wrote:
print "<table>"; print "<tr>"; while ($item = current($array)) { for ($n=0 ;$n<3;$n++) { print "<td>$item</td>"; next($array); } print "</tr>"; } print "</table>";
what this code does is to print all the contents of an array in a table of 3 columns, using a cell for each element. I'm trying to do this same thing but using a <dtml-in expr="objectValues('Folder')"> instead of the array.
I'm not sure exactly what you want to print--do you want to print the name of the item found in the folder? The title? The contents? <dtml-in "objectValues(['Folder'])"> <tr> <td><dtml-var title_or_id></td> </tr> </dtml-in> This will print the title, or failing that, the ID. The Zope book is an excellent reference for questions like this. -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
Hi Itai, I agree with many of your comments about the structure of EMarket. Factoring is hard and the current decisions about EMarket were made because I didn't want to require the user to subclass his EMarket classes from my 'special' classes.. so I put more methods in the Specialists. Also, the EMarket approach makes a lot more sense in the context of ZCVSMixin (which I also use a lot!) for 'sync'ing development and production servers. Also, putting methods/dtml in the instance is harder than leaving them in the Class! If you want something to be *not* editable ttw, just set it as a class attribute in your Product. But then you've got to edit filesystem based code to customize... which means you need subclass to customize. Also.. (my last also.. I promise!) EMarket doesn't require ZClasses, it just requires DataSkins (any DataSkin subclass should do). I've got one EMarket running now.. where most/all the EMarket integration was done as SkinScript... The Refresh product makes doing more at the Product level a bit more bearable as well... but it seems to me that you'll need to subclass your application every time you want to customize it... is that the plan? This seems to have problems of its own. take care, -steve
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
Itai> Hi Steve, Itai> Thanks. I've looked at all the ZPatterns-based products I Itai> could find when I started thinking about making this Itai> transition - and EMarket was the first I looked at. Itai> The problem is that there are some things in the way EMarket Itai> is organized that I don't like - which is why I'm looking Itai> for a strategy that would work better for me. Itai> When you create a new EMarket instance, all dtml methods get Itai> installed in the instance, and from then on all Itai> customization gets done ttw on the instance. This is fine Itai> for a product that users who are not experienced in python Itai> product editing are expected to take and use as-is and only Itai> customize the UI. But in my case, the application is Itai> expected to be heavily customized for both features and UI Itai> for every instance, and does not need to be simple enough to Itai> be managed by a non-programmer. So moving a large part of Itai> the application into the instance doesn't make sense to me. Itai> Also, I'd like to keep UI code that displays class instances Itai> where I think it belongs - in the class, rather than in the Itai> Specialists as in EMarket. So I either create ZClasses and Itai> place the UI methods in them, or keep the UI in the Itai> product. And requiring ZClasses, the way EMarket does, is Itai> another thing I want to avoid, when I can have the product Itai> manage all classes on its own. Itai> So... I guess I either need to be convinced that the EMarket Itai> structure is indeed good... or get some confirmation from Itai> anyone that a more product-centric approach is appropriate Itai> (and workable). Itai> What really bothers me is that if I end up with a lot of Itai> methods in the instance, I lose much of the benefit of using Itai> a product. For example, I can't make changes on a test Itai> server and then upload the new product to the live server Itai> while retaining existing data - I need to copy individual Itai> methods instead. Itai> Itai The Infinitely Confused Itai> Steve Spicklemire wrote: >> Hi Itai, >> >> You might be able to steal some code from EMarket for this. It >> doesn't set up custom Racks, but it does set up Specialists >> with custom methods. Note that EMarket is in serious flux, and >> that 'the basic way things are done' is changing. ZPatterns Zen >> takes a bit to grok, and my first pass at EMarket for ZPatterns >> was a tad on the early side of Zen building. But.. with that >> caveat.. I think it may represent a useful approach for your >> Product.. >> >> take care, -steve >> >>>>>>> "Itai" == Itai Tavor <itai@optusnet.com.au> writes: >> Itai> Hi, I'm thinking about migrating my ZPatterns-based Itai> application, which is currently built from standard Zope Itai> components, into a python Product. I'm looking for ideas on Itai> the best way to organize the application. >> Itai> I'm not trying to build a general-purpose application that Itai> can be instantiated easily, but I do need to consider Itai> reusing the application in the future, which will require Itai> customizing features, UI, etc. >> Itai> My main confusing is whether I should put everything in the Itai> python product, or also have methods in the application Itai> instance. Putting some methods (especially UI) in the Itai> instance will make it easier to customize, but then large Itai> pieces of the application are out of the product and I lose Itai> the advantages that made me want to use a product in the Itai> first place. OTOH, keeping everything in the product Itai> requires creating a new, modified product every time I need Itai> a new instance with different UI or features (this might not Itai> be so bad considering that it does not get instantiated very Itai> often, and that a lot of customizing work is expected anyway Itai> - but it would make it hard to merge in code updates that Itai> are relevant to all instances). Also, when the app is built Itai> as a product it will define its own DataSkin classes, so Itai> ZClasses will not be used at all - but then there's no place Itai> for customizable object methods. >> Itai> Another issue is that for the product to provide all the Itai> code I need to create my own Racks - every Rack in the Itai> application has to be a separate class which adds methods Itai> and SkinScripts specific to that Rack. And every Specialist Itai> needs a customized Racks management form that allows for Itai> adding the appropriate Racks for that Specialist. This Itai> seems like a huge amount of work compared to managing a Itai> standard objects and ZClasses application. >> Itai> I'd appreciate any suggestions or description of how people Itai> are dealing with these decisions. >> Itai> TIA, Itai >> Itai> P.S This is starting to sound a lot like the problems the Itai> PTK^H^H^HCMF is dealing with using skins... but implementing Itai> that kind of functionality is waaaay beyond the amount of Itai> work I can afford to put in... also, skins would help to Itai> customize UI, but not features, so actually copying and Itai> modifying the product might be something I just can't avoid. Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper -- >> Itai> _______________________________________________ Zope Itai> maillist - Zope@zope.org Itai> http://lists.zope.org/mailman/listinfo/zope ** No cross Itai> posts or HTML encoding! ** (Related lists - Itai> http://lists.zope.org/mailman/listinfo/zope-announce Itai> http://lists.zope.org/mailman/listinfo/zope-dev ) Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper --
Hi Steve, I think that what I'm trying to do is quite different than EMarket. I'm trying to build an object model-based application that can be reused. And following O-O rules, reuse should happen at the level of selecting objects from the original application, subclassing some that need to be changed and completely replacing others that are not appropriate for the new application. I'm not even sure that the basis for starting a new application should be an EMarket-like class that builds everything else - rather each application needs its own top level class to encompass everything. But then even that is not necessary - because that class gets instantiated only once. So the process for starting a new application might be to create a folder and populate it with instances of Specialist-derived classes from the original application. I'm not sure that subclassing to customize can be avoided, because customizing can involve more than modifying UI methods, when features or interfaces need to be changed. In any case, I'll be subclassing anyway, because I don't want to place class methods in Specialists, so I can either create ZClasses and place the UI methods in them, or create filesystem-based classes. It seems that what I'm planning is a full application that can later be torn apart and reused, when maybe I should be trying to build a template product that can be instantiated, like EMarket. I'm not sure which approach is better. And I can't figure out how to build an EMarket-like product while providing the ability to mix different classes and change features and interfaces for each instance. Creating a new application by reusing and subclassing objects from an existing product seems more in the O-O way to me, but it does create its own problems. If anyone else is still following this thread, could you please throw in your comments, if you ever developed an object-model/Product/ZPatterns based application? Itai P.S And to the rest of the list, apologies for the growing length of this thread. Steve Spicklemire <steve@spvi.com> wrote:
Hi Itai,
I agree with many of your comments about the structure of EMarket. Factoring is hard and the current decisions about EMarket were made because I didn't want to require the user to subclass his EMarket classes from my 'special' classes.. so I put more methods in the Specialists.
Also, the EMarket approach makes a lot more sense in the context of ZCVSMixin (which I also use a lot!) for 'sync'ing development and production servers.
Also, putting methods/dtml in the instance is harder than leaving them in the Class! If you want something to be *not* editable ttw, just set it as a class attribute in your Product. But then you've got to edit filesystem based code to customize... which means you need subclass to customize.
Also.. (my last also.. I promise!) EMarket doesn't require ZClasses, it just requires DataSkins (any DataSkin subclass should do). I've got one EMarket running now.. where most/all the EMarket integration was done as SkinScript...
The Refresh product makes doing more at the Product level a bit more bearable as well... but it seems to me that you'll need to subclass your application every time you want to customize it... is that the plan? This seems to have problems of its own.
take care, -steve
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
Itai> Hi Steve,
Itai> Thanks. I've looked at all the ZPatterns-based products I Itai> could find when I started thinking about making this Itai> transition - and EMarket was the first I looked at.
Itai> The problem is that there are some things in the way EMarket Itai> is organized that I don't like - which is why I'm looking Itai> for a strategy that would work better for me.
Itai> When you create a new EMarket instance, all dtml methods get Itai> installed in the instance, and from then on all Itai> customization gets done ttw on the instance. This is fine Itai> for a product that users who are not experienced in python Itai> product editing are expected to take and use as-is and only Itai> customize the UI. But in my case, the application is Itai> expected to be heavily customized for both features and UI Itai> for every instance, and does not need to be simple enough to Itai> be managed by a non-programmer. So moving a large part of Itai> the application into the instance doesn't make sense to me.
Itai> Also, I'd like to keep UI code that displays class instances Itai> where I think it belongs - in the class, rather than in the Itai> Specialists as in EMarket. So I either create ZClasses and Itai> place the UI methods in them, or keep the UI in the Itai> product. And requiring ZClasses, the way EMarket does, is Itai> another thing I want to avoid, when I can have the product Itai> manage all classes on its own.
Itai> So... I guess I either need to be convinced that the EMarket Itai> structure is indeed good... or get some confirmation from Itai> anyone that a more product-centric approach is appropriate Itai> (and workable).
Itai> What really bothers me is that if I end up with a lot of Itai> methods in the instance, I lose much of the benefit of using Itai> a product. For example, I can't make changes on a test Itai> server and then upload the new product to the live server Itai> while retaining existing data - I need to copy individual Itai> methods instead.
Itai> Itai The Infinitely Confused
Itai> Steve Spicklemire wrote:
>> Hi Itai, >> >> You might be able to steal some code from EMarket for this. It >> doesn't set up custom Racks, but it does set up Specialists >> with custom methods. Note that EMarket is in serious flux, and >> that 'the basic way things are done' is changing. ZPatterns Zen >> takes a bit to grok, and my first pass at EMarket for ZPatterns >> was a tad on the early side of Zen building. But.. with that >> caveat.. I think it may represent a useful approach for your >> Product.. >> >> take care, -steve >> >>>>>>> "Itai" == Itai Tavor <itai@optusnet.com.au> writes: >> Itai> Hi, I'm thinking about migrating my ZPatterns-based Itai> application, which is currently built from standard Zope Itai> components, into a python Product. I'm looking for ideas on Itai> the best way to organize the application. >> Itai> I'm not trying to build a general-purpose application that Itai> can be instantiated easily, but I do need to consider Itai> reusing the application in the future, which will require Itai> customizing features, UI, etc. >> Itai> My main confusing is whether I should put everything in the Itai> python product, or also have methods in the application Itai> instance. Putting some methods (especially UI) in the Itai> instance will make it easier to customize, but then large Itai> pieces of the application are out of the product and I lose Itai> the advantages that made me want to use a product in the Itai> first place. OTOH, keeping everything in the product Itai> requires creating a new, modified product every time I need Itai> a new instance with different UI or features (this might not Itai> be so bad considering that it does not get instantiated very Itai> often, and that a lot of customizing work is expected anyway Itai> - but it would make it hard to merge in code updates that Itai> are relevant to all instances). Also, when the app is built Itai> as a product it will define its own DataSkin classes, so Itai> ZClasses will not be used at all - but then there's no place Itai> for customizable object methods. >> Itai> Another issue is that for the product to provide all the Itai> code I need to create my own Racks - every Rack in the Itai> application has to be a separate class which adds methods Itai> and SkinScripts specific to that Rack. And every Specialist Itai> needs a customized Racks management form that allows for Itai> adding the appropriate Racks for that Specialist. This Itai> seems like a huge amount of work compared to managing a Itai> standard objects and ZClasses application. >> Itai> I'd appreciate any suggestions or description of how people Itai> are dealing with these decisions. >> Itai> TIA, Itai >> Itai> P.S This is starting to sound a lot like the problems the Itai> PTK^H^H^HCMF is dealing with using skins... but implementing Itai> that kind of functionality is waaaay beyond the amount of Itai> work I can afford to put in... also, skins would help to Itai> customize UI, but not features, so actually copying and Itai> modifying the product might be something I just can't avoid. Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper -- >> Itai> _______________________________________________ Zope Itai> maillist - Zope@zope.org Itai> http://lists.zope.org/mailman/listinfo/zope ** No cross Itai> posts or HTML encoding! ** (Related lists - Itai> http://lists.zope.org/mailman/listinfo/zope-announce Itai> http://lists.zope.org/mailman/listinfo/zope-dev )
Itai> -- Itai Tavor -- "Je sautille, donc je suis." -- Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every Itai> day, once a day, give yourself a present" - Dale Cooper --
-- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --
participants (5)
-
Alex Verstraeten -
Itai Tavor -
Joel Burton -
John Morton -
Steve Spicklemire