R: [Zope-dev] Playing with DateTime
Hello well, my idea was, as I said, to create a pubblic interface called DateTime, and then wrap mxDateTime or other forms behind it. This will make it fully compatible with the existing DC implementation. Then if soembody like me needs a more flexible implementation, as in my case a class that accepts and returns things in the central european format, then he/she can decide whatever or not use this implementation. Best regards Stefano -Messaggio originale- Da: Brian Lloyd [mailto:[EMAIL PROTECTED]] Inviato: venerd 16 marzo 2001 20.09 A: Christian Scholz; Casey Duncan Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Oggetto: RE: [Zope-dev] Playing with DateTime IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope. I think a product that adds mxDateTime to the _ variable would be your best bet. Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this. Note the "DC needs to decide..." only applies to what we decide to integrate (and thus sign up to maintain, at some level) into the core. One of the key goals of our long-term strategy of becoming much more component-oriented is that the "marketplace" (aka the community) decides what the best component is for a given task. And we do not have to wait for the full component story to land for this to happen; as noted, I'm sure someone could come up with a product that "componentizes" mxDateTime in some way so that people who prefer it can use it easily. Time and de facto usage would then tell whether we (DC) should consider some sort of transition - and we can learn whether that would be a good idea without inconveniencing those who prefer to continue using the built-in DateTime in the meantime. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
Hello Stefano, I used mxDateTime about two years ago, when I worked with Bobo, the move to Zope brought lots of advantages, the only thing I missed was mxDateTime. The discussion about DateTime comes to the mailing lists between time to time, you can look what has already been said about it in the archives, for example: http://lists.zope.org/pipermail/zope/2000-May/108798.html http://lists.zope.org/pipermail/zope/2000-September/118269.html Yes, switching to mxDateTime would require a lot of work in Zope and also would break lots of products and web sites, while patching DateTime is a more quick(dirty) solution. IMHO there're no good arguments against reusing a so good piece of code, in the long term at least; mxDateTime is the standard in the python community, only zopers use something else; and it's free software: if the original developer does not support it anymore others can do it. But I understant that if you only want to fix something it's more quick to patch DateTime. best regards, jdavid ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
"[EMAIL PROTECTED]" wrote: Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope. I think a product that adds mxDateTime to the _ variable would be your best bet. My $.02 -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
Hi! IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope. I think a product that adds mxDateTime to the _ variable would be your best bet. Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this. -- christian -- COM.lounge http://comlounge.net/ communication design [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Playing with DateTime
IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope. I think a product that adds mxDateTime to the _ variable would be your best bet. Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this. Note the "DC needs to decide..." only applies to what we decide to integrate (and thus sign up to maintain, at some level) into the core. One of the key goals of our long-term strategy of becoming much more component-oriented is that the "marketplace" (aka the community) decides what the best component is for a given task. And we do not have to wait for the full component story to land for this to happen; as noted, I'm sure someone could come up with a product that "componentizes" mxDateTime in some way so that people who prefer it can use it easily. Time and de facto usage would then tell whether we (DC) should consider some sort of transition - and we can learn whether that would be a good idea without inconveniencing those who prefer to continue using the built-in DateTime in the meantime. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
Hello,
Of course, we already can use mxDateTime in our own products. But
there is a problem, both modules have the same name, if you write
"import DateTime" you get the Zope's DateTime module.
A solution is to rename the mxDateTime module directory from
DateTime to, for example, mxDateTime, then use "import mxDateTime"
and everything is fine. Unfortunetaly this could break other
python programs.
I've played for several hours with imp, __import__, sys, etc..
but haven't been able to import mxDateTime as it's installed.
If somebody knows how to do it please let me know.
We also could build a python product (a Zope component as Brian
suggests), it would be just a copy of mxDateTime. This is not very
elegant because you could need two copies of mxDateTime, one for
the Zope and one for other python programs. And it wouldn't be so
easy to install because mxDateTime has C code that needs to be
compiled.
Another posibility is to use a symbolic link:
$ cd INSTANCE_HOME/Products
$ ln -s wherever the mxDateTime module is mxDateTime
And then use "from Products import mxDateTime". Windows users
still would need to copy the directory.
The (small) problem with this solution is that requires some
work of the user/admin that would be nice to avoid.
The following code automates the creation of the sym. link:
import imp, os, string, sys
filename = os.path.join(INSTANCE_HOME, 'Products', 'mxDateTime')
if not os.path.isdir(filename):
## Find the path to the mxDateTime module
path = filter(lambda x, find=string.find: find(x, 'zope') == -1, sys.path)
file, pathname, description = imp.find_module('DateTime', path)
## Create the symlink
os.symlink(pathname, filename)
from Products import mxDateTime
But I still don't like this solution. If somebody comes to something better
please let me know. Improvements to that code are also very welcomed, I want
to use mxDateTime for the upcomoing new version of the CalendarTag.
Also, perhaps DC could do something to avoid the name conflict for a future
Zope release, :)
best regards,
jdavid
Note the "DC needs to decide..." only applies to what we
decide to integrate (and thus sign up to maintain, at some
level) into the core. One of the key goals of our long-term
strategy of becoming much more component-oriented is that
the "marketplace" (aka the community) decides what the best
component is for a given task.
And we do not have to wait for the full component story to
land for this to happen; as noted, I'm sure someone could
come up with a product that "componentizes" mxDateTime in
some way so that people who prefer it can use it easily.
Time and de facto usage would then tell whether we (DC) should
consider some sort of transition - and we can learn whether
that would be a good idea without inconveniencing those who
prefer to continue using the built-in DateTime in the meantime.
Brian Lloyd[EMAIL PROTECTED]
Software Engineer 540.371.6909
Digital Creations http://www.digicool.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Playing with DateTime
Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
Hello, IMHO the long term solution would be to use the mxDateTime [1] module instead of the DateTime module that currently uses Zope. best regards, jdavid [1] http://www.lemburg.com/files/python/mxDateTime.html Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Playing with DateTime
Ola Juan I think that, while on one side is very comfortable to recycle others code, there should have been a very good reason for DC to develop that class. I had the impression that the class is heavily used in the internals of Zope, and probably the integration of an external module would mean a major redesign issue. Always in my opinion, in the long run automaintained code can be easier to leverage and adapt. In the end, if the original developer does not support the code anymore or change it in a way that is not possible to upgrade, DC will have major problems. The idea of developing an internal class is, for me, a good point. However, I think that DC did not approached the international subject simply because, as far as I understood, Zope was build on the American market. While they should be terribly proud of the magnificent product thay have done, in future they will be facing more and more the problem of other countries using it. This is why I am looking to fix the DateTime class starting from their code. This problem will occur also for the formatting of values, for instance. As far as I have seen, when you ask Zope to return a number formatted as currency, you get it in dollars, with the "." and "," used where central europeans put them the other way around. I do not know if DC or somebody else is already approaching this issue, and I admit that I have looked around but I haven't found anything about this, but I am pretty sure that the european developers like me and you which are trying to find a RAD for the internet, will find Zope as one of the best products, and the spread of it will sooner or later raise more and more problems on this side. I was asking this on the ml because I am considering proposing a project on this, but I wanted to be sure that this was not already been done somewhere else Best regards Stefano Vedovelli Hello, IMHO the long term solution would be to use the mxDateTime [1] module instead of the DateTime module that currently uses Zope. best regards, jdavid [1] http://www.lemburg.com/files/python/mxDateTime.html Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
