[Zope-dev] zope.publisher and ZPublisher: decoding form input
Hi! As discussed in a different thread, zope.publisher compatible decoding should be added to the ZPublisher. But does that code from zope.publisher make any sense? def _decode(self, text): Try to decode the text using one of the available charsets. if self.charsets is None: envadapter = IUserPreferredCharsets(self) self.charsets = envadapter.getPreferredCharsets() or ['utf-8'] for charset in self.charsets: try: text = unicode(text, charset) break except UnicodeError: pass return text Using getPreferredCharsets()[0] is correct because zope.publisher uses the same charset for encoding responses. (For ZPublisher we decided we don't want to support charset negotiation.) But what about the other charsets? AFAICS - There are no tests in zope.publisher for that fallback behavior. - That fallback behavior doesn't cause trouble because it is very rarely or never used. - The fact no error is raised by unicode(text, charset) doesn't mean we have the right charset. Here some background information: http://chardet.feedparser.org/docs/index.html - Returning the encoded strings if all attempts fail might not be the best choice. Proposal: Just use unicode(text, charset, 'replace') with the same charset used for encoding responses. If there are no objections, I'll implement it that way in ZPublisher. What about zope.publisher? I don't use zope.publisher, but I think it should always use 'utf-8' instead of trying to be smart. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.publisher release?
Would someone please add me (kteague) to the zope.publisher maintainers list on PyPI, or do a new zope.publisher release? I want to get the fix for the xml-rpc hang in Grok out there: https://bugs.launchpad.net/grok/+bug/332063 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.publisher
Hello, Someone please grant PYPI perm to me (agroszer) or do a release from svn://svn.zope.org/repos/main/zope.publisher/branches/3.4 -- Best regards, Adam GROSZER mailto:agros...@gmail.com -- Quote of the day: Nature gives man corn but he must grind it; God gives man a will but he must make the right choices. - Bishop Fulton J. Sheen ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher
On Tue, Apr 6, 2010 at 1:22 PM, Adam GROSZER agros...@gmail.com wrote: Hello, Someone please grant PYPI perm to me (agroszer) or do a release from svn://svn.zope.org/repos/main/zope.publisher/branches/3.4 Done. -- Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages
Jan-Wijbrand Kolman janwijbr...@gmail.com wrote: Martijn Faassen faas...@startifact.com wrote: 25 zope.app packages are broken due to changes in zope.publisher 3.12. zope.publisher had some components factored out of it into zope.login. I fixed zope.app.exception: it could be fixed by adding the zope.login requirement and adding a zcml include statement. I suspect most, probably all, other failures are similarly shallow. I just ran zope.app.exception's test and all pass. Thanks!! Do I understand correctly here that I can now release zope.app.exception too? Ah, I see you did already as 3.6.1. Thanks. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages
Martijn Faassen faas...@startifact.com wrote: 25 zope.app packages are broken due to changes in zope.publisher 3.12. zope.publisher had some components factored out of it into zope.login. I fixed zope.app.exception: it could be fixed by adding the zope.login requirement and adding a zcml include statement. I suspect most, probably all, other failures are similarly shallow. I just ran zope.app.exception's test and all pass. Thanks!! Do I understand correctly here that I can now release zope.app.exception too? regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, 25 zope.app packages are broken due to changes in zope.publisher 3.12. zope.publisher had some components factored out of it into zope.login. I fixed zope.app.exception: it could be fixed by adding the zope.login requirement and adding a zcml include statement. I suspect most, probably all, other failures are similarly shallow. The breaking of so many packages wasn't noticed by anyone, until tests of svn checkouts that previously worked now broke. I hope we can put mechanisms in place so that developers of ZTK packages can be better made aware of breaking other packages that depend on the ZTK. This way the developer making the changes could do one or more of the following: * provide better backward compatibility * fix up the breaking packages * provide a better warning to others who are maintaining these packages that something was broken. I faintly, faintly recall we had such early-warning mechanisms in the past. :) AFAIK, the zope-tests list is the watchman on the battlements: seeing something break in its daily summary mail is usually the first warning I have that a checkin broke something. I would be glad to see other configurations sending their test results to that list, so that everybody gets notified about breakage. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD2X8ACgkQ+gerLs4ltQ4GOgCgqY4rrDVeio/TWp+/mzYWf4tH 1V4An0PeTUvwXOE7H0ii9HFbeyQa2AO7 =tkPS -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.publisher 3.12 broke 25 zope.app packages
Hi there, 25 zope.app packages are broken due to changes in zope.publisher 3.12. zope.publisher had some components factored out of it into zope.login. I fixed zope.app.exception: it could be fixed by adding the zope.login requirement and adding a zcml include statement. I suspect most, probably all, other failures are similarly shallow. The breaking of so many packages wasn't noticed by anyone, until tests of svn checkouts that previously worked now broke. I hope we can put mechanisms in place so that developers of ZTK packages can be better made aware of breaking other packages that depend on the ZTK. This way the developer making the changes could do one or more of the following: * provide better backward compatibility * fix up the breaking packages * provide a better warning to others who are maintaining these packages that something was broken. I faintly, faintly recall we had such early-warning mechanisms in the past. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages
Hanno Schlichting wrote: On Mon, Jan 4, 2010 at 11:51 PM, Martijn Faassen faas...@startifact.com wrote: Good news, it was only 24 packages, I counted wrong. :) Couldn't you have solved that by updating one underlying package, like zope.app.testing? Most of zope.app generally depends on things like app.testing, app.zcmlfiles or things like app.publsher. You're probably right - I am not really thinking straight today. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Gary Betreff: Re: AW: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Ah, this sounds good. We often use query string urls for simulate a post request e.g. foo.html?form.action.remove=1id=123 which forces to process the button action in z3c.form within a value 123 for the id field etc. I was afraid that this isn't working anymore if such query values will not longer work as request.form key/values But as far as I understand it's only a problem with POST and query strings and does not affect the above usecase. Maybe http://bugs.python.org/issue1817 gives you the information you want? Thanks a lot Roger Ineichen Gary ___ 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.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
Hi Tres
I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
unimportant to this email (I backported a change to trunk that was
discussed on the mailing list). It looks like you made a 3.5.7 with
the following change (omitting tests and the like).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver env['X-POST-QUERY_STRING'] =
env.pop('QUERY_STRING')
I can handle adjusting to this change, if it is appropriate, but my
concern is that it is not in trunk or any subsequent major release
(3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
to use my updated 3.5 release, which I had hoped would be a
conservative update, I have to change in a currently forward-
incompatible way.
What's the story here? Is 3.5.7 a brownbag that needs to have its
changes aborted in a subsequent release in that branch? Or are
those legitimate changes that need to be forward ported?
FWIW, we (Launchpad) also care about this case of a POST with other
pertinent, separate data in the query string, and the behavior you
implement here would be fine if it is necessary for Py 2.6 as your
comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string. I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access to
the query string on the request object, whether the method were get or
post or whatever else.
Gary
___
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.publisher 3.5 branch has code/behavior not a part of subsequent releases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
Hi Tres
I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
unimportant to this email (I backported a change to trunk that was
discussed on the mailing list). It looks like you made a 3.5.7 with
the following change (omitting tests and the like).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver env['X-POST-QUERY_STRING'] =
env.pop('QUERY_STRING')
I can handle adjusting to this change, if it is appropriate, but my
concern is that it is not in trunk or any subsequent major release
(3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
to use my updated 3.5 release, which I had hoped would be a
conservative update, I have to change in a currently forward-
incompatible way.
What's the story here? Is 3.5.7 a brownbag that needs to have its
changes aborted in a subsequent release in that branch? Or are
those legitimate changes that need to be forward ported?
FWIW, we (Launchpad) also care about this case of a POST with other
pertinent, separate data in the query string, and the behavior you
implement here would be fine if it is necessary for Py 2.6 as your
comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string. I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access to
the query string on the request object, whether the method were get or
post or whatever else.
It is *essential* for correct operation that QUERY_STRING values *not*
be admixed with POSTed form values. I don't really care how we resolve
your issue, as long as we do not end up in a case where the values in
the query string get mingled into the form data: for instance, we could
hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage
machinery.
Whatever gets done needs to leave the existing test in place::
self.assertEqual(dict(request.form), dict(x='1', y='2'))
for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the
'x' and 'y' values.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKkwXA+gerLs4ltQ4RAhVKAKDY5LuTUshFf1ihKTQXpJjyxvIeeACglpu8
FZSMcnQjaiOyax9ziOAlFNE=
=qJS/
-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] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKkwXA+gerLs4ltQ4RAhVKAKDY5LuTUshFf1ihKTQXpJjyxvIeeACglpu8 FZSMcnQjaiOyax9ziOAlFNE= =qJS/ -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 ) ___ 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.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 5:27 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
Hi Tres
I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
unimportant to this email (I backported a change to trunk that was
discussed on the mailing list). It looks like you made a 3.5.7 with
the following change (omitting tests and the like).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver env['X-POST-QUERY_STRING'] =
env.pop('QUERY_STRING')
I can handle adjusting to this change, if it is appropriate, but my
concern is that it is not in trunk or any subsequent major release
(3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
to use my updated 3.5 release, which I had hoped would be a
conservative update, I have to change in a currently forward-
incompatible way.
What's the story here? Is 3.5.7 a brownbag that needs to have its
changes aborted in a subsequent release in that branch? Or are
those legitimate changes that need to be forward ported?
FWIW, we (Launchpad) also care about this case of a POST with other
pertinent, separate data in the query string, and the behavior you
implement here would be fine if it is necessary for Py 2.6 as your
comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string.
I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access
to
the query string on the request object, whether the method were get
or
post or whatever else.
It is *essential* for correct operation that QUERY_STRING values *not*
be admixed with POSTed form values. I don't really care how we
resolve
your issue, as long as we do not end up in a case where the values in
the query string get mingled into the form data: for instance, we
could
hand a QUERY_STRING-free copy of the environment to the
cgi.FieldStorage
machinery.
Whatever gets done needs to leave the existing test in place::
self.assertEqual(dict(request.form), dict(x='1', y='2'))
for a request whose QUERY_STRING was 'a=5b:int=6', but which posted
the
'x' and 'y' values.
I'm good with that.
My additional constraint would be that
self.assertEqual(request.get('QUERY_STRING'), 'a=5b:int=6')
for the same request. Hiding the QUERY_STRING causes us some
unpleasant and subtle functional test pain.
Passing a QUERY_STRING-free copy to cgi.FieldStorage as you suggest
seems like a good way to go to me.
Unless someone beats me to it or stops me, I'll plan to make this go
in trunk and in the 3.5 branch, and make a 3.5.9 release.
(If someone *were* to beat me to it, that would be awesome. I'm kinda
swamped.)
Thanks
Gary
___
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.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Maybe http://bugs.python.org/issue1817 gives you the information you want? Gary ___ 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.publisher dependencies
On Mar 6, 2009, at 2:18 AM, Shane Hathaway wrote: Jim Fulton wrote: - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. I hope you're not asking me to write documentation for zope.publisher :-), I wasn't asking you to do anything. :) because I only understand the mechanics. The overall scope and purpose is cloudy to me. In particular, I don't understand how the publication interface is actually generic. Does it fit the needs of anything other than Zope? I believe so. I think there are enough hooks there for pretty much any application. A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) FWIW, that particular functionality has been pulled out twice now, both in repoze.monty and zope.httpform. As a baby step, we could make zope.publisher depend on zope.httpform. (I made zope.httpform without knowing repoze.monty already existed, but zope.httpform has more tests and interfaces and it's hosted on svn.zope.org, so I think zope.httpform is worth keeping.) I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I'd also like to use or be compatible with WebOb on that. I'd prefer to do this at PyCon where I'll have time to pay attention and where there will be higher bandwidth communication. I'm sympathetic to Martijn's desire not to slow you down, it's not clear to me why you need changes to zope.publisher. If it's just a matter of reducing dependencies, I don't think that's a blocker for any work you might want to do. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
Jim Fulton wrote: I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I'd also like to use or be compatible with WebOb on that. I'd prefer to do this at PyCon where I'll have time to pay attention and where there will be higher bandwidth communication. I look forward to PyCon! :-) Shane ___ 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] zope.publisher uses deprecated IView
Hello, since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? Wolfgang -- Wolfgang Schnerring · w...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.publisher uses deprecated IView
Hey, Wolfgang Schnerring wrote: since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? I actually remember running into this many many years ago and got so confused I gave up on it then. :) Hopefully someone else can tell you more! Something is definitely funky in here. I wonder what happens to our compattests if we simply remove this inheritance relationship. If nothing directly refers to IView it might mean everything will still work... Regards, Martijn ___ 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.publisher dependencies
Hey, Jim Fulton wrote: [snip] I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I had the impression Shane was doing that; i.e. building zope.pipeline factoring bits out of the publisher but not really changing the publisher very much itself, creating a new structure instead. Shane, is that correct? I'd also like to use or be compatible with WebOb on that. I'd prefer to do this at PyCon where I'll have time to pay attention and where there will be higher bandwidth communication. +1 on the WebOb compatibility. I imagine it should be possible to reconstruct our request and response interfaces on top of WebOb's. We should also think of ways so that code can get the WebOb request directly instead of having to go through these adapters. I'd also be much in favor of reusing WebOb's implementation, not just the APIs. I think it could help us replace part of the publisher. I'm sympathetic to Martijn's desire not to slow you down, it's not clear to me why you need changes to zope.publisher. If it's just a matter of reducing dependencies, I don't think that's a blocker for any work you might want to do. Thanks. I'm very much in favor of you guys talking at PyCon if that's the best way to make progress. I'm also looking forward to seeing Shane again at PyCon after meeting him so briefly all these years ago when I was still young and nimble. So I'm glad to hear he's going to make it! I'm also happy I'll get to see you again as well! Regards, Martijn ___ 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.publisher dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Jim Fulton wrote: - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. I hope you're not asking me to write documentation for zope.publisher :-), because I only understand the mechanics. The overall scope and purpose is cloudy to me. In particular, I don't understand how the publication interface is actually generic. Does it fit the needs of anything other than Zope? A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) FWIW, that particular functionality has been pulled out twice now, both in repoze.monty and zope.httpform. As a baby step, we could make zope.publisher depend on zope.httpform. (I made zope.httpform without knowing repoze.monty already existed, but zope.httpform has more tests and interfaces and it's hosted on svn.zope.org, so I think zope.httpform is worth keeping.) Yup. repoze.monty should become just a BBB wrapper. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUNS+gerLs4ltQ4RAlsAAKCQNH3YTAb4NjDq4VOW/ZxU6/pQLgCgzGBW pMIHEqDDxxUno1GdRRx3sEw= =E5aV -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] zope.publisher uses deprecated IView
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Wolfgang Schnerring wrote: since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? I actually remember running into this many many years ago and got so confused I gave up on it then. :) Hopefully someone else can tell you more! Something is definitely funky in here. I wonder what happens to our compattests if we simply remove this inheritance relationship. If nothing directly refers to IView it might mean everything will still work... I just undeprecated IView and the other 'bbb' interfaces for exactly this reason: if core packages still use them five years later, then the deprecation loses. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUkc+gerLs4ltQ4RAuNxAJwK+mWmEesGrBEBDRGAbVRmmjJ2kACeONam pIs6yQadsfbwT/n5XFcwC+4= =C8ps -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] zope.publisher dependencies
Martijn Faassen wrote: Jim Fulton wrote: [snip] I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I had the impression Shane was doing that; i.e. building zope.pipeline factoring bits out of the publisher but not really changing the publisher very much itself, creating a new structure instead. Shane, is that correct? Yes. I think Jim and I are saying the same thing there. The current code in zope.pipeline doesn't reflect that thinking, though, because we really need to divide zope.publisher somehow before a project like this makes sense. +1 on the WebOb compatibility. I imagine it should be possible to reconstruct our request and response interfaces on top of WebOb's. We should also think of ways so that code can get the WebOb request directly instead of having to go through these adapters. I'd also be much in favor of reusing WebOb's implementation, not just the APIs. I think it could help us replace part of the publisher. That should be a great thing to work on in a sprint. Thanks. I'm very much in favor of you guys talking at PyCon if that's the best way to make progress. I'm also looking forward to seeing Shane again at PyCon after meeting him so briefly all these years ago when I was still young and nimble. So I'm glad to hear he's going to make it! I'm also happy I'll get to see you again as well! I'll be the one who arrives Monday afternoon without much hair on top. :-) Shane ___ 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.publisher uses deprecated IView
2009/3/6 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Wolfgang Schnerring wrote: since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? I actually remember running into this many many years ago and got so confused I gave up on it then. :) Hopefully someone else can tell you more! Something is definitely funky in here. I wonder what happens to our compattests if we simply remove this inheritance relationship. If nothing directly refers to IView it might mean everything will still work... I just undeprecated IView and the other 'bbb' interfaces for exactly this reason: if core packages still use them five years later, then the deprecation loses. I doubt that the IView and (especially) IPresentation/IContextDependent are actually imported/used anywhere directly. Especially when they were deprecated for years. So I'm +10 on simply removing the inheritance and that BBB interfaces themselves, as they only create confusion when someone tries to find out what those interfaces constist of. As for others, I bet IResource could be safely moved into zope.app.publisher and the IDefaultViewName - to zope.publisher to make company for IDefaultSkin. :) As for IViewFactory/IResourceFactory - they are not used by zope. For example, the BrowserView and BrowserPage classes don't provide those interfaces. So I propose to simply remove them. -- WBR, Dan Korostelev ___ 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.publisher uses deprecated IView
Dan Korostelev wrote: 2009/3/6 Tres Seaver tsea...@palladion.com: [snip] I just undeprecated IView and the other 'bbb' interfaces for exactly this reason: if core packages still use them five years later, then the deprecation loses. I doubt that the IView and (especially) IPresentation/IContextDependent are actually imported/used anywhere directly. Especially when they were deprecated for years. So I'm +10 on simply removing the inheritance and that BBB interfaces themselves, as they only create confusion when someone tries to find out what those interfaces constist of. I'd definitely be in favor of trying this instead of undeprecating them. zope.component has no business knowing about views and such. Regards, Martijn ___ 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.publisher uses deprecated IView
On Friday 06 March 2009, Martijn Faassen wrote: I'd definitely be in favor of trying this instead of undeprecating them. zope.component has no business knowing about views and such. +1 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] zope.publisher
Shane Hathaway wrote: Roger Ineichen wrote: Shane, Can you review and merge this changes into your zope.pipeline branch? I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and I need to discuss it in person; hopefully then I can understand his opposition and the group can decide on the best direction for zope.publisher and zope.app.publication. You should certainly talk to Jim if you think it will help you. But do note that Jim cannot be blocking your work anymore with a veto. In order to get this to be part of the Zope Framework, you'd need to convince the Zope Framework Steering Group, not Jim. I do think it's extremely bad if Jim's opposition can block all of your work on this project, which you were quite enthusiastic about before, for a whole month! This is exactly the sort of situation we want to avoid under our new system. As a Zope Framework Steering Group member I am quite supportive of your work, as reading your code already I have a much better sense of what's going on than I ever did with the standard publishing stack, so you got 1 out of 3 on board already. Regards, Martijn ___ 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.publisher
Hi Martijn Betreff: Re: [Zope-dev] zope.publisher Roger Ineichen wrote: Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. As long as zope.publisher's configure.zcml does it, Grok will load that up. Grok isn't different in that respect; it only uses Grok-style registration in packages that explicitly use grok or grokcore.* libraries. It's quite possible Grok can start using some of your changes for its REST skin implementation (which do apply to IBrowserRequest), though I'm not 100% sure. of corse, all changes are 100% compatible. The changes allow you to inherit from IHTTPRequest instead of IBrowserRequest and support a IDefaultSkin. The previous implementation required that the default skin pattern uses an IBrowserRequest. REST does normaly depend on IBrowserRequest but JSON-RPC doesn't have to, or you will get all the IBrwoserRequest parts in JSON-RPC too which is not good. Also XML-RPC has to be inherited from IHTTPRequest and not how it is right now from IBrowserRequest. XML-RPC should also allow to use it's own default skin and not depend on the IBrowserRequest default skin implementation. e.g. we do really not need a contents.html page in XML-RPC skins. But that's another (security) topic which we can discuss at a later time. I'm trying to understand why the default default skin cannot be registered as an interface, instead of the introduction of an adapter. Is this because defaultSkin can only be used for IBrowserRequest? Because it's not an adapter. It's doens't provide what it should provide and is registered for. The following will end in a TypeError: request BrowserRequest() defautlSkin = IDefaultskin(request) TypeError ... but it should return: IDefaultBrowserLayer Another side effect is that we get pickled interfaces in the adapter registry. That really hurts if someone does the same in a local (persistent) adapter registry and the interface get removed. The question is, should we allow to register such *junk* in the zope adapter registry? I think you need to update the upgrade notes in zope3docs too to point out this change. If there is anything people should change to their code, you need to explain how to find what needs to be changed and what change to make. You need to at least warn them that something big changed if they get problems with their skins and point them to zope.publisher's changelog. will do so soon I'll also note that this is *not* a minor bugfix release of zope.publisher, so it should be 3.6 not 3.5.7. Also don't use 'dev' markers in CHANGES.txt; only in setup.py. agreed Regards Roger Ineichen Regards, Martijn ___ 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 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.publisher dependencies
Jim Fulton wrote: - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. I hope you're not asking me to write documentation for zope.publisher :-), because I only understand the mechanics. The overall scope and purpose is cloudy to me. In particular, I don't understand how the publication interface is actually generic. Does it fit the needs of anything other than Zope? A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) FWIW, that particular functionality has been pulled out twice now, both in repoze.monty and zope.httpform. As a baby step, we could make zope.publisher depend on zope.httpform. (I made zope.httpform without knowing repoze.monty already existed, but zope.httpform has more tests and interfaces and it's hosted on svn.zope.org, so I think zope.httpform is worth keeping.) Shane ___ 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] zope.publisher
Hi Martijn, Shane I fixed some issues in zope.publisher and at the same time I implemented the default skin pattern within an adapter pattern. The adapter getDefaultSkin in zope.publisher.browser.py is registered in configure.zcml The changes are compatible within the zope core but only if zmcl is used. The concept is the following A request implementation can provide a named IDefaultSkin adapter within the name default. This default skin get used if no other default skin get defined. The IDefaultBrowserLayer is used as such a default adapter for IBrowserRequest. This was done hardcoded in setDefaultSkin before my changes. A default skin in your own projects get registered as an unnamed IDefaultSkin adapter. This is normaly done within the defaultSkin ZCML directive. Such a unnamed adapter get used before the setDefaultSkin method will lookup for the *fallback* named adapter. Everything is 100% compatible if the adapter configuration get used in configure.zcml. Questions - Everbody, Right now the setDefaultSkin method will silently fail if a skin doesn't provide ISkinType. What do you think should we raise an exception instead of silently ignore the skin? A general problem in the implemenation before and after my changes is that the skin interfaces registered by the defaultSkin ZCMl directive will register the interface as adapter which is not adaptable because it's not an adapter factory. Should we change the defaultSkin directive and register an adapter factory? This whould ensure that we don't have junk in the dapter registry. Another question The applySkin method removes all skin types from the request. Why do we not remove all skin types in setDefaultLayer? Are there any skins applied at the time we call setDefaultSkin? Martijn, Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. Shane, Can you review and merge this changes into your zope.pipeline branch? 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 )
Re: [Zope-dev] zope.publisher
Roger Ineichen wrote: Shane, Can you review and merge this changes into your zope.pipeline branch? I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and I need to discuss it in person; hopefully then I can understand his opposition and the group can decide on the best direction for zope.publisher and zope.app.publication. Shane ___ 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.publisher dependencies
On Feb 24, 2009, at 12:59 PM, Shane Hathaway wrote: Jim Fulton wrote: I disagree strongly with many of the assertions made in these articles. (I can't judge the pipeline proposal, since it is only fleshed out in code.) While I do think zope.publisher has some problems, they aren't the same problems that shane sees. What are the problems with zope.publisher as you see it? - It has too many dependencies. Obviously. - It has too much in it. This contributes to the large number of dependencies. - I think the attempt to support multiple protocols through different request types has turned out to be a mistake. I think it was a reasonable approach to try, but I don't think it turned out well, in part because it seems too heavy. Last year, I implemented some Ajax support framework without anything like the complexity that's in the xml-rpc support. I did end up defining a new request marker type to facilitate component lookup, but I was able to do this in a very light- weight way. - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
On Wed, Feb 25, 2009 at 08:46, Baiju M mba...@zeomega.net wrote: This will not make any change in dependency graph unless zope.location become a namespace package. Yeah, that was what I was thinking, but I just realized that it might be tricky to have both a zope.location and a zope.location.interfaces. I haven't tried. Anyway, it was just an idea. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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.publisher dependencies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
One simple, low-risk refactoring I would like to do is move
zope.publisher.interfaces into its own package, make zope.publisher a
namespace package, and make zope.publisher depend on
zope.publisher.interfaces. The __init__.py in zope.publisher is already
empty, so I expect the namespace conversion to be safe. Then I'd like
to refine the dependency list of various packages that only require
zope.publisher.interfaces. Any objections?
+1.
It is less clear what we should do with BrowserView and BrowserPage.
They depend on zope.location, unlike the rest of zope.publisher, so they
don't really fit there. Perhaps those two belong in a new package,
zope.publisher.browserbase. There is also the tiny new zope.browser
package. Would it make sense to move them there? (It's hard to tell
what the intent of the new package is.) I'd love to hear other suggestions.
zope.browser is supposed to be a zero-dependency spot for commonly-used
interfaces:
This package provides shared zope browser components without other
dependencies.
So I wouldn't move anything depending on zope.location into that
package. Your new package idea sounds better.
As for TestRequest, I could update the setup.py of various packages that
currently depend on zope.publisher just for TestRequest. I would make
zope.publisher a test-only requirement.
Frankly, any code using a testing stub which is that heavyweight needs
to be refactored.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJpAOY+gerLs4ltQ4RAjp/AJ9sbBrxvOrWkjFuypP7/16n75uUkwCgvtZW
3J0s+vDo0p1nxkxhtrFbS/A=
=FUZq
-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] zope.publisher dependencies
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
Can you elaborate on this a bit?
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
Jim
--
Jim Fulton
Zope Corporation
___
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.publisher dependencies
On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote: ... As for TestRequest, I could update the setup.py of various packages that currently depend on zope.publisher just for TestRequest. I would make zope.publisher a test-only requirement. Frankly, any code using a testing stub which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
On Tuesday 24 February 2009, Shane Hathaway wrote:
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
Can you give examples?
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
Packages that depend on those classes usually more or less implicitly depend
on zope.publisher. So the split might be arbitrary for this example.
One simple, low-risk refactoring I would like to do is move
zope.publisher.interfaces into its own package, make zope.publisher a
namespace package, and make zope.publisher depend on
zope.publisher.interfaces. The __init__.py in zope.publisher is already
empty, so I expect the namespace conversion to be safe. Then I'd like
to refine the dependency list of various packages that only require
zope.publisher.interfaces. Any objections?
I want to see some motivation, because I fail to see how this helps.
It is less clear what we should do with BrowserView and BrowserPage.
They depend on zope.location, unlike the rest of zope.publisher, so they
don't really fit there. Perhaps those two belong in a new package,
zope.publisher.browserbase.
I do agree moving BrowserView and BrowserPage out of the publisher because
they introduce the zope.location dependency.
There is also the tiny new zope.browser
package. Would it make sense to move them there? (It's hard to tell
what the intent of the new package is.) I'd love to hear other
suggestions.
I think the purpose of the package is still defining itself. I think it will
be defined by the things that we move into it. I am very tempted to say that
it is a good home for BrowserView and BrowserPage.
As for TestRequest, I could update the setup.py of various packages that
currently depend on zope.publisher just for TestRequest. I would make
zope.publisher a test-only requirement.
TestRequest does not add any additional dependencies to the system, so what's
the point? It will depend on zope.publisher.browser anyways.
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] zope.publisher dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote: ... As for TestRequest, I could update the setup.py of various packages that currently depend on zope.publisher just for TestRequest. I would make zope.publisher a test-only requirement. Frankly, any code using a testing stub which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. - - It derives from BrowserRequest, which means carrying along a *lot* of extra implementation baggage. Tests which use this class, rather than stubbing out a dummy request which provides only the API required by the application-under-test, will tend to grow unexpected / undesirable tentacles to the request implementation. - - Using TestRequest involves pulling in all of zope.publisher, a *big* dependency; Shane wants to reduce such dependencies. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpBxw+gerLs4ltQ4RAosKAKDNmJoShgxtFrhi3rVFYqa3H+ncVACgmGU8 TOcde0xx65K1KeIopuy3hpk= =/+UR -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] zope.publisher dependencies
Hey Shane, +1 on separating out zope.publisher.interfaces, as it seems low-hanging fruit. Shane Hathaway wrote: It is less clear what we should do with BrowserView and BrowserPage. They depend on zope.location, unlike the rest of zope.publisher, so they don't really fit there. Perhaps those two belong in a new package, zope.publisher.browserbase. There is also the tiny new zope.browser package. Would it make sense to move them there? (It's hard to tell what the intent of the new package is.) I'd love to hear other suggestions. Perhaps zope.browser is the most straightforward location, especially given the names of the views involved. Even if zope.browser has unclear intent now it'll gain more clear intent from this. That said, zope.browser currently doesn't depend on zope.location and it would need to gain this as a dependency. As for TestRequest, I could update the setup.py of various packages that currently depend on zope.publisher just for TestRequest. I would make zope.publisher a test-only requirement. I would prefer if we could make TestRequest also go somewhere else (zope.browser?) instead of making zope.publisher a test-only requirement. While that step would be an improvement, I think the greater improvement would be to find a way to reduce test-only requirements. Regards, Martijn ___ 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.publisher dependencies
Jim Fulton wrote:
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
Can you elaborate on this a bit?
He has, though perhaps not in an obvious place for you:
http://shane.willowrise.com/archives/repozublisher/
http://shane.willowrise.com/archives/redesign-of-zopepublisher/
http://shane.willowrise.com/archives/zopepipeline/
http://shane.willowrise.com/archives/limits-of-zopepipeline/
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
Shane, how integrated is code that relies on the pieces in
zope.publisher you identified into their own packages? I have the
impression it'll be much harder to go that way than factor bits out of
zope.publisher instead. Especially as zope.publisher contains stuff that
Shane has no use for with zope.pipeline, and we'd still be pulling it in
if we didn't do the refactoring.
We got two kinds of browser-based code we should distinguish between:
* ZMI code
* framework code that supports the browser
To get rid of ZMI code, a pattern that works fairly well is to refactor
everything *else* out of the package and leave the ZMI code in its
original location, with backwards compatibility imports in place.
zope.app.* packages frequently can get this kind of treatment.
Other framework code that supports the browser is much like any other
framework code. Some packages need to be aware of the browser in order
to perform their role as framework component at all. If those packages
can rely on *less* code that would be an improvement.
I'm not very much in favor of making these sub-packages of
zope.publisher though, as to me a sub-package structure tends to make an
implication that it relies on the outer package, which in this case it
doesn't. I'd rather see zope.browser take this role. Perhaps the current
zope.browser package doesn't have the right name?
Regards,
Martijn
___
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.publisher dependencies
On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote: ... As for TestRequest, I could update the setup.py of various packages that currently depend on zope.publisher just for TestRequest. I would make zope.publisher a test-only requirement. Frankly, any code using a testing stub which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. - - It derives from BrowserRequest, which means carrying along a *lot* of extra implementation baggage. Tests which use this class, rather than stubbing out a dummy request which provides only the API required by the application-under-test, will tend to grow unexpected / undesirable tentacles to the request implementation. - - Using TestRequest involves pulling in all of zope.publisher, a *big* dependency; Shane wants to reduce such dependencies. OK, I don't agree that zope.publisher is a big dependency, especially for code that is meant to run in the context of it. Any view (or resource) code, which is the only code who's tests would need zope.publisher, will be used in together with zope.publisher in practice. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
On Tuesday 24 February 2009, Jim Fulton wrote: - - Using TestRequest involves pulling in all of zope.publisher, a *big* dependency; Shane wants to reduce such dependencies. OK, I don't agree that zope.publisher is a big dependency, especially for code that is meant to run in the context of it. Any view (or resource) code, which is the only code who's tests would need zope.publisher, will be used in together with zope.publisher in practice. Yep, 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] zope.publisher dependencies
On Tuesday 24 February 2009, Martijn Faassen wrote: Packages that depend on those classes usually more or less implicitly depend on zope.publisher. So the split might be arbitrary for this example. My understanding is that Shane is working on an alternative publisher, zope.pipeline, that doesn't need this other code. Is that correct, Shane? I see. He only needs the interfaces, so that he can write compatible code. And he is doing some rest-like stuff, so he does not need browser. I would only factor out the browser code, if it introduces additional dependencies. In general I am worried that we are creating too many packages. However, here is my order of importance: 1. Minimize dependencies. 2. Minimize packages. 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] zope.publisher dependencies
Jim Fulton wrote: On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote: - - Using TestRequest involves pulling in all of zope.publisher, a *big* dependency; Shane wants to reduce such dependencies. OK, I don't agree that zope.publisher is a big dependency, especially for code that is meant to run in the context of it. I think it's a very subjective and relative measure. Some people call 15 packages a very big dependency. Some measure it in terms of actual features you get and think it's small. Hanno P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) ___ 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.publisher dependencies
On Feb 24, 2009, at 11:46 AM, Martijn Faassen wrote: Jim Fulton wrote: On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote: I've been working on the dependencies to and from zope.publisher. Refining the dependencies should make it easier to integrate zope.pipeline when it's ready. Can you elaborate on this a bit? He has, though perhaps not in an obvious place for you: http://shane.willowrise.com/archives/repozublisher/ http://shane.willowrise.com/archives/redesign-of-zopepublisher/ http://shane.willowrise.com/archives/zopepipeline/ I disagree strongly with many of the assertions made in these articles. (I can't judge the pipeline proposal, since it is only fleshed out in code.) While I do think zope.publisher has some problems, they aren't the same problems that shane sees. ... I'd like to turn this around a little bit. Only browser-based code should depend on zope.publisher. This seems like a very reasonable dependency. It's like wxwindows UI code depending on wxwindows. Maybe the browser code should be factored out of the packages that depend on zoep.publisher so that only *that* code has the dependency and non-browser code doesn't. Shane, how integrated is code that relies on the pieces in zope.publisher you identified into their own packages? I have the impression it'll be much harder to go that way than factor bits out of zope.publisher instead. I'd like to see see some specific examples. In general, in Zope 3, we've advocated a separation of model and application code from presentation code. Presentation code is going to depend on whatever presentation framework it uses. Especially as zope.publisher contains stuff that Shane has no use for with zope.pipeline, and we'd still be pulling it in if we didn't do the refactoring. I'm not sure why this matters. BTW, I suspect we're more concerned about odd dependencies *of* zope.publisher, like zope.location. It might be better to focus on some of those. I'd also be in favor of separating out less central parts, like support for xml-rpc. We got two kinds of browser-based code we should distinguish between: * ZMI code There shouldn't be anything in zope.publisher that depends on the ZMI. * framework code that supports the browser To get rid of ZMI code, a pattern that works fairly well is to refactor everything *else* out of the package and leave the ZMI code in its original location, with backwards compatibility imports in place. zope.app.* packages frequently can get this kind of treatment. Other framework code that supports the browser is much like any other framework code. Some packages need to be aware of the browser in order to perform their role as framework component at all. If those packages can rely on *less* code that would be an improvement. I'm not sure what you're saying. If an application package has presentation code mixed into it and if there is a desire to use that application code in a context without presentation, I'd separate the presentation code from the application code. The presentation code would depend on zope.publisher. The application code wouldn't. I'm not very much in favor of making these sub-packages of zope.publisher though, as to me a sub-package structure tends to make an implication that it relies on the outer package, which in this case it doesn't. I'd rather see zope.browser take this role. Perhaps the current zope.browser package doesn't have the right name? I don't know what you mean by these above. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
Jim Fulton wrote:
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
Can you elaborate on this a bit?
I've been discussing zope.pipeline on my blog. I am attempting to
rebuild the publisher to make it easier to understand and customize. I
think it's working out pretty well. zope.pipeline is intended to
replace most of the implementation code in zope.publisher and
zope.app.publication.
To accomplish that, it looks like I ought to separate the
implementations in zope.publisher from the specifications. Separating
the zope.publisher.interfaces package would mostly accomplish that.
After thinking this over last night, I realize that the idea to move
BrowserView, BrowserPage, and TestRequest is driven by the desire to
clarify the dependency graph. That's more complex than what I'm trying
to do and I don't think I need to do that for zope.pipeline, so I'm
going to withdraw from that part of the discussion for now.
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
I think things are already pretty well factored in that sense. Take
zope.formlib, for example. It wouldn't make sense to separate
zope.formlib into an abstract package and a browser package, because
zope.formlib only makes sense for browsers.
Shane
___
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.publisher dependencies
Hey, On Tue, Feb 24, 2009 at 6:33 PM, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: In general I am worried that we are creating too many packages. However, here is my order of importance: 1. Minimize dependencies. 2. Minimize packages. +1 I think on the longer term better dependencies can allow us to remove a great number of packages from the Zope Framework, so I'm not too worried about the minimization of packages right now. To properly reduce dependencies you need to go about it in an intelligent way anyway and do some actual analysis of code, so the new packages that are created tend to make sense. Fundamental goals should be: * Make the code more comprehensible * Make the code more reusable The dependency refactoring is not only an effort to make the dependencies between packages a nicer tree (and thus encourage reuse of more packages and easier understandability), but also results in trees that have less code altogether. I think the last point is very important. Less code might not be reflected directly in the amount of packages, but is a huge win anyway. Less code makes the code that remains typically far more understandable and because it pulls in less baggage also more reusable. Less code should be evaluated for the whole framework, but also for each node in the dependency tree. As an example, zope.site is a new package but contains bits of zope.app.component and zope.app.folder both. Together with the creation of zope.container and moving stuff from zope.app.component to zope.security, we can probably eventually get rid of zope.app.component altogether, along with zope.app.folder and zope.app.container. That is a net minimization of packages, and what's more important, also less code to have to understand. Regards, Martijn ___ 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.publisher dependencies
Jim Fulton wrote: I disagree strongly with many of the assertions made in these articles. (I can't judge the pipeline proposal, since it is only fleshed out in code.) While I do think zope.publisher has some problems, they aren't the same problems that shane sees. What are the problems with zope.publisher as you see it? Shane ___ 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.publisher dependencies
Hi there, Hanno Schlichting wrote: [snip] P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) That's a cool resource! (the general dependencies folder there) Are you removing indirect dependencies before generating the graphs? I think it is valuable to actually consider the graphs *without* such removal being done. I think doing so hides the true complexity of the dependency situation and can therefore be very misleading. At least I recall the true dependency graphs of something like zope.formlib look a lot more hairy than this: http://hannosch.eu/dependencies/zope/zope.formlib.svg I highly recommend the use graphviz's sccmap to detect clusters of strongly connected components. Circular dependencies are one of our true problems and this tool can help you identify them. It would be nice if we could have a dependency checking service that could inform us when we're going in the wrong direction; in particular when we create strongly connected clusters. Regards, Martijn ___ 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.publisher dependencies
Hey, Shane Hathaway wrote: [snip] After thinking this over last night, I realize that the idea to move BrowserView, BrowserPage, and TestRequest is driven by the desire to clarify the dependency graph. That's more complex than what I'm trying to do and I don't think I need to do that for zope.pipeline, so I'm going to withdraw from that part of the discussion for now. If you can make progress without doing so now, by all means. I think we do need to get back to this though eventually. It'd be bad to pull in code that actually doesn't get used when you use zope.pipeline. Regards, Martijn ___ 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.publisher dependencies
Martijn Faassen wrote: Hanno Schlichting wrote: [snip] P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) That's a cool resource! (the general dependencies folder there) Are you removing indirect dependencies before generating the graphs? Yep. Those are the version with transitive dependencies removed. I work on this mostly from a Plone perspective, where the full versions are just utterly unreadable. But for actual code refactoring and dependency reduction on the zope.* level the full versions are indeed more useful. I added them now. The full horror of formlib is available as http://hannosch.eu/dependencies/zope/zope.formlib-full.svg I highly recommend the use graphviz's sccmap to detect clusters of strongly connected components. Circular dependencies are one of our true problems and this tool can help you identify them. I'll check that out, thanks. Hanno ___ 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.publisher dependencies
On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote: P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) That's cool, although wildly inaccurate. One of the things wrong with zope.publisher is that it depends on too many other things. It would be useful to try to clean that up. A while ago, I proposed a stripped down zope.publisher (zope.pub or something) that had a lot less in it, http://mail.zope.org/pipermail/zope-dev/2008-March/031170.html . I never found time to do this though. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
Martijn Faassen wrote: The main problem I have with the zope publication machinery is that after all these years of using it I *still* get lost in it regularly. A more regular architecture that can be traced more easily would not only allow better understanding on my part, but might also allow us to more easily selectively replace or remove bits of it. +1. As I recall, we tried to build a regular architecture in zope.publisher using the IPublication interface, but the publisher machinery is still painfully difficult to understand without extensive study. I think a pipeline design will make the publisher a lot easier for everyone to understand because the pipeline design seems to keep concerns closer together. For example, I've made a traversal module in zope.pipeline which has nearly all of the traversal logic in one place and almost nothing else. Its code came from at least 4 scattered modules. Now, in theory, when people want to understand traversal, they will usually only need to understand one module. Shane ___ 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.publisher dependencies
On Feb 24, 2009, at 12:44 PM, Shane Hathaway wrote: Jim Fulton wrote: On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote: I've been working on the dependencies to and from zope.publisher. Refining the dependencies should make it easier to integrate zope.pipeline when it's ready. Can you elaborate on this a bit? I've been discussing zope.pipeline on my blog. I just looked and I don't see many specifics. I think I have to look at the code and I don't have time for that atm. I am attempting to rebuild the publisher to make it easier to understand and customize. I think it's working out pretty well. zope.pipeline is intended to replace most of the implementation code in zope.publisher and zope.app.publication. If it is mixing those 2, them I'm not too impressed and I think those two packages have very different concerns. In any case, if what you you really want to do is to standardize some common APIs that a number of different publishing implementations can use, I'm fine with that. It should be a new package that has just those APIs and that zope.publisher could import. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
On Feb 24, 2009, at 1:55 PM, Shane Hathaway wrote: Martijn Faassen wrote: The main problem I have with the zope publication machinery is that after all these years of using it I *still* get lost in it regularly. A more regular architecture that can be traced more easily would not only allow better understanding on my part, but might also allow us to more easily selectively replace or remove bits of it. +1. As I recall, we tried to build a regular architecture in zope.publisher using the IPublication interface, but the publisher machinery is still painfully difficult to understand without extensive study. Maybe, but I find that people confuse the machinery in zope.publisher with a bunch of additional and very confusing machinery in various zope.app packages. The publisher itself is pretty simple. I think this is illustrated by paste.txt in the zope.publisher package. That isn't to say there might not be better models. Hopefully, I'll find time to study your pipeline ideas. I wish there was a proposal I could read rather than reading code. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
Jim Fulton wrote: On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote: P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) That's cool, although wildly inaccurate. What's wildly inaccurate about it? Missing transitive dependencies or something else? Regards, Martijn ___ 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.publisher dependencies
On Feb 24, 2009, at 5:19 PM, Martijn Faassen wrote: Jim Fulton wrote: On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote: P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) That's cool, although wildly inaccurate. What's wildly inaccurate about it? Missing transitive dependencies or something else? The graph only shows direct dependencies on zope.i18n and zope.security, but there are many other direct dependencies. Jim -- Jim Fulton Zope Corporation ___ 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.publisher dependencies
Hey, On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote: [snip] The graph only shows direct dependencies on zope.i18n and zope.security, but there are many other direct dependencies. Ah, agreed, yes, I think this is because of the transitive dependency functionality removal somehow, even though it seems to remove more than just these. Hanno's now also generating the real graphs, though: http://hannosch.eu/dependencies/zope/zope.publisher-full.svg Hanno, would you consider also generating graphs for the grokcore.* packages? Regards, Martijn ___ 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.publisher dependencies
Martijn Faassen wrote: Hanno, would you consider also generating graphs for the grokcore.* packages? Can you point me to a buildout or virtualenv-friendly way of getting an environment with those? Than it should be rather trivial to do for me. Hanno ___ 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.publisher dependencies
Martijn Faassen wrote: Hey, On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote: [snip] The graph only shows direct dependencies on zope.i18n and zope.security, but there are many other direct dependencies. Ah, agreed, yes, I think this is because of the transitive dependency functionality removal somehow, even though it seems to remove more than just these. Hanno's now also generating the real graphs, though: http://hannosch.eu/dependencies/zope/zope.publisher-full.svg I see in that graph a number of dependencies that are pulled in just for specifications. For instance, zope.publisher doesn't really need the Location class, it only needs ILocation. Just brainstorming, but I wonder if we shouldn't split at least the following packages into specification and implementation packages: - zope.location - zope.security - zope.i18n - zope.publisher - zope.component That way various packages could use i18n interfaces without pulling in pytz, or could use location interfaces without pulling in zope.proxy, and so on. Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. Shane ___ 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.publisher dependencies
Stephan Richter wrote: On Tuesday 24 February 2009, Shane Hathaway wrote: Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. Shane ___ 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.publisher dependencies
On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org wrote: Stephan Richter wrote: On Tuesday 24 February 2009, Shane Hathaway wrote: Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. zope.location.interfaces? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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.publisher dependencies
On Wed, Feb 25, 2009 at 12:39 PM, Lennart Regebro rege...@gmail.com wrote: On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org wrote: Stephan Richter wrote: On Tuesday 24 February 2009, Shane Hathaway wrote: Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. zope.location.interfaces? This will not make any change in dependency graph unless zope.location become a namespace package. -- Baiju M ___ 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] zope.publisher returns 200 Ok instead of 200 OK
Hi there, In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? Regarsd, Martijn ___ 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.publisher returns 200 Ok instead of 200 OK
On Nov 13, 2007 9:33 PM, Martijn Faassen [EMAIL PROTECTED] wrote: In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 -- Martijn Pieters ___ 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.publisher returns 200 Ok instead of 200 OK
Hi there, On Nov 13, 2007 9:45 PM, Martijn Pieters [EMAIL PROTECTED] wrote: On Nov 13, 2007 9:33 PM, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] What do people think? Should this be fixed? This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 Ah, I should've checked launchpad before reporting it. The discussion there is quite clear. Thanks! Regards, Martijn ___ 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 )
