[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Sun Aug 23 12:00:00 2009 UTC to Mon Aug 24 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Aug 23 20:44:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012368.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Aug 23 20:46:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012369.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Sun Aug 23 20:48:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012370.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Sun Aug 23 20:50:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012371.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun Aug 23 20:52:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012372.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Sun Aug 23 20:54:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012373.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Sun Aug 23 20:56:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012374.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Sun Aug 23 20:58:02 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012375.html ___ 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] Proposal: zope.app.publisher refactoring
On Friday 21 August 2009, Dan Korostelev wrote: > BrowserSkinsVocabulary - this can be moved to zope.publisher.browser > and rewritten with zope.schema's SimpleVocabulary not to introduce > dependency on zope.componentvocabulary. -1. Why? The reason we wrote the zope.componentvocabulary code originally was exactly to avoid the constant reimplementation of that code. Regards, Stephan -- Entrepreneur and Software Geek 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] Proposal: zope.app.publisher refactoring
2009/8/24 Stephan Richter : > On Friday 21 August 2009, Dan Korostelev wrote: >> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser >> and rewritten with zope.schema's SimpleVocabulary not to introduce >> dependency on zope.componentvocabulary. > > -1. Why? The reason we wrote the zope.componentvocabulary code originally was > exactly to avoid the constant reimplementation of that code. Well, the only reason is that zope.publisher currently doesn't depend on zope.componentvocabulary. But it doesn't matter for me personally, so if steering group decides that it's okay to add a dependency on zope.componentvocabulary to zope.publisher, I won't rewrite the vocabulary with SimpleVocabulary :-) -- 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] Proposal: zope.app.publisher refactoring
2009/8/22 Michael Howitz : > Am 21.08.2009 um 21:06 schrieb Dan Korostelev: > [...] >> >> ILogin, ILogout from zope.app.publisher.interfaces.http - looks like >> these don't really mean anything and are used only in >> zope.app.security. I'd move them to zope.app.security even without BBB >> imports (not to make zope.app.publisher dependent on >> zope.app.security), but maybe I just don't know something about them? >> :) > > z3c.layer.pagelet also uses these interfaces to re-implement login/logout > like zope.app.security but by using pagelets and viewlets. > So it would be nice to have a better place for these interfaces, so > z3c.layer.pagelet does not need to depend on zope.app.security. Are these interfaces used for anything else than just declaring them as implemented? :-) I don't see much sense in them, because they are too abstract and it's hard to understand what they are for, so I'd get just rid of them in z3c.layer.pegelet. -- 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 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] Proposal: zope.app.publisher refactoring
Hi Dan > Betreff: Re: [Zope-dev] Proposal: zope.app.publisher refactoring > > 2009/8/22 Michael Howitz : > > Am 21.08.2009 um 21:06 schrieb Dan Korostelev: > > [...] > >> > >> ILogin, ILogout from zope.app.publisher.interfaces.http - > looks like > >> these don't really mean anything and are used only in > >> zope.app.security. I'd move them to zope.app.security even without > >> BBB imports (not to make zope.app.publisher dependent on > >> zope.app.security), but maybe I just don't know something > about them? > >> :) > > > > z3c.layer.pagelet also uses these interfaces to re-implement > > login/logout like zope.app.security but by using pagelets > and viewlets. > > So it would be nice to have a better place for these interfaces, so > > z3c.layer.pagelet does not need to depend on zope.app.security. > > Are these interfaces used for anything else than just > declaring them as implemented? :-) I don't see much sense in > them, because they are too abstract and it's hard to > understand what they are for, so I'd get just rid of them in > z3c.layer.pegelet. Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling. Regards Roger ineichen > -- > 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 ) > ___ 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=5&b:int=6', but which posted the
'x' and 'y' values.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
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=5&b: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 Design"http://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 2.12: mkzopeinstance, runzope and zopectl - a small proposal
yuppie wrote: > Currently buildout is just used to set up the software. Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is "the software"... > is used to set up instances. And while I see that using buildout for > setting up everything in one step has some advantages, it's not the best > pattern for all use cases. So tell us where it's not best rather than just asserting that such a use case exists ;-) > mkzopeinstance helps to draw a line between software and data. No it doesn't. Plenty of software can live in an instance. IMNSHO, buildout does a *better* job of drawing a line between software and data... > that's important for distributors who want to distribute generic > software, not user specific instance setups. Distributors just want a tarball or similar, let them use zc.sourcerelease and have a slightly different buildout.cfg, or even default.cfg, which uses that tarball as the source of eggs rather than PyPI... > And sometimes it is useful > to link an existing instance to a new buildout by updating some paths in > instance/bin. I don't understand this. Please explain more... > Or to create several instances based on one buildout. Why? >> Interesting. I never noticed that... Hopefully that change will make it >> into Zope 2.12 final? > > Yes. I made that change on the 2.12 branch as well. Cool :-) >> Cool. If only the zope2 egg could expose these now, it would make the >> buildout.cfg simpler... just the matter of passing in the config. I >> wonder if anyone can think of a nicer way of doing that? > > runzope and zopectl are defined as entry points: > http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515&view=auto > > Or did you mean something else? I meant I nicer way of passing in the location of zope.conf... >>> we can make it unnecessary to specify the interpreter. >> When runzope and zopectl are built by buildout, this is already the >> case... One python is used for both... > > No. Currently you also need 'zopepy' (or 'py' in your case). They're all the same python... >>> 4.) How do you create zopeservice.py for Windows? >> What's Windows? Seriously though, I haven't needed to run Zope 2.12 on >> Windows, so I don't know... > > But we have to support Windows. And I was able to get zopeservice.py > running with mkzopeinstance. *If* we decide to use buildout the way you > propose, someone has to figure out how to create zopeservice.py without > mkzopeinstance. Sure, I can't imagine it's a particularly hard problem, it's just not one the I'm interested in solving... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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=5&b: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=5&b: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=5&b: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 )
[Zope-dev] zope.app.publisher refactoring status
Hi people. As you might notice, I was refactoring zope.app.publisher in my sandbox. The work is mostly done now, apart from couple of things still in question. Four new packages have been introduced: * zope.browsermenu - browser menu system, without any changes. :-) * zope.browserpage - browser:page directive and friends. the directives was changed to support menu item registration only when zope.browsermenu is available, simply ignoring (and raising a warning) the "menu" argument otherwise. * zope.browserresource - resource system and browser:resource directive and friends. file-based resources now supports pluggable resource class lookup based on file extension (implementation based on this patch - https://bugs.launchpad.net/zope3/+bug/98459). this allows to separate pagetemplate resources into another package as well as support registering specific resource factories for some extensions (.zrt for example). * zope.ptresource - the page template resource that was moved into a separate package to make zope.browserresource independent from zope.pagetemplate. it's now a plugin for zope.browserresource - a custom resource factory, registered for "pt", "zpt" and "html" extensions. The ModifiableBrowserLanguages adapter was moved into zope.publisher.browser, as well as some ZCML security declarations defined for zope.publisher's classes. Things left in zope.app.publisher are still to be discussed. First, the "Browser Skins" vocabulary - a vocabulary of IBrowserSkinType utilities. It could be moved to zope.publisher, but it introduces dependency on zope.componentvocabulary, which is not needed for zope.publisher currently. So there's three options to choose from: a) Move it to zope.publisher, introducing a dependency on zope.componentvocabulary for it. b) Move it to zope.publisher, rewriting the vocabulary to use zope.schema's SimpleVocabulary and not introducing dependency on zope.componentvocabulary. c) Leave it there as is. I think, that it's a nice option, since "Browser Skins" vocabulary doesn't seem to be used anywhere by other zope packages and can be easily recreated if someone will need it. Second, the "browser:defaultView" and "browser:defaultSkin" directives. The functionality of default views and default skins is currently contained in zope.publisher, and these directives only provide a way to configure default view/skin via ZCML. I think that these directives should be moved to zope.publisher as well, since it seems the right place for them and the move won't introduce extra dependencies for zope.publisher. Third, the "xmlrpc:view" directive and the XML-RPC method publisher. It's a nice thing, but people doesn't seem to be interested very much in XML-RPC these days. Also, it seems that zope.publisher will be refactored soon, so the future of xmlrpc modules is not clear. I see two options for this thing: a) Extract it into the new, "zope.xmlrpc" module. b) Leave it there as is. If noone demonstrates interest in discussing the xmlrpc, I'll probably choose option b :-) The code is available in svn://svn.zope.org/repos/main/Sandbox/nadako/zope.app.publisher/. It will also check out newly created packages via svn:externals, so all you need for testing is simply checkout zope.app.publisher from my sandbox. -- 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] Proposal: zope.app.publisher refactoring
Am 24.08.2009 um 19:02 schrieb Dan Korostelev: > 2009/8/22 Michael Howitz : >> Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...] >> z3c.layer.pagelet also uses these interfaces to re-implement login/ >> logout >> like zope.app.security but by using pagelets and viewlets. >> So it would be nice to have a better place for these interfaces, so >> z3c.layer.pagelet does not need to depend on zope.app.security. > > Are these interfaces used for anything else than just declaring them > as implemented? :-) I don't see much sense in them, because they are > too abstract and it's hard to understand what they are for, so I'd get > just rid of them in z3c.layer.pegelet. I looked a bit into the code of z3c.layer.pagelet and it seems that you are right. Only the ILogin interface is used there. (The ILogout interface is the one from zope.authentication which seems to be semantically different from the one in zope.app.publisher.interfaces.http.) Although it is a bad idea to copy interfaces, z3c.layer.pagelet could reinvent ILogin if it is really needed. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · 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] Proposal: zope.app.publisher refactoring
Am 24.08.2009 um 22:55 schrieb Roger Ineichen: [...] > Everything which has to do with login has nothing to do > in z3c.layer.pagelet. > z3c.layer.pagelet should only offer a working setup for > pagelet based traversal stuff and error handling. Until we find a better place for it I'd like to keep it there as it is a basic implementation (ported from zope.app.security) of login/logout using pagelets/viewlets. It is the pagelet version of login/logout as the other parts are the pagelet version of error handling and traversal. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · 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 )
