Re: [Zope-dev] Interface for renderable component
Hi Malthe > Betreff: Re: [Zope-dev] Interface for renderable component > > 2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>: > > yes, this package must be a zope.* package. > > Then we could move the ITerms interface to this package too rather > > then add a new one like zope.term. > > Could this package be called ``zope.browser`` then? +1 to this hot topic I like the idea to have a pure interface package for some basic (context, request) adatper components called views, browser pages or contentprovider etc. Regards Roger Ineichen > \malthe > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
Hi Sidnei > Betreff: Re: [Zope-dev] lxml and z3c.form strategy? > > What's the actual issue with lxml? It's not that hard to > compile it (I'm the person that compiles the official > releases), just a little bit under-documented. We started to use lxml in different z3c.* packages. The problem right now is that we need to ensure a stable release concept for lxml on windows. Are you doing future release for lxml? btw, are you using the Visual Studio or mingw compiler? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and lxml
On Tue, Sep 16, 2008 at 12:48 AM, Roger Ineichen <[EMAIL PROTECTED]> wrote: > Sidnei, > we or at least I as the second last windows user need > your help;-) > > We like to use lxml everywhere in z3c packages > because Malthe implemented a nice and fast PageTemplate > relacement in z3c.pt based on lxml. > > The problem right now is, that nobody compiles the > lxml binary eggs for windows. > > What do you think, can you do that important part? > And more important can you keep doing that in the future? Yes, I do compile the binary eggs. And yes, you can expect me to keep doing it in the future. It might take 2-3 weeks sometimes, but eventually I get around to it. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
What's the actual issue with lxml? It's not that hard to compile it (I'm the person that compiles the official releases), just a little bit under-documented. On Tue, Sep 16, 2008 at 12:29 AM, Roger Ineichen <[EMAIL PROTECTED]> wrote: > Malthe, Stephan > > I decided after along night, trying to compile > lxml on a windows box, that we will not use > lxml and lxml based packages like z3c.form, > z3c.template, z3c.macro etc at some of our > windows servers. > > We have to find a strategy to keep this packages > free of lxml and implement the z3c.pt support in > this packages in a different way. > > I really like your lxml based z3c.pt work. It's > nice and incredible fast. > > What do you think about that? > > I know it's a hugh amount of work, but I'm willing > to help with the refactoring if you like. > > > Regards > Roger Ineichen > _ > END OF MESSAGE > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>: > yes, this package must be a zope.* package. > Then we could move the ITerms interface to this > package too rather then add a new one like zope.term. Could this package be called ``zope.browser`` then? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
Hi Stephan > Betreff: Re: [Zope-dev] Interface for renderable component > > On Tuesday 16 September 2008, Malthe Borch wrote: > > 2008/9/16 Stephan Richter <[EMAIL PROTECTED]>: > > > Yeah, I like that. This is the right package, since it defines > > > high-level patterns without any heavy implementations. > > > > Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` > > because it implements a TALES expression and somehow, this package > > pulls in zope.app.*-packages. > > Darn. Let me think about that. I guess a new package to > collect our community-agreed high-level UI patterns would be > good then. > > From my point of view, it should include the following patterns: > > * update/render > > * generic IRenderer API (based on update/render!) Is the IRenderer interface not exactly the same like the IContentProvider? Does it provide an additional __call__ method? Or only __call__ method? It smells to me that we should name it to something like IProvider if it's a base for our IContentProvider or IXHTMLProvider if it provides XHTML based on z3c.pt I preferre anything with the word provider instead of renderer. > * Probably the concept of content providers > > The package should probably live int he zope.* namespace. > > Anything else? yes, this package must be a zope.* package. Then we could move the ITerms interface to this package too rather then add a new one like zope.term. > > I think we should work to never have zope.*-packages depend on > > zope.app.* ––– and perhaps declare a truce on minimizing > > dependencies within the zope.* group of packages (it seems > very difficult). > > I agree. > > Regards, > Stephan > -- > Stephan Richter > Web Software Design, Development and Training Google me. > "Zope Stephan Richter" > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>: > Are you thinking about a basic UI interface package. > where we probably define some interfaces e.g. > IBrowserPage and friends and nothing else? It really depends on how much we want to play with frameworks like repoze.bfg that do not want complete buy-in. > This whould offer a good base for any other UI > framework to provide the right interfaces for > their implementation. Interfaces like IContentProvider > could depend on such an interface too. And the ITerms > interface could also become a part of this package rather > then move to a zope.term package which we already agreed on. In Zope, there's a default implementation for most interfaces and this makes it easy to get started. The downside is that often times those implementation have a bunch of dependencies. But I don't think there's a way out of that. That's why I think we should simply try to get rid of zope.app.*-dependencies for starters and also try to move commonly used components/interfaces to base packages. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
Hi Malthe > Betreff: Re: [Zope-dev] Interface for renderable component > > 2008/9/16 Stephan Richter <[EMAIL PROTECTED]>: > > Yeah, I like that. This is the right package, since it defines > > high-level patterns without any heavy implementations. > > Unfortunately, ``zope.contentprovider`` relies on > ``zope.tales`` because it implements a TALES expression and > somehow, this package pulls in zope.app.*-packages. > > I think we should work to never have zope.*-packages depend on > zope.app.* --- and perhaps declare a truce on minimizing > dependencies within the zope.* group of packages (it seems > very difficult). zope.app.testing is only a test dependency. We have to replace such zope.app.testing dependencies in moste z3c.* package anyway. But first we need a better testing base for doing so. Are you thinking about a basic UI interface package. where we probably define some interfaces e.g. IBrowserPage and friends and nothing else? This whould offer a good base for any other UI framework to provide the right interfaces for their implementation. Interfaces like IContentProvider could depend on such an interface too. And the ITerms interface could also become a part of this package rather then move to a zope.term package which we already agreed on. Regards Roger Ineichen > \malthe > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
On Tuesday 16 September 2008, Tres Seaver wrote: > > I guess we have to figure out a clever way to make a special extra > > requires for Python 2.4, since elementtree and cElementTree are available > > in PyPI. > > Something like this in setup.py?: > > extra_requires = [] > import sys > if sys.version_info[0:2] < (2, 5): > extra_requires.append(...) Yeah, that should work. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
On Tuesday 16 September 2008, Malthe Borch wrote: > 2008/9/16 Stephan Richter <[EMAIL PROTECTED]>: > > Yeah, I like that. This is the right package, since it defines high-level > > patterns without any heavy implementations. > > Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` > because it implements a TALES expression and somehow, this package > pulls in zope.app.*-packages. Darn. Let me think about that. I guess a new package to collect our community-agreed high-level UI patterns would be good then. From my point of view, it should include the following patterns: * update/render * generic IRenderer API (based on update/render!) * Probably the concept of content providers The package should probably live int he zope.* namespace. Anything else? > I think we should work to never have zope.*-packages depend on > zope.app.* ––– and perhaps declare a truce on minimizing dependencies > within the zope.* group of packages (it seems very difficult). I agree. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Stephan Richter <[EMAIL PROTECTED]>: > Yeah, I like that. This is the right package, since it defines high-level > patterns without any heavy implementations. Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages. I think we should work to never have zope.*-packages depend on zope.app.* ––– and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems very difficult). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Tuesday 16 September 2008, Marius Gedminas wrote: >> Is that ElementTree that was only included from Python 2.5? In other >> words, z3c.pt + python2.4 - lxml = fail? > > I guess we have to figure out a clever way to make a special extra requires > for Python 2.4, since elementtree and cElementTree are available in PyPI. Something like this in setup.py?: extra_requires = [] import sys if sys.version_info[0:2] < (2, 5): extra_requires.append(...) Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIz+ky+gerLs4ltQ4RAm4pAKCTmb/ZjE3sGI8MedXfaS7Him4YZQCgxXni RjpGBYa3JXTmt0ERUx6zwdY= =2XYw -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
On Monday 15 September 2008, Roger Ineichen wrote: > Why not define a IHTMLProvider or someting like that > located in the zope.contentprovider package. Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
On Tuesday 16 September 2008, Marius Gedminas wrote: > Is that ElementTree that was only included from Python 2.5? In other > words, z3c.pt + python2.4 - lxml = fail? I guess we have to figure out a clever way to make a special extra requires for Python 2.4, since elementtree and cElementTree are available in PyPI. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
On Tue, Sep 16, 2008 at 03:29:13PM +0200, Malthe Borch wrote: > 2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>: > > That's fine for me. But the question is what happens on a > > production server. Does the missing lxml end in useing > > a slow fallback implementation or does it use the old > > style PageTempalte? > > Without lxml, it'll use ``xml.etree`` to parse the template and there > a few differences, most of which have been addressed at this point. Is that ElementTree that was only included from Python 2.5? In other words, z3c.pt + python2.4 - lxml = fail? Marius Gedminas -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>: > What is the reason why z3c.* packages should use z3c.pt and fallback > to a new concept rather then stay with PageTemplate if no lxml is > installed and z3c.pt is useless? There seems to be some confusion here, and I understand why this has arisen, but let me repeat what Chris also has mentioned: There's absolutely no trace of XML left after a template is compiled (not so for Genshi templates, but that's a different story). The *only* reason I opted for lxml is that it seemed to provide the best parsing functionality. However, ``xml.etree`` aka ElementTree seems to be a good candidate, too. > Is the fallback to xml.etree faster and then the old stable > PageTemplate implementation? See above. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
