Re: [Zope3-dev] Is Zope3.4 eggs going to be backwards compatible with Zope3.3 zpkg?
Ignas Mikalajunas wrote: Hi, I have accidentally tried upgrading from Zope3.3 branch checkout to Zop3.4 eggs, How you are doing this? can you elaborate? and it seems that at least: include package=zope.app / instead of throwing a deprecation warning (the way switching to Zope3.4 branch does IIRC) just stopped working. An egg based release is different from zpkg based release. In this case to get the proper warning you require more packages like 'zope.app.zcmlfiles', which are available as eggs. When working with eggs, there should be some mechanism to glue these eggs together, using zc.buildout is a good solution for that. Is there something wrong with my setup or will this way of upgrading things just not work? I can migrate Zope3.3 zpkg - Zope3.4 zpkg - Zope3.4 eggs. So, to change from zpkg based release to an egg based one, applications need to undergo some change in it's way of developing it. For example, if you want to use use zc.buildout, you can also use recipes like zc.zope3recipes, zc.recipe.filestorage, zc.recipe.testrunner etc for building and deploying a Zope 3 application. These recipe doesn't support anything like package-includes by default. Please see this for an example: svn://svn.zope.org/repos/main/zwiki/branches/baijum-experimental-zwiki Just that naming Egg release 3.4 seems a bit unfair, as one would expect 3.4 to be backwards compatible with 3.3. Well, what about creating an egg which lists all packages in Zope 3.4 as dependencies ? I think it will be useful for those who changing from zpkg based release to egg based release for development. In fact I have created one egg like that for my convenience: http://www.baijum.info/z3/download/zope33to34-3.4.0a1.tar.gz If anyone else want this, I can upload this to Python's cheeseshop. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a bug in the Zope 3 (and 2) page template engine
Fred Drake wrote: On 4/20/07, Martijn Faassen [EMAIL PROTECTED] wrote: No, the current expectation is that it works, whatever the replacement is. This currently works in Zope 2.8: You'll need to explain how silently dropping the tal:attributes on the floor was ever it works. Sorry about being unclear. Of course you can argue about whether this is correct behavior or not. That was not my point. I was trying to make sure you understood the issue here: the getCompilerError exception occurs no matter whether the replace text starts with an element or not. You seemed to be saying it only happened in the latter case. At any rate, backward compatibility reigns in the page template engine, no matter how misguided I feel this behavior may be. Right. I agree that the behavior is somewhat unexpected (I didn't expect it), though I can see it potentially being useful. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a bug in the Zope 3 (and 2) page template engine
Fred Drake wrote: On 4/20/07, kit BLAKE [EMAIL PROTECTED] wrote: But those attributes *do* work. If you call that image without the attributes, it won't have a title attribute. If you keep the tag as it is, it will have a title attribute. This is some pretty freaky behavior for page templates, I think, but was by design. (I don't remember the driving use-case though; sorry.) The problem is that Martijn's replacement doesn't start with an element, so the attribute insertion fails. There should probably be a more explanatory error message in this case. No, I don't think that is the cause of the problem, unless I'm missing something. This results in the exact same error: html img tal:replace=structure python:'pFoo/p' tal:attributes=title python:'bar' / /html The error message is not just non-explanatory. The error message is an indication of a real bug that's been in Zope 3 page templates since SVN history began. :) I don't really like this behavior, and wouldn't miss it if it were disallowed, but the current expectation is that it work when the replacement starts with an element. No, the current expectation is that it works, whatever the replacement is. This currently works in Zope 2.8: img tal:replace=structure python:'Foo' tal:attributes=title python:'bar' / The result is' foo'. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] possible bug in z.a.password?
Hello, Using the current trunk I experienced that using the PAU with a user folder and users passwords stored with MD5, entering accented characters as passwords causes an exception. That happens either at adding the principal or at Z3's stock login form. I think this is not my fault, but could somebody crosscheck that please? Traceback from the login form, I entered éá as password: File U:\zope\svn_zope34\src\zope\publisher\publish.py, line 130, in publish obj = request.traverse(obj) File U:\zope\svn_zope34\src\zope\publisher\browser.py, line 513, in traverse ob = super(BrowserRequest, self).traverse(obj) File U:\zope\svn_zope34\src\zope\publisher\http.py, line 448, in traverse ob = super(HTTPRequest, self).traverse(obj) File U:\zope\svn_zope34\src\zope\publisher\base.py, line 252, in traverse publication.callTraversalHooks(self, obj) File U:\zope\svn_zope34\src\zope\app\publication\zopepublication.py, line 12 3, in callTraversalHooks self._maybePlacefullyAuthenticate(request, ob) File U:\zope\svn_zope34\src\zope\app\publication\zopepublication.py, line 11 0, in _maybePlacefullyAuthenticate principal = auth.authenticate(request) File U:\zope\svn_zope34\src\zope\app\authentication\authentication.py, line 76, in authenticate info = authplugin.authenticateCredentials(credentials) File U:\zope\svn_zope34\src\zope\app\authentication\principalfolder.py, line 280, in authenticateCredentials if not internal.checkPassword(credentials[password]): File U:\zope\svn_zope34\src\zope\app\authentication\principalfolder.py, line 150, in checkPassword return passwordManager.checkPassword(self.password, password) File U:\zope\svn_zope34\src\zope\app\authentication\password.py, line 54, in checkPassword return storedPassword == self.encodePassword(password) File U:\zope\svn_zope34\src\zope\app\authentication\password.py, line 77, in encodePassword return md5.new(password).hexdigest() UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordin al not in range(128) -- Best regards, Groszer Adam -- Quote of the day: Top ten things you'll never hear in an internet chat room: 5. Well... gotta go. It's almost time to pick up my date. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.4.0a1 released
On Apr 20, 2007, at 10:25 AM, Martijn Faassen wrote: Hey, Compatibility with Zope 2 -- We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 packages. But we're not there yet. **You can't run Zope 2 applications in Zope 3.** [...] I'd suggest a rewrite ... +1 to changing, and to what you wrote specifically Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max M wrote: Martin Aspeli skrev: Peter Bengtsson wrote: Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) (I know it is late to participate in this thread, but I am reading up on grok.) I used to have the above opinion too. But I have changed my mind. A good framework will get you up and running with as little resistance as possible. But actual real-life projects will often need a lot of files, configuration and settings. So you might start out mean and lean, but after you are done fixing all the little special cases and customizations, you will still have a lot of code. If all that code you end up with anyway is automatically generated, it will have an educational effect on the community. A Code by Numbers effect where you fill in code in the obvious slots. That presumes that the framework is omniscient / presient enough to leave slots in place to allow the customizaitons you want. I *hate* fighing some UID-generateing architecture (wiggling the wires) to get the customer's desired UI. Just see how easy it is to check out other peoples AT based code in Plone. Simply because everyone are acustomed to the structures and conventions. I think you just proved Martin's point: in my experience, maintaining other people's AT-based code is like Napoleon before Moscow: thigh deep in freezing mud. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFGKM+2+gerLs4ltQ4RAlqyAJ9/5MlxmBy+nAYJUkmrrtCPt0aHMwCeOr3X T0RmJNDsVnTMl4iARwFtL2E= =Q4CN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Grok sprint 2 reports
Tres Seaver wrote: I think you just proved Martin's point: in my experience, maintaining other people's AT-based code is like Napoleon before Moscow: thigh deep in freezing mud. By AT, I assume you mean Archetypes, and Archetypes doesn't depend on code generation, nor is it very hard to maintain other people's AT based code if it was well-written to begin with. Maintaining other people's badly written code is a pain no matter what tool they used to write it. :) If you're talking about ArchGenXML, which generates AT code from UML, it's not too bad. The code it generates is pretty clean, and if you decide to abandon code generation, there's a minimum of cruft (mostly a few comment blocks) that you can remove if you wish. Martin -- View this message in context: http://www.nabble.com/Grok-sprint-2-reports-tf2947404.html#a10103484 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote:
While I am vehemently opposed to code generation per se, one alternative
which I think is important is to generate stuff *at runtime* from
artifacts which are more understandable to business users than Python
code. E.g., they might specify schema in a spreadsheet, an HTML form,
or a UML diagram, which we then use to create a schema interface (my
'userschema' package[1] does this already for the first two).
Not sure which mailing list my questions belong on but for the time
being I'll ask them here (any list subscribers feel free to tell me to
take this discussion offline).
This userschema package looks very cool and it's nice to see all the
cool ways you can produce schema's from user contributed data (ie csv,
html). But I'm curious to know what sort of use cases you have for the
end-result schema's ... simple formlib form generation? content type +
edit form (via formlib) generation?
Obviously generated UI is the main use-case; I have some notions about
making it easier to use schema stuff from within custom UI, but they
aren't fleshed out yet.
I do have a notion of allowing the template which *specifies* the schema
to be used to *render* its fields, but haven't got that part working
yet. Chris McDonough and I have talked about using a meld3-based
approach to that, as well.
(Sorry to follow up to myself, and so late).
While at the BBQ sprint last month, Philipp and I worked on a prototype
for this last idea. Although it isn't cleaned up yet for a release, the
essence of it is to put the 'index' and 'edit' templates (hand-rolled,
of course) into the appropriate subdirectory, and then use a new grok
directive to get the class and all its views wired up. E.g.::
$ cat simple_templates/index.pt
html
body
div tal:content=structure context/body | nothing
BODY
/div
/body
/html
$ cat simple_templates/edit.pt
html
body
form name=simple_edit action=. method=POST
fieldset id=body_fs
legendSimple Body/legend
textarea id=doc_body name=body rows=20 cols=80
tal:attributes=name view/widget/body/name|default
tal:content=view/widgets/body/_getFormValue/textarea
/fieldset
div
input type=submit name=form.submitted value= Save Changes
tal:repeat=action view/actions
tal:attributes=name action/__name__;
value action/label /
/div
/form
/body
/html
$ cat app.py
import grok
import grok_crud
from zope.formlib import form
class SimpleApp(grok.Application, grok.Container):
pass
class Index(grok.View):
grok.context(SimpleApp)
class Simple(grok_crud.Crud):
grok_crud.directory('simple')
With something like meld3, we could even get rid of the hairy TALES
expressions in the tmeplates, making them purely the domain of the designer.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
iD8DBQFGKNxM+gerLs4ltQ4RAu0AAJ9/l7K9l5TkMLCOAp/rdExACfpItACgxRpq
X4p0vh6t5WKEJPmihBjf3qo=
=CHwU
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a bug in the Zope 3 (and 2) page template engine
kit BLAKE wrote: 2007/4/19, Martijn Faassen [EMAIL PROTECTED]: Hi there, I just tracked down what I believe is a bug in the Zope 3 page template engine. I didn't know it was a bug in the Zope 3 page template engine as I was tracking down a bug in Silva with Zope 2.10, which of course uses the Zope 3 page template engine. For the proposed solution, see the bottom of the mail. Let's consider the following code fragment: img tal:replace=structure python:'foo' tal:attributes=title python:'bar' / In Zope 2 before Zope 2.10, this line works without error. The tal:attributes line of course is pretty useless, as the whole img tag gets replaced anyway, but it doesn't bail out with an error. But those attributes *do* work. If you call that image without the attributes, it won't have a title attribute. If you keep the tag as it is, it will have a title attribute. You are right, I just verified this. I was wondering about this yesterday, but in some cases I went through in Silva seemed to have a duplication only - the underlying Python code appeared to be doing the same as the ZPT, so the ZPT was redundant. I may have missed some cases though and I should've checked with an older version of Silva. [snip] This might also be a good occasion for a new Zope 2.10 bugfix release. Silva is running into this currently, though of course now that we know what the cause is we can work around it. Just please keep the attributes working with replace :-) Yes, definitely. I hope the fix I am proposing still does this, but I need to verify this. I will add a test that actually tests this. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli skrev: Peter Bengtsson wrote: Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) (I know it is late to participate in this thread, but I am reading up on grok.) I used to have the above opinion too. But I have changed my mind. A good framework will get you up and running with as little resistance as possible. But actual real-life projects will often need a lot of files, configuration and settings. So you might start out mean and lean, but after you are done fixing all the little special cases and customizations, you will still have a lot of code. If all that code you end up with anyway is automatically generated, it will have an educational effect on the community. A Code by Numbers effect where you fill in code in the obvious slots. Just see how easy it is to check out other peoples AT based code in Plone. Simply because everyone are acustomed to the structures and conventions. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget(.tiny) widget available to easy_install anywhere?
P.S. Visibility of Zope 3 extensions would be increased greatly if we could have an overview page per extension on zope.org somewhere. It would of course include the canonical download link as well. I think we can accomplish this relatively quickly with a fairly low-tech project, but we need a volunteer. Anyone? Sort of like cheeseshop? BTW, why aren't the Zope packages on cheeseshop to start with? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget(.tiny) widget available to easy_install anywhere?
On Apr 20, 2007, at 1:32 PM, Sidnei da Silva wrote: P.S. Visibility of Zope 3 extensions would be increased greatly if we could have an overview page per extension on zope.org somewhere. It would of course include the canonical download link as well. I think we can accomplish this relatively quickly with a fairly low-tech project, but we need a volunteer. Anyone? Sort of like cheeseshop? BTW, why aren't the Zope packages on cheeseshop to start with? Many of the zope packages have been minimally eggified. I personally don't want to see packages appear in the cheeseshop until their meta data has been filled out and have documentation that either shows up in the cheeseshop or is linked from there. I'm also finding it challenging to manage eggs in the cheeseshop. The cheeseshop makes it really hard to publish multiple versions and multiple versions need to be accessable to buildout so that versions can be frozen. I wish we had our own tool that we could link to from the cheesehop, but, of course, I don't have time to write it. I guess I should request cheeseshop enhancements. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget(.tiny) widget available to easy_install anywhere?
Hi Martin. Cheeseshop does this already. You can see how a nice overview page is constructed by putting readme.txt with readme.txt release notes in setup.py as restructured text. This is available on some zope packages but also the zif packages on pipy. See zif.headincludes in the cheeseshop as an example of how this works for a nice web page explaining the package. I am not sure why there are two resources for obtaining eggs myself, not sure if it is because pipy gets busy. Should the default be pipy or will this slow buildouts? Maybe all packages could be put there in any case even if primary dependency link for zope packages is download.zope.org. Maybe this just adds to the headache of releases to have more than a single location. pipy already has the infrastructure for some proper searching and management for package maintainers - so not sure that the wheel needs to be invented. Actually, I thought the way this was all going to unfold was with the ZF website which I think is still being worked on. Many thanks. Regards, David Martijn Faassen wrote: Hi there, I'm interested in adding a dependency on z3c.widget, and in particular z3c.widget.tiny, in an application I'm available. In the svn checkins I see a comment by dobe saying: buildout and egg, clean imports This implies to me there might be an tgz that buildout/easy_install can use available somewhere. But where? I cannot find it in the cheeseshop, nor in download.zope.org/distribution. Is it available somewhere else? Or should I upload a version of it myself? Regards, Martijn P.S. Visibility of Zope 3 extensions would be increased greatly if we could have an overview page per extension on zope.org somewhere. It would of course include the canonical download link as well. I think we can accomplish this relatively quickly with a fairly low-tech project, but we need a volunteer. Anyone? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] SHA1Password manager, add a pinch of salt
Hi, I've been researching authentication and whatnot in Zope 3 and was looking at the password management implementations. I don't like the fact that the SHA1 password manager doesn't use a random salt value when encoding and storing a password. Salts are commonly used in /etc/passwd and friends to eliminate the identification of passwords that are the same among users, as well as to make the brute forcing space a little larger. Here is a unified diff that adds 32 bits of salt to the SHA1 password storage mechanism. The same may be done for md5, but its use is falling out of favour, so I didn't bother. What else do I need to do to contribute this change? Have I missed anything? Regards, Mark zope# diff -u password.py.dist password.py --- password.py.distTue Oct 24 04:21:55 2006 +++ password.py Fri Apr 20 14:21:31 2007 @@ -13,12 +13,13 @@ ## Password managers -$Id: password.py 70897 2006-10-24 08:21:55Z flox $ +$Id$ __docformat__ = 'restructuredtext' import md5 import sha +import random from zope.interface import implements, classProvides from zope.schema.interfaces import IVocabularyFactory @@ -85,19 +86,34 @@ verifyObject(IPasswordManager, manager) True - encoded = manager.encodePassword(password) + encoded = manager.encodePassword(password, salt='') encoded '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8' manager.checkPassword(encoded, password) True manager.checkPassword(encoded, bad) False + + encoded = manager.encodePassword(password) + manager.checkPassword(encoded, password) +True + manager.checkPassword(encoded, bad) +False implements(IPasswordManager) -def encodePassword(self, password): -return sha.new(password).hexdigest() +def encodePassword(self, password, salt=None): +if salt is None: +salt = '%x' % random.randrange(1, 2**32-1) +return salt + sha.new(salt+password).hexdigest() + +def checkPassword(self, storedPassword, password): +if len(storedPassword) == 48: +salt = storedPassword[0:8] +else: +salt = '' +return storedPassword == self.encodePassword(password, salt) # Simple registry used by mkzopeinstance script managers = [ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli skrev: If you're talking about ArchGenXML, which generates AT code from UML, it's not too bad. The code it generates is pretty clean, and if you decide to abandon code generation, there's a minimum of cruft (mostly a few comment blocks) that you can remove if you wish. Yes. I was unclear. Sorry. I meant AGX. I use it for getting a project skeleton up and running quickly from simple UML. Something similar for Zope3 would be with me. Where the interfaces, classes, zcml and views would be generated from UML. But I will try out Grok, and see how the shoe fits before rambling on. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
