[Zope3-dev] Is standard_macros/view just an alias for standard_macros/page?
Hello! I've just looked at zope.app.basicskin.standardmacros and it seems to me standard_macros/view (and similar macros) now not used and moreover some templates now unaccessible through standard_macros for example zope/app/rotterdam/view_macros.pt now overridden by zope/app/rotterdam/template_tablelayout.pt. Is it intentional and unused templates should be removed or it's a bug or maybe I'm missing something? -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Don't need $Id$ string any more
Jim Fulton wrote: I propose we stop bothering to include $Id$ strings. (Note that I'm *not* suggesting we go out of our way to remove them.) Thoughts? +1 (Moreover Bazaar for example doesn't support this keywords yet.) -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] KeywordIndex, TopicIndex should implement IIndexSearch
I've just discovered that KeywordIndex and TopicIndex don't implement IIndexSearch so the indexes don't work with the Catalog. Is there any reasons for this? I think apply methods in this case can be equivalent to search(query, 'and') without any problems. -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ 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: translation of zope3
Philipp von Weitershausen wrote: Christophe Combelles wrote: Is translations.launchpad.net the regular and recommended way of translating zope3 ? Yes. I'm not sure they're synchronizing frequently with the repository. You bring a good point to my attention. Now that each package is its own project with a separate release cycle, we should split up the translations and maintain them for each package. Mostly 'zope.app.*' packages (with a few exceptions such as zope.formlib) will have translations. Given that the extraction tool left source markers in the translation files, I think this task could be automated. Would be a fun project for somebody :) I've already thought about it and I think the following steps should be performed: 1. Move all Python modules from zope.app.locales to zope.i18nmessageid (or maybe to zope.i18n?). 2. Write a tool for splitting up translations. I think the tool will be useful not only for the case and it would be cool if the tool could extract, split and merge translations. 3. Split up the existing translations. 4. Remove zope.app.locales altogether. If nobody objects I can perform the steps above. Open questions: - What about translations.launchpad.net? Is there are way to create templates for all translated packages in the zope3 project? - When the next release? :-) -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Inherit IUnauthorized and IForbidden from IException
Hello! I've just found that zope.security.interfaces.IUnathorized and IForbidden inherited from Interface instead of IException (as I expecting it should be). Is it intentionally or just a bug? In the last case I can easily fix it. -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SHA1Password manager, add a pinch of salt
Giovannetti, Mark wrote:
From: Dmitry Vasiliev [mailto:[EMAIL PROTECTED]
Slices doesn't wrap around.
Right, this was what I was seeing/thinking about:
for i in range(41): print i, ' + password[:i-40] + '
[skip]
Can't really call it wrap around, I guess.
Anyway:
def checkPassword(self, storedPassword, password):
salt = storedPassword[:max(0, len(storedPassword)-40)]
return storedPassword == self.encodePassword(password, salt)
With Python you can do things as simply as possible. :-) The
expression
storedPassword[:-40] (which is equivalent to
storedPassword[:len(storedPassword)-40]) does exactly what you want:
password[:-40]
''
Keeping it simple is often the best way. Given the above, in order
to ensure a blank salt with a password less than 40 characters,
keeping it simple may not suffice.
I think in the example above you're testing for wrong use case since we
use constant slice index, the following example explains what I mean:
hash = 123456789
while hash:
... print (hash[:-4], hash[-4:])
... hash = hash[1:]
...
('12345', '6789')
('2345', '6789')
('345', '6789')
('45', '6789')
('5', '6789')
('', '6789')
('', '789')
('', '89')
('', '9')
--
Dmitry Vasiliev dima at hlabs.spb.ru
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in z.a.password?
Adam Groszer wrote: Ugh, my bad I didn't notice that passwords may be Unicode strings. I think password should be encoded to UTF-8 before processing but I don't know that to do with backward compatibility. As an option we can introduce new Unicode-aware password managers. Opinions? Thinking it further, I think that nobody was able to enter accented passwords until today :-) I want to believe that most use more secure password managers which fit their needs. :-) and UTF-8 is encoding ASCII to ASCII (does it change anything???). I think it's OK. IMHO it would not hurt adding an UTF-8 encoding to the current password manager. Anybody against that? +1 I can commit the changes if nobody objects. -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Windows 2000 zc-bbwin3
[EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope3 trunk 2.4 Windows 2000 zc-bbwin3. The errors are mostly fall in the following categories: 1. Permission denied: 'c:\\docume~1\\buildbot\\locals~1\\temp\\... Can somebody fix the setup? 2. No such file or directory: 'src/docutils/writers/html4css1/html4css1.css' Possibly some path arithmetic error? Although all tests from this category are pass for me on Windows XP. 3. zope/testing/testrunner-coverage.txt: Failed example: ignore._test_dirs Expected: ['/myproject/src/blah/foo/', '/myproject/src/blah/bar/'] Got: ['c:/myproject/src/blah/foo/', 'c:/myproject/src/blah/bar/'] It seems like 'os.path.abspath' problem but again it work for me on Windows XP. -- Dmitry Vasiliev dima at hlabs.spb.ru http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] server error in apidoc (encoding pb)
Christophe Combelles wrote: Did someone have a look on this error ? Is it a trivial thing, or a local configuration problem, or is it reproduceable? (I write in utf-8, and I put # -*- coding: utf-8 -*- in my interfaces.py) You must use unicode docstrings. The encoding declaration at the top of the module doesn't do any magic by itself but just tells Python from which encoding unicode strings can be decoded. So your module should looks like this: # -*- coding: utf-8 -*- uSome docstring text in utf-8. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] onlinehelp i18n aware
Jean-François Roche wrote: I meet a usecase that i don't really see how to solve. My users need some kind of contextual help and these help files need to be in different languages. I looked closer at onlinehelp but it seems that no i18n link have been done. I was wondering if you might have an idea on how to implement this in a nice way ? I've thought about this a few months ago and my initial thoughts was about slightly modified interfaces like this: class II18NOnlineHelpTopic(Interface): def getTitle(language=None): pass def getPath(language=None): pass def addResources(resources, language=None): pass class II18NSourceTextOnlineHelpTopic(II18NOnlineHelpTopic): def getSource(language=None): pass def getType(language=None): pass Unfortunately it's just a raw thoughts and I don't have time right now to start implementing it. :-( -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: Subversion 1.4 breaks mkzopeinstance.py
Philipp von Weitershausen wrote: Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: Jim Fulton wrote: Uh, why are we parsing the entries file? To get the current revision of the Zope 3 checkout... Why not use svn info --xml? or even just svn info... I think we (Christian Theune and I) chose to poke at CVS/Tag and .svn/entries later because you may not know where the cvs/svn executable is installed (it may not be on your $PATH). Ugh, it was me. I switched ZopeVersion from CSV to SVN, moreover the first revision (25322) used 're' module to parse .svn/entries and later (41452) has been switched to use 'xml.dom.minidom'. I think extract information from .svn/entries is more safe way than use svn info/svnversion but however it require more maintaining effort. So I'll change the parser to make it more robust if no one objects. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: Subversion 1.4 breaks mkzopeinstance.py
Wichert Akkerman wrote: Previously Dmitry Vasiliev wrote: Ugh, it was me. I switched ZopeVersion from CSV to SVN, moreover the first revision (25322) used 're' module to parse .svn/entries and later (41452) has been switched to use 'xml.dom.minidom'. I think extract information from .svn/entries is more safe way than use svn info/svnversion but however it require more maintaining effort. So I'll change the parser to make it more robust if no one objects. I would suggest using svnversion first if that exists, and possibly doing a fallback to parsing things by hand. The output of svnversion is much more accurate than a single revision number. Current implementation of ZopeVersion also extracts tag/branch information so I guess it's better to use 'svn info' instead of 'svnversion'. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Christian Theune wrote: Dmitry Vasiliev wrote: I agree the i18n datetime parsing should be made a bit relaxed. I even think the only important thing in this context is the order of the fields, so we can ignore spaces (or even ignore some other delimitters?) and maybe ignore other non-field characters (for example in the russian long format you always need to write year as year 2006 instead of the simple 2006). I'm very much against relaxed date/time format checking. I tend to give my user the exact format that is expected and fail otherwise. All the guessing in the past led to bad bad errors because the field order the user entered was syntactically compatible but had a semantically different meaning. E.g. 02/05/2005 and 02.05.2005 are two different things. Relaxed doesn't mean try to parse any possible datetime format in the world. For each locale the ICU XML files contains 4 date formats and 4 time formats. The formats mainly useful for formatting printable datetime representation and a bit strict for parsing. So there are my ideas: - it would be useful if DateTimeFormat (hmm, maybe also NumberFormat) might to parse any format combination for the current locale (if it possible) in some unstrict mode; - I think it would be safe to parse any number of space characters as one space character and ignore literal (quoted in the pattern) characters on input; - I think it would be safe to interchange long and short month names on input (as Gary already pointed); -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] About the issue #525: DateWidget ru-format
Hi, I'll plan to rollback the revision 68818 on the 3.3 branch (hmm, should I also rollback the revision 68821?) and add Date(time)I18NWidget instead before the weekend. It seems so big change for the 3.3 branch and need more discussion (also the change broke SchoolTool functional tests). -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Tres Seaver wrote: Dmitry Vasiliev wrote: It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. That breaks a test: File /home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/python/zope/formlib/form.txt, line 1547, in form.txt Failed example: print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE Expected: input class=textType id=form.now name=form.now size=20 type=text value=2002-12-02 12:30:00 / Got: input class=textType id=form.now name=form.now size=20 type=text value=2002 12 2 12:30:00 / You just need to update your zope.formlib package. The test was fixed in the original checkin. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Gary Poster wrote:
However, I'm not sure the new widget behavior is great for non-default
locales either. Certainly being able to display dates in a
locale-specific way is nice, but the input seems to be problematic. If
you specify an ACCEPT-LANGUAGE of en-US, for instance, you need to
fill in Dec 2, 2002 12:30:00 PM, if I remember correctly. Fully
spelling out December does not work. Leaving off the seconds doesn't
work. Any other format will not work. I didn't check, but assume other
languages result in similar restrictions in input.
Yes, the input is a bit problematic in russian too, especially for long and
full display styles. Unfortunately I didn't get any reply on my pre-checkin
message (http://mail.zope.org/pipermail/zope3-dev/2006-June/019585.html) so I
guessed no one was interested in the problem.
The data in en.xml could be usable to get a more robust approach, and it
could even be done without change to zope.i18n for dates. But AFAICT,
for datetimes some help would need to be implemented in the i18n.locale
module (since the order of dates and times is specified in the XML); and
for datetimes and times I think we'd want to make specifying seconds,
and maybe even minutes, optional. This is probably doable, but it seems
like it might be painful to code and test.
I agree the i18n datetime parsing should be made a bit relaxed. I even think
the only important thing in this context is the order of the fields, so we can
ignore spaces (or even ignore some other delimitters?) and maybe ignore other
non-field characters (for example in the russian long format you always need
to write year as year 2006 instead of the simple 2006).
I understand what Dmitry did, and why he did it. It makes sense
theoretically, but seems to fall down a bit practically. I wonder if
this should be an optional set of date and datetime widgets, rather than
the default ones.
I think we just need to relax a bit i18n datetime parsing and the widgets will
be useful as is. BTW, shouldn't we add Time and Timedelta widgets?
I think I've heard that the parsing in the old
datetime widget was Ameri-centric, but at least it could handle an ISO
standard that was unambiguous, defensible, and easily described in some
static how to specify a date example or instructions.
It would be useful if some sort of instruction with the desired input format
will appears for the datetime fields, for example as dynamic description of the
field.
The other approach is for someone to spend some time polishing the
i18n.locale formatting code a bit. That won't solve the test problem
('2005 4 12 12:15:00 ') but it would at least make the primary user
experience more reasonable.
I don't think we need to change the formatting code, just need to make the
parsing code a bit flexible. I can start working on the parsing code if no one
objects.
BTW, maybe we need to do something with timezone offset-naive/offset-aware
datetime issue? For example we can store all time in UTC and convert it as
needed on input/output (it's like unicode for time :), or just store
offset-naive time as UTC. It seems currently we don't have a consistent policy
for this case.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Benji York wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? DatetimeWidget now use zope.i18n for parse and format values so the display is the same as for DatetimeDisplayWidget (note the line 1529 of the form.txt). ...and in such a strange way? It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] About issue 525: i18n Date(time)Widget
Hello! Currently I'm working on the issue 525 (DateWidget ru-format). I've already changed 'parseDatetimetz' in favor of 'self.request.locale.dates.getFormatter' for DatetimeWidget and DateWidget, but now I face some usability/backward compatibility problems. By default display style for 'getFormatter' is set to None which means (in the most locale data files) 'medium' date/time format. The problem is that 'medium' time format doesn't accept timezone argument (in the most locale data files) so there is no way to set timezone information (it just ignored). One possible solution is to change display style to 'long'. The drawbacks I've seen so far are: - the timezone information is mandatory in this case; - the format is much verbose than 'medium'; Maybe some more acceptable solutions exists? In case if there is no objections about 'long' format should we also change display format to 'long' for DateDisplayWidget/DatetimeDisplayWidget? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] TALES PathExpr doesn't call old style classes
Dieter Maurer wrote: Dmitry Vasiliev wrote at 2006-5-23 17:06 +0400: ... PEP-3100 suggest just call the object and catch the exception instead of use callable(). So maybe we can write: try: ob() except: pass return ob Unfortunately exceptions still will be masked. Yes, and therefore *NEVER* do this. I don't like it also but the PEP suggest so... :-) -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote: Hi there, I've filed an issue in the collector outlining a problem with old style classes and TALES traversal: http://www.zope.org/Collectors/Zope3-dev/635 In particular, I'm looking for comments on problem #2. PEP-3100 suggest just call the object and catch the exception instead of use callable(). So maybe we can write: try: ob() except: pass return ob Unfortunately exceptions still will be masked. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] i18n for 'structure' in TAL
Martijn Faassen wrote: i18n doesn't actually work for things marked as 'structure' in a page template in both Zope 2 and Zope 3. Zope 2 does do this with PlacelessTranslationService (through some tortuous route I won't go into). I think in practice large systems such as Plone, Silva and CPS are all translating snippets with bits of HTML in there, so i18n for structure is important. Hmm, it was working in Zope 3, moreover there is even a tests for this case in 'zope/tal/tests/test_talinterpreter.py'. The only possibility I've seen so far is 'evaluateStructure' call returns something different from 'TypesToTranslate' and no translation happens. Zope 2 + Five i18n work however. Zope 3 presumably doesn't work either. I have a monkey patch lying around that fixes this in Zope 2.x and I could check the fix in directly (and fix it Zope 3.3 trunk too), if there are no objections. Please do. I realize we're getting close to a release and we're in feature freeze now, so this may be considered to be too large a change for this round. I think it's a bug and should be fixed anyway. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.rdb bug?
Jeff Rush wrote: Dmitry Vasiliev wrote: David Johnson wrote: I am using the zope database adapter, and on occasion (1/20) the following code intermittently throws an exception (1/20 times), even though the connection is connected. It's a known bug, see http://www.zope.org/Collectors/Zope3-dev/582. The problem is that the adapter sometimes can't be loaded from the ghost state. However, I still can't understand why the connection is closed (or reported as closed) while the request should be still in process... If it's related to persistence, then perhaps a workaround for David in the meantime would be to supply the connector as a global utility not stored in the ZODB. I haven't seen the problem occur here and perhaps that's because I declared my adapter in site.zcml so it never gets ghosted: I guess the adapter should work just fine as global utility, but we need to fix the bug anyway. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: [Zope3-Users] PsycopgDA problem
Stuart Bishop wrote: [moving to zope3-dev] I think I know what might have been going on. The earlier patch neglected to change getEncoding() to always return UTF-8. So the code in zope.app.rdb that encodes the queries was encoding them to whatever getEncoding() happened to return rather than UTF8. Would you be happy with this if it works for you? I agree that the problem possibly was in getEncoding(), unfortunately I didn't have a time to explore the problem deeper. I'll try to return 'SET client_encoding' back and hide the encoding field for psycopgda in a few days. The alternative that meets my requirements would be to make the possible encodings a Choice field of the encodings that recent PostgreSQL supports, (which needs a mapping from the PostgreSQL naming to the Python naming). The default would be UTF-8, and the connection would issue a 'SET client_encoding' statement using the selected encoding rather than trusting that whatever encoding has been selected in Z3 happens to be the default client encoding. There would be a slight performance improvement with this method in the case where a non-UTF8 database could receive data in its native encoding, but I'd personally rather not have the added complexity. I've already thought about the Choice field, but I didn't find the easy way to implement enumeration of the encodings in Python. The getEncoding() approach isn't meaningful with database adapters that accept Unicode strings which is becoming the norm. The idea that database adapters will never be Unicode aware seems to have been embedded into Z3 quite deeply though :-( I guess the 'zope.app.rdb' code is somewhat in beta state so we still need to figure out better approaches, interfaces, etc. I guess we can allow getEncoding() to return None for modern database drivers and make Z3 pass through queries as Unicode or ASCII strings to driver in this case. I'm going to want to make the switch to psycopg2 soon, and I think I'll need to sort this out in Z3 at that point. I think it would be better to add some additional method like 'isUnicodeAware()' because 'getEncoding()' which returns None in the case of unicode aware adapter seems hackish for me. I'm going to want to make the switch to psycopg2 soon, and I think I'll need to sort this out in Z3 at that point. I don't know yet if it will be better to maintain a single psycopgda or if it will be better to split it into two products. I think the single product would be better and more flexible approach, in this case we can select better available underlying adapter at setup-time or/and at run-time. By the way, what do you think about the idea of add DB-API2 compliant exception hierarchy to 'zope.app.rdb'? Adapters will be responsible to translate its exceptions to 'zope.app.rdb' exceptions. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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-dev] Two visions
Lennart Regebro wrote: I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not. +1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reducing the amount of ZCML directives
Philipp von Weitershausen wrote: Hi all, looking for your comments at http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives :) +1 for deprecation of the proposed directives. Also +1 to get rid of 'rdb:gadflyRoot'. I think very few people use 'zope.app.rdb.gadfly' at all since even for test purposes it's so featureless. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release schedule and deprecation decisions
Jim Fulton wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) +1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ Added chapters about the testbrowser to the apidoc book
Benji York wrote:
Dmitry Vasiliev wrote:
Log message for revision 41524:
Added chapters about the testbrowser to the apidoc book
Modified: Zope3/trunk/src/zope/testbrowser/over_the_wire.txt
===
--- Zope3/trunk/src/zope/testbrowser/over_the_wire.txt2006-02-01
08:43:01 UTC (rev 41523)
+++ Zope3/trunk/src/zope/testbrowser/over_the_wire.txt2006-02-01
08:47:13 UTC (rev 41524)
@@ -16,8 +16,8 @@
The browser can `open` web pages:
-# This is tricky, since in Germany I am forwarded to google.de
usually;
-# The `ncr` forces to really go to google.com.
+ # This is tricky, since in Germany I am forwarded to
google.de usually;
+ # The `ncr` forces to really go to google.com.
browser.open('http://google.com/ncr')
browser.url
'http://www.google.com/'
I've been meaning to remove this test and instead start an http server
on a known port and test against it. If you (or anyone else in the
world) wants to beat me to it, feel free.
+100
And also I suggest move all tests from over_the_wire.txt to README.txt.
By the way, what do you think about add FTP handling to
zope.testbrowser.testing.Browser? I think it would be useful feature.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Locale-specific Text Collation
Jim Fulton wrote: A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: undeprecate auto-message id translation
Martijn Faassen wrote: Dmitry Vasiliev wrote: [snip] * currently you can translate any string (not only a message id) like this: p tal:content=string: STRING TO TRANSLATE i18n:translate=/p In this case the string will be automatically converted to message id and then translated. I think we definitely shouldn't translate any string, only message ids. This is an interesting usecase. If I understand you correctly, the question, put a bit broader, is the following: p tal:content=some/call i18n:translate=/p Should this translate whatever string (not message id) is returned from some/call or should it leave it alone? You seem to be arguing it shouldn't. I can also see a usecase where this would be handy -- you can just add the string to your translation dictionary without having to mark anything in your codebase. This is a *disadvantage* if you're already using extraction tools, though. I think only message ids should be translated since you always need to have a message id at some stage anyway to be extracted by i18nextract. Translating a string (not message id) returned by 'tal:content' is just a chortcut for lazy programmers. :-) -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: undeprecate auto-message id translation
Martijn Faassen wrote:
* if a i18n:translate has to be explictily added, extraction tools will
find the i18n:translate= in the ZPT and think there's a message in the
ZPT to translate. But there's not, it's coming from Python code. This
might result in the extraction tool mistakenly extracting dummy text:
p tal:content=context/something i18n:translate=This dummy text is
replaced/p
Unless the tool is so smart it notices this case. Anyway, the tools
already extracted the *real* message anyway.
Currently i18nextract just extracts '${DYNAMIC_CONTENT}' marker for all dynamic
content.
Risks
-
+1 for translate message ids without explicit 'i18n:translate' attribute but
some open questions still remain:
* currently you can translate any string (not only a message id) like this:
p tal:content=string: STRING TO TRANSLATE i18n:translate=/p
In this case the string will be automatically converted to message id and then
translated. I think we definitely shouldn't translate any string, only message ids.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] i18n:translate and tal:content should not use template domain
Jim Fulton wrote: Dmitry Vasiliev wrote: Maybe we should translate *only* a message id values in case of i18n:translate and tal:content/tal:replace and print a warning for any other values? I think we should do the translation in either case. But the translation for a string or a id with an unknown domain should just return the original, with interpolation, if necessary. Perhaps we should have a warning in dev mode. We should also think about how development tools can be used to help with this. The test language support I checked in yesterday should help, I think. Awesome tool! BTW another one use case for ++lang++. ;-) Moreover it's Zope-3.1 behavior. What is Zope-3.1 behavior? I meant in Zope-3.1, only message ids are translatable in case of tal:content/tal:replace. For Zope-3.2 there was a bug report at http://www.zope.org/Collectors/Zope3-dev/455 partially fixed by me. Now I'm not sure the fix was a good idea. Main disadvantage I see is that it leads to bad i18n style for users. This example is particularly agregious. Still, I think your fix is necessary. I think we need better tools for checking i18n and l10n. I'll plan to add a some statistics and warnings for i18nextract. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New database generation for Zope 3.2 (Was: [Zope3-checkins] Added BBB for older instances)
Benji York wrote: Dmitry Vasiliev wrote: BTW, another one idea: We can set a password manager for a principal folder, not for a individual principal, so all principals in the folder will be use the only one password manager. I like that even better. +1 Ok, so I'll redo the implementation and get rid of the generation. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New database generation for Zope 3.2 (Was: [Zope3-checkins] Added BBB for older instances)
Benji York wrote: Dmitry Vasiliev wrote: Dmitry Vasiliev wrote: Oops, we can't get rid of the generation since we need to encode the password anyway... :-/ Even if we default to plain text? Yes. For example if you change the password of a principal it needs to be properly encoded before storing so the password needs to go through aPasswordManager.encodePassword method. I think the only way to get rid of the generation is to use InternalPrincipal.setPassword method inside the views and store the encoded password as InternalPrincipal.password attribute (like before). -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] New database generation for Zope 3.2 (Was: [Zope3-checkins] Added BBB for older instances)
Benji York wrote: Roger Ineichen wrote: Is there a way to evolve during the bootstrap process? Or is the manuel process via the ZMI the right way? If min generation is set properly shouldn't this happen automatically? Yes, but is it right way to set min generation == max generation? What do you think,should I remove the _passwordManagerName class attribute, which will break instances in un-evolved databases. I think a generation is too heavy a fix where a simple class attribute will suffice. I like Roger's fix and propose we remove the generation. No, there is also self.password attribute changed to a property which is not so easy to fix without a generation. I see two alternative possibilities: 1. Custom __getstate__() method; 2. The views may use a methods to get/set self.password attribute; -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Freeze approaching quickly
Stephan Richter wrote: Hi everyone, with October winding down, the freeze on the trunk is coming quickly. So, if you have any outstanding work, now is the time to get it done. During the last week I have monitored the proposals and branches a bit and I think most people are done with their work. After Michael told me that WebDAV has to wait until 3.3., the only outstanding projects are: - Dimitry (hdima): Merge the password manager branch. I know he is close, so I am not worried. Done Once the feature freeze is complete, I would like to keep the trunk frozen for about a month, so that the contribution bar for bug fixes remains as low as possible. And bugs we have plenty. As people start using Zope 3, we have had quiet a number of reports, some of which are really serious, like i18nextract being broken. Thus I propose two bug days: - Firday, November 4, 2005 - Friday, December 2, 2005 What do you guys think? Would people commit time on those days to the effort? I don't know about those days but now I've just switched myself in the bug-fixing mode untill the release. :-) -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] i18n in ZPT half-broken?
Fred Drake wrote: On 9/19/05, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Hi! I'm having trouble getting strings to be translated using tal:content=variable or tal:replace=variable ... according to the documentation, i18n:translate= tal:content=... should translate the evaluated content. ... it works in Zope2, why is it different here? This is a bug. What version of Zope 3 are you using? It would be good if we could track down when the bug was introduced. I don't think it's a bug. tal:content/tal:replace expressions should produce a message id to be translated, there is no implicit creation of a message id from a string. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Philipp von Weitershausen wrote: Martijn suggests to just use user. I can live with that. The reason why I didn't propose that is because I thought people still valued the abstraction of a principal as opposed to the physical person. I don't need it and all those Unix users out there don't seem to need it either... +1 on user. Actually for Russian translation I've used user anyway since I didn't find another good translation for principal. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] The UI grant tool doesn't work for objects without an location
Can someone take a look at the issue 447? http://www.zope.org/Collectors/Zope3-dev/447 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: Build problem
Ruslan Spivak wrote: I think Dmitry used that because of slice assignment and i don't see how it can be done with index assignment of insert(): Yes, definitely. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Build problem
Fred Drake wrote: On 9/2/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: Before the fix (rev. 38239): ['buildsupport', ..., 'src'] After the fix: ['src','buildsupport', ...] Ok, I think I understand this now. Appearantly you have some version of ZConfig installed elsewhere that is getting picked up in the original case. Yes. I was trying to explain this but it seems I couldn't. :-) I now agree that the change is reasonable. It needs a comment that it's protecting against importing *installed* versions of ZConfig. Done at rev. 38287 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Build problem
There is a problem to build extensions for the Zope3 trunk (and I guess for ZODB trunk as well) - all extension module names is lowercased now. For example: gcc -pthread -shared build/temp.linux-i686-2.4/src/persistent/TimeStamp.o -o src/persistent/timestamp.so I guess the problem that the SETUP.cfg's 'extension' section name always lowercased before processing. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Dmitry Vasiliev wrote: Maybe we need always check security map at the root folder? I don't believe this is the solution. Altrough it will solve my example, it wouldn't help in other scenarios. I would eventually make ZopeConnection and ZopeCursor locatable, if they aren't already, and assign the database adapter as the parent of the connection and the connection to the cursor at the time of their creation. Actually I'm going to patch it like that right away. ZopeConnection and ZopeCursor not only an objects without an location, see for example '/++etc++process' so I think it is the UI grant tool problem. I'll post an issue to the collector. One last question, to clear things a bit for me, as I don't have a Zope3 copy here to try - Imagine the user accesses some python class by the means of submiting a form and that class needs to do some work with the database, so it obtains a database connection, creates a cursor and executes some queries. In this case, will the class access the connection with the user's privileges, or is it trusted ? If it is trusted, my problem here is not of so big importance, but if not, I imagine zope.app.rdb needs some urgent updates. I don't believe that I'm currently fully understand whole Z3's security system, :-) but I think you can manage access rights through 'permission' attribute of the form's ZCML directive. For instance in one of my projects there is a pages which use a database connection with 'zope.Public' and 'zope.ManageContent' permissions. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: The problem is easy to reproduce in a few simple steps - assuming clean installation from the .tgz release, here is what I do: 1. create an instance (of course), zope.Manager granted principal is crated by the mkzopeinstance script. 2. uncomment the sample zope.Member principal 'frodo' in principals.zcml and run zope -- using the browser from now on: 3. login with the zope.Manager principal use the grant tool to grant zope.Manager role at the top of the site to the 'frodo' principal 4. go to manage site - site management and add a database adapter, gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp, or any other dir as apropriate 5. login as frodo and go to /++etc++site/tools/yourdbaname 6. select the test page and just click on 'execute' 7. unauthorized 8. if you try (5),(6) with the zope.Manager principal, you will see the database adapter working as expected (producing an error in this example actually, but not 'unauthorized' exception) Ugh. The problem seems is that the UI grant tool work only for locatable objects like folders, pages and so on. For example if you go to /@@grant.html and grant some role/permission for a principal a local security map will be stored in the root folder annotations. Then if you access some folder at /aFolder zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following: 1. check for security map at /aFolder 2. get the aFolder's parent (the root folder in our case) through the '__parent__' attribute 3. check for security map at / 4. check global security map defined through configuration Then global security declarations will be overridden by local security declarations. If object doesn't have a '__parent__' attribute and any associated security map the security check will be based only on global security map. Maybe we need always check security map at the root folder? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Hello, My problems on this subject didn't get resolved since my last post, but I have some new info and questions - The sympthoms (Zope 3.1.0c1): Database adapters are not usable by principals other than the zope.Manager, in the principals.zcml file. Any other principal is unauthenticated - I tried principals.zcml regular user with zope.ManageContent, zope.UseDatabaseConnections and zope.View granted, pluggable authentication user with the zope.Manager role granted, and finally - principals.zcml regular user with zope.Manager role. All principals are able to see and manage the connection object, but can't retrieve results. This is tested and true for both psycopg and Gadfly database adapters. This is the exception I get when trying to use SQL script: * Module zope.app.sqlscript.browser.sqlscript, line 39, in getArguments for argname, argvalue in self.context.getArguments().items(): Unauthorized: (zope.app.sqlscript.sqlscript.Arguments object at 0xa03e86c, 'items', 'zope.ManageContent') This is the excpetion from the test page of the connection object (in /++etc++site/tools) when I use principal with zope.Manager granted: * Module zope.app.rdb, line 372, in queryForResults cursor = conn.cursor() Unauthorized: (zope.app.rdb.ZopeConnection object at 0xad11c2c, 'cursor', 'zope.ManageContent') Hmm... Database adapter working just fine for me. Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) and the ZopeConnection class does not have anything, that deals with security, as far as I can see. See zope/app/rdb/configure.zcml for security declarations. My question is, does this eventually mean, that ZopeConnection objects, which are created at run-time, are not security proxied and consequently unauthorized in all cases (except the system_user) and if yes, what should be done? I'm not familiar with the Zope3 environment and I don't know how and where objects get proxied. Or is there something I'm missing here ? Can you repeat all this experiments on clean Z3 setup (without any additional components and without your old Data.fs file, check also for all possibly conflicting modules on the PYTHONPATH)? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: Input encoding of a PageTemplateFile
Fred Drake wrote: On 7/22/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: I think about the following generic algorithm: 1. Preparation stage. Content type and encoding are determining based on the ?xml?/meta declarations. In case of the 'text/html' type and a not unicoded content we decode the content. In case of the 'text/xml' type the parser takes care of the encoding at the cooking stage. We can do it somewhere inside PageTemplate.pt_edit()/PageTemplate.write() methods. This is probably right; I'll have to look at the code again. 2. Cooking stage. Nothing interested for our case. Wrong; this is when the bytecode is generated. At this point, we can remove the encoding markers (since we've already used them for input). 3. Rendering stage. Now we can strip the ?xml?/meta declarations. We can do it somewhere inside PageTemplate.pt_render()/PageTempalte.__call__() methods. Rendering is the most costly stage, so we want to reduce the work done here. Avoiding it entirely is best. By removing the encoding markers at compilation time, we manage to have nothing else to do at this stage. Ok. Now I think that all this can be done somewhere inside zope.tal. I need to write a proposal... BTW, just curious why we need to read HTML files in the text mode (See PageTemplateFile._read_file())? I don't remember, but it seemed important at the time. It likely has something to do with newline normalization; the XML parser handles that for us since the XML specification requires it to, but the HTML parser doesn't bother. I doubt this is important in practice, but may be relied on in the tests. Maybe we can use universal newlines mode instead? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ++language++ namespace
Stephan Richter wrote: On Monday 01 August 2005 09:09, Dmitry Vasiliev wrote: I want to add language namespace to 'zope.app.traversing.namespace' so someone can override the language settings through URL, like this: http://site.com/++language++ru/path I guess this feature would be useful for sites with selectable languages. Please make this a proposal. It might seem like overkill, but it gives us a better basis for discussion. I've just created the proposal at http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LanguageNamespace -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ++language++ namespace
Hello everyone, I want to add language namespace to 'zope.app.traversing.namespace' so someone can override the language settings through URL, like this: http://site.com/++language++ru/path I guess this feature would be useful for sites with selectable languages. Implementation notes: The simplest code is: def traverse(self, name, ignored): self.request._environ[HTTP_ACCEPT_LANGUAGE] = name return self.context but I don't like it since it seems like a hack. Maybe I need to provide new IUserPreferredLanguages adapter and then return the old one when the request is closed? Thoughts? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] translate() default value
Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: translate() default value
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? I think so. I also don't agree with myself anymore regarding the fixing of issue 298; your proposal sounds a lot better. So, +1 to the change. The question remains what to do on X3.0 branch. Changing the semantics of zope.i18n.translate could already jeopardize backward compatability between X3.0 and 3.1; such a change between X3.0.0 and X3.0.1 could be even be worse... Thoughts? The simplest solution is to change all translate(text) calls to translate(text, default=text). I think we need to do it for 3.1 also. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: translate() default value
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Hi Everyone, In the most cases users of the translate() expect untranslated string will be returned if no translation is performed. See for example Issue #298 (http://www.zope.org/Collectors/Zope3-dev/298). Is this reasonable to change the translate() to return untranslated string by default instead of None? I think so. I also don't agree with myself anymore regarding the fixing of issue 298; your proposal sounds a lot better. So, +1 to the change. The question remains what to do on X3.0 branch. Changing the semantics of zope.i18n.translate could already jeopardize backward compatability between X3.0 and 3.1; such a change between X3.0.0 and X3.0.1 could be even be worse... Thoughts? The simplest solution is to change all translate(text) calls to translate(text, default=text). Ah, when I wrote my original mail I thought of this solution but scrapped it because I didn't think it would work (e.g. think of explicit message ids). By looking at the code of zope.i18n.translate now and a quick test on the interpreter prompt, I think that it'll be appropriate. I think we need to do it for 3.1 also. Well, I dunno... I think changing the behaviour of zope.i18n.translate regarding the default argument should be enough. Explicit defaults where they're not needed are dead chickens. We need the dead chickens for X3.0 but why introduce them for 3.1 as well? Hmm... You're right. Then I'll fix issue #298 both on the trunk and on the branch. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] mysqldbda mysql 4.1 problem
Andy Dustman wrote: On 7/25/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: Andy Dustman wrote: On 7/24/05, Jaroslaw Zabiello [EMAIL PROTECTED] wrote: I have mysql 4.1 with database and all tables set to utf8. I have problems with Zope3.1beta/win32. I cannot query the database with mysqldbda adapter because I get an error: unknown encoding: latin1_swedish_ci. http://bugs.mysql.com/bug.php?id=7891 MySQL-4.1, prior to 4.1.9 (and 5.0.3), returns the collation instead of the character set; that's what you're seeing here. What client version are you running? I assume you have at least MySQL-python-1.2.0; older versions probably won't work with MySQL-4.1 (some 1.1 versions will, but 1.0 will not). I've just added the encoding attribute to the ZopeDatabaseAdapter (rev. 37378). Also I've changed psycopg adapter to respect the attribute. Can someone change mysqldbda to use self.getEncoding() instead of connection.character_set_name()? Note that connection.character_set_name() only retrieves the character set name that is in use. To actually set the character set name, you have to do a bit of SQL; for details see: http://dev.mysql.com/doc/mysql/en/charset-connection.html Also note that this is only applicable to MySQL-4.1 and newer. In 4.0, the character set is a server configuration option and cannot be changed by the client. I've added the encoding attribute to the ZopeDatabaseAdapter (previously there has been hardcoded 'utf-8'). Now when you create the adapter instance you can set the encoding. It's more portable way, since the psycopg for example don't allow to retrieve the database encoding, AFAIK. I don't use MySQL so I'm afraid to change anything without testing. :-) So the question is: Can someone change mysqldbda.py:connection.character_set_name() to self.getEncoding() and then test the changes? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] mysqldbda mysql 4.1 problem
Andy Dustman wrote: On 7/24/05, Jaroslaw Zabiello [EMAIL PROTECTED] wrote: I have mysql 4.1 with database and all tables set to utf8. I have problems with Zope3.1beta/win32. I cannot query the database with mysqldbda adapter because I get an error: unknown encoding: latin1_swedish_ci. http://bugs.mysql.com/bug.php?id=7891 MySQL-4.1, prior to 4.1.9 (and 5.0.3), returns the collation instead of the character set; that's what you're seeing here. What client version are you running? I assume you have at least MySQL-python-1.2.0; older versions probably won't work with MySQL-4.1 (some 1.1 versions will, but 1.0 will not). I've just added the encoding attribute to the ZopeDatabaseAdapter (rev. 37378). Also I've changed psycopg adapter to respect the attribute. Can someone change mysqldbda to use self.getEncoding() instead of connection.character_set_name()? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Input encoding of a PageTemplateFile
Fred Drake wrote: On 7/21/05, Dmitry Vasiliev [EMAIL PROTECTED] wrote: Log message for revision 37358: Now input encoding of a PageTemplateFile in 'html' mode is determined by meta declaration and then the declaration will stripped. Open question: Shouldn't meta/?xml? stripping be in PageTemplate.__call__()? This should be stripped by the compilation phase. Since those should never be part of the output, they need not be represented in the compiled template at all. I think about the following generic algorithm: 1. Preparation stage. Content type and encoding are determining based on the ?xml?/meta declarations. In case of the 'text/html' type and a not unicoded content we decode the content. In case of the 'text/xml' type the parser takes care of the encoding at the cooking stage. We can do it somewhere inside PageTemplate.pt_edit()/PageTemplate.write() methods. 2. Cooking stage. Nothing interested for our case. 3. Rendering stage. Now we can strip the ?xml?/meta declarations. We can do it somewhere inside PageTemplate.pt_render()/PageTempalte.__call__() methods. BTW, just curious why we need to read HTML files in the text mode (See PageTemplateFile._read_file())? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Resource URL's and virtual hosting
Hello! Seems like resource URL's are wrong for virtual hosted sites. For example: 1. Create configure.zcml: configure xmlns=http://namespaces.zope.org/browser; resourceDirectory name=images directory=images / page for=* name=restest.html permission=zope.Public template=test.pt / /configure 2. Create test.pt: h1 tal:content=context/++resource++imagesResource path/h1 3. Create a folder 'test' and make it a site. Then if you go to 'http://localhost:8080/test/++vh++http:localhost:8080/test/++/restest.html' you'll see 'http://localhost:8080/test/@@/images' although expected result is 'http://localhost:8080/@@/images'. Is it a bug or maybe I'm wrong? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Resource URL's and virtual hosting
Albertas Agejevas wrote: On Fri, Jul 15, 2005 at 03:01:11PM +0400, Dmitry Vasiliev wrote: Then if you go to 'http://localhost:8080/test/++vh++http:localhost:8080/test/++/restest.html' you'll see 'http://localhost:8080/test/@@/images' although expected result is 'http://localhost:8080/@@/images'. Is it a bug or maybe I'm wrong? If you want to get http://localhost:8080/@@/images, you should go to http://localhost:8080/test/++vh++http:localhost:8080/++/restest.html AFAIK. The path between the plusses is the URL you want your virtual host to have. Ahh, my bad. I've guessed the path between the pluses is a part of the URL which will be suppressed for the virtual host path. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: tal:replace=default question
Evan Simpson wrote: Paul Winkler wrote: On Fri, May 13, 2005 at 05:39:56PM +0400, Dmitry Vasiliev wrote: 'span tal:content=default42/span' = 'span42/span' 'span tal:replace=default42/span' = '42' +1. IMHO the current behavior is wrong. replace should always replace the element, no exceptions. (Zope 2 has the same bug, I just checked.) You can certainly disagree with this behavior, but it is not a bug. See http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AdvZPT.stx for example, which states that default is A special value that doesn't change anything when used in tal:replace, tal:content, or tal:attributes. It leaves the template text in place. But see also the Omitting Tags section for opposite examples: b tal:omit-tag=ithis/i stays/b Renders to: ithis/i stays At this level of usage, tal:omit-tag operates almost like tal:replace=default. Now in my Z3 sandbox 'tal:replace=value' is just a syntactic sugar for 'tal:content=value tal:omit-tag=' (I guess this is only the way to work around the automatic msgid's translation issue) so I've found the bug. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: MessageID's automatic translation in TAL
Philipp von Weitershausen wrote:
Dmitry Vasiliev wrote:
- Should we do automatic translation for msgid's inside a TALES
expression?
IMO we shouldn't do automatic translation at all.
How then we want to translate TALES expressions like some text ${msgid}?
The only way now is explicit translate() inside the view.
- Maybe we need some new TALES expression type for msgid definition?
For example:
tal:block define=name msgid:Specific
Why? Use case?
See zope/app/apidoc/ifacemodule/iface_macros.pt at the end. With the msgid
type we can define msgid's right in TAL code.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] MessageID's automatic translation in TAL
Stephan Richter wrote: On Friday 06 May 2005 10:11, Dmitry Vasiliev wrote: Opinions? Dimitry, I am sorry. There was already a papal's edict on the issue: http://mail.zope.org/pipermail/zope3-dev/2004-September/012186.html That means, message ids must be translated explicitely using i18n:translate. So, Dimitry, you can go ahead and deprecate the implict tranlation of message ids. Again, I am sorry for the confusion. I had totally forgotten Jim edict. Ok. No problem. Then I'll eliminate all cases of implicit translation. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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: MessageID's automatic translation in TAL
Philipp von Weitershausen wrote: Stephan Richter wrote: On Friday 06 May 2005 10:11, Dmitry Vasiliev wrote: Opinions? Dimitry, I am sorry. There was already a papal's edict on the issue: http://mail.zope.org/pipermail/zope3-dev/2004-September/012186.html That means, message ids must be translated explicitely using i18n:translate. So, Dimitry, you can go ahead and deprecate the implict tranlation of message ids. Great. I guess that also means backing out most of r30249. Yes, and I pretty sure that we'll found much more cases of implicit translation. Btw, I dug through the thread and found an 'interesting' edge case that we might want to look into as well. Imagine you have span tal:content=view/getMeSomeI18nMessage i18n:translate=explicit_message_id / IMO, this shouldn't happen, meaning it should be a syntax error to use tal:content and an explicit message id in i18n:translate in the same tag. Maybe this was already fixed, but I would guess not. The fix will be trivial anyway. A note about the edict: The edict doesn't rule out a change of semantics, provided it was written out in a proposal. For example, thinking about the above edge case, it struck me that i18n:translate is really used for two things: a) Translating a static string in the template p i18n:translate=heading-greetingGreetings, user!/p b) Translating a message id coming from Python code: p tal:content=view/getAnI18nMessage i18n:translate=.../p So, i18n:translate has two different semantics, depending whether you're using it for case a) or b). In case b), for example, stating an explicit message id is nonsense, as I've stated in the edge case above. So, here's an idea: Let's limit the use of i18n:translate to case a) and introduce i18n versions of tal:content and tal:replace that mean insert the message id and translate it. It would look like that: span i18n:content=view/getAnI18nMessage.../span instead of span tal:content=view/getAnI18nMessage i18n:translate=.../span The latter would be deprecated/forbidden. That would get rid of any ambiguity regarding i18n:translate and thus also a lot easier for message id extraction tools. They wouldn't collect false message ids anymore. Also, we could even require the input of i18n:content to always be an i18n message id. So, if view.getAnI18nMessage() return a mere string, it wouldn't be translated. But maybe there are use cases against this. It wouldn't be translated anyway since i18n:content will be only translation phase and we can't define a msgid for dynamic content, we just can pass the string through or raise an error/warning. Thoughts? I like the idea and I'm ready to implement the proposal, but I like to do it after 3.1 will be released. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] MessageID's automatic translation in TAL
Recently Stephan and me have a discussion on the IRC about purpose of i18n:translate attribute for tags with dynamic content through tal:content attribute. Stephan pointed out that i18n:translate in this case is just a marker for call translate() later. But later I discovered that TALInterpreter.do_isertText_tal() does the automatic translation for all MessageID's even when the t18n:translate isn't present. So now the question: Do we need automatic translation for all MessageID's? Stephan also have pointed that automatic translation doesn't allow somebody to disable translation on purpose for some piece of content. I'm personally think that automatic translation would be helpful in some cases. Opinions? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Issue 301
Stephan Richter wrote: On Thursday 28 April 2005 03:59, Dmitry Vasiliev wrote: Ok, I fully agree with this changes, but then I have one more question. Should we do this changes on ZopeX3.0 branch? That about backward compatibility for 3.0, for example if someone use code like this: 'h1 i18n:name=H1foo/h1'? Okay, let's not backport this bug fix. Ugh... Seems like the test29.html was wrong. For following input data: div i18n:translate=At the tone the time will be span i18n:data=here/currentTime i18n:translate=timefmt i18n:name=time2:32 pm/span... beep!/div result was: divAT THE TONE THE TIME WILL BE 59 MINUTES AFTER 6 PM... BEEP!/div but the right result should was be (see zope.tal.driver.TestTranslations): divAT THE TONE THE TIME WILL BE 59 minutes after 6 PM... BEEP!/div Seems like the wrong result was produced by double translate() call. And for new (explicit) i18n:name behaviour result will be: divAT THE TONE THE TIME WILL BE span59 minutes after 6 PM/span... BEEP!/div -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Issue 301
Stephan Richter wrote: Should 'span i18n:name=foobar/span' pass 'spanbar/span' to the msgid mapping or just 'bar'? Wow, so this gets hairy and we need to get it right. Unfortunately, tests right now support both practices. So here are my observations: p i18n:translate= This house is em i18n:name=color i18n:translate=red/em. /p The case above should produce two message ids: This house is $color. red Note: The XML element containing i18n:name is *not* part of the second message id. Also, the em tag is not part of the outer message id. So here is the way to think about this. The I18n name, as seen from the outer translation is the entire em element. However, the em element itself only sends its content out as a message id. Further, there need to be some rules deciding when the em tag should be omitted. I agree with Marius and Godefroid that it should only be omitted when either tal:replace or tal:omit-tag is specified. It thus follows: - test_content_with_messageid_and_i18nname in test_talinterpreter.py is correct. - test36.html is incorrect. - Marius' submitted test is correct. Ok, I fully agree with this changes, but then I have one more question. Should we do this changes on ZopeX3.0 branch? That about backward compatibility for 3.0, for example if someone use code like this: 'h1 i18n:name=H1foo/h1'? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Issue 301
I want to fix Issue 301 Bug with i18n:name and i18n:translate on the same
element (http://www.zope.org/Collectors/Zope3-dev/301) but there are some open
questions...
Should 'span i18n:name=foobar/span' pass 'spanbar/span' to the msgid
mapping or just 'bar'?
In the latter case which additional attributes should preserve the tag in the
msgid mapping? For example:
'span i18n:name=foo i18n:translate=bar/span' = 'bar' (translated)
but
'a href=url i18n:name=foo i18n:translate=bar/a' = 'a
href=urlbar/a' ('bar' translated)
and so on
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
