[Zope-dev] can these wrong DEPENDENCIES.cfg files be removed?
We are working on zope.app.renderer and I see that there is a file named DEPENDENCIES.cfg that lists: docutils zope.app zope.component zope.configuration zope.interface zope.schema zope.structuredtext zope.testing while the actual package has a different list of dependencies: setuptools docutils zope.component zope.configuration zope.i18nmessageid zope.interface zope.publisher zope.schema zope.structuredtext [test] zope.app.testing What is the DEPENDENCIES.cfg file for, and why are the dependencies listed different than the current ones in setup.py? Can I just remove the redundant information in DEPENDENCIES.cfg and have the information in just one place instead? -- Brandon Craig Rhodes bran...@rhodesmill.org http://rhodesmill.org/brandon ___ 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] zope.component: calling an Interface and calling queryAdapter give differing results
Shane Hathaway [EMAIL PROTECTED] writes: Philipp von Weitershausen wrote: So overall I'm +1 +1 from me as well on IFoo.adapt() with the signature Chris suggested. zope.component.getMultiAdapter() is only easy to remember if you're a die-hard Zope coder, while IFoo.adapt() seems more useful to the larger Python community. A similar suggestion was hammered out last September; I guess September is the official month for the annual reconsideration of adaptation syntax? :-) http://mail.zope.org/pipermail/zope3-dev/2007-September/023824.html http://mail.zope.org/pipermail/zope3-dev/2007-September/023904.html http://mail.zope.org/pipermail/zope3-dev/2007-September/023907.html I'm encouraged by the fact that this time it looks like people with time are interested enough to actually begin producing code? At the time that I made the 2007 proposal I was still very new to the code base and never got the courage up (or time available) to start making changes... -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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] [zopeproject] ZODB3 specified, but ZODB3 3.9.0-dev-r77011 egg still attempted?!
Philipp von Weitershausen [EMAIL PROTECTED] writes: [versions] ZODB3 = 3.8.0 ... This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?! Because you're not doing it right. You invented a [versions] section but you still need to tell buildout to actually use that section as a versions declarations: [buildout] ... versions = versions Should we write something like Grok for buildout, so that it just uses sections without having to have them doubly declared up at the top? :-) -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] Re: could zope.sqlalchemy flush before committing?
Laurence Rowe [EMAIL PROTECTED] writes: This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released. Could the fix be backported and a new release made? I have to have this particular system ready for production next week, and would love to not have to explain why it was running out of Subversion in production. :-) -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] could zope.sqlalchemy flush before committing?
I complained recently about problems with things disappearing from an in-memory sqlite database. It appears that my problems were actually symptoms of something else: that, so far as I can see, doing a transaction.commit() when SQLAlchemy is active does *not* first do a session().commit()! This means that the following sequence in a test suite: p = Person(name='Brandon') s = session() s.add(p) transaction.commit() s.attribute = 'an illegal value' Traceback: ... Exception: the database does not allow that attribute to have that value transaction.rollback() Instead, to make this work, one has to write the first stanza as: p = Person(name='Brandon') s = session() s.add(p) s.flush() # Sheesh transaction.commit() Could zope.sqlalchemy be improved so that, on transaction commit, the current SQLAlchemy session is first flushed before being committed? -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] Re: could zope.sqlalchemy flush before committing?
Brandon Craig Rhodes [EMAIL PROTECTED] writes: I complained recently about problems with things disappearing from an in-memory sqlite database. It appears that my problems were actually symptoms of something else: that, so far as I can see, doing a transaction.commit() when SQLAlchemy is active does *not* first do a session().commit()! Drat. I meant, as I hope the code examples that followed made clear, that doing a transaction.commit() does not do a session().flush(). -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Malthe Borch [EMAIL PROTECTED] writes: On Vudo, the view is always a layout. It's then up to the layout to provide regions in which you can plug in a region content provider. Typically, you'd plug in at least the following: -- Title provider: Renders the title of the page (in title/title) -- Content provider: Renders the content of the page as widgets There are many more options to this scheme. You could plug in a portlet manager, or a viewlet manager or a global navigation. Someone mentioned Vudo to me last week. I said that I was tempted to write an extension to Grok that lets you create a grok.Layout template that maybe is inherited throughout your whole site if you don't specify otherwise, and then a grok.View on an object would just generate content for the main pane inside of that layout, and viewlets could keep working like they do today but fill in other parts of the layout. This is kind of how people look to be doing things today with the viewlets revolution that's going on in Grok land; look at: http://svn.zope.org/Grokstar/trunk/src/grokstar/blog.py?rev=87483view=auto and note how many of the grok.View objects are specifying the same dratted template, over and over again, and then rely on viewlets to actually fill in the varying parts of each page that change with the content. It struck me as a situation that is just crying out for a grok.Layout local utility that provides the template everywhere under a part of a site automatically, so that the grok.template(...) declaration does not have to get repeated so incessantly. It really looks to me like Grok best-practices are evolving towards a layout-centric, rather than a macro-centric, approach, and that something like the Vudo approach would make this all easier to manage. Do I sound on-target, or like I'm missing something? -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] can we teach official Zope to start detecting HTTPS header?
I'm told that, here at Georgia Tech, we are running our Plone's Zope
2.10 behind pound, and that we need some way to signal it about
which requests are coming in through http and which came through
https, so that all of the links generated by Plone can start with
the right protocol. So at the moment, users who type an https URL
so that they can edit documents and enjoy some privacy immediately get
kicked back to the http protocol the first time they click on a
link.
For an earlier version of our site, back on an earlier version of Zope
and Plone, we edited Zope so that it detected an HTTPS header, if
one was present, and allowed the value:
HTTPS: on
to change the protocol variable from HTTP to HTTPS. Then we told
pound to provide that header when an https request was made, and to
delete the header otherwise, and everything worked fine.
Would there be any chance of getting this change into Zope trunk
today, or is it too specific a need to be worth adding to the code
just for us folks using pound at Georgia Tech?
The patch, in the form in which we first wrote it back at the
beginning of 2007, is attached for the curious. Thanks for any feedback!
--- /usr/local/zope-2.9.5/lib/python/ZPublisher/HTTPRequest.py 2006-10-02 11:53:33.0 -0400
+++ /usr/local/zope-2.9.5/lib/python/ZPublisher/HTTPRequest.py 2007-01-03 18:20:35.0 -0500
@@ -294,6 +294,10 @@
if have_env('HTTPS') and (
environ['HTTPS'] == on or environ['HTTPS'] == ON):
protocol = 'https'
+elif have_env('HTTP_HTTPS') and (
+environ['HTTP_HTTPS'] == on or
+environ['HTTP_HTTPS'] == ON):
+protocol = 'https'
elif (have_env('SERVER_PORT_SECURE') and
environ['SERVER_PORT_SECURE'] == 1):
protocol = 'https'
--
Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon
___
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 )
