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 )
[Zope-dev] ZPatterns: getItem returns None
I think I've read everything on the mailing lists on this issue, but have found no joy. I have a ZClass derived dataskin called AllotmentArea matching a table with the same name in my SQL RDBMS. I have a Specialist called AllotmentAreas with storage set to the AllotmentArea ZClass and load attribute set to "AllotmentArea_ID" and this property does not exist on the ZClass propertysheet. When I call getItem(existing_id) on the specialist, it returns None. SkinScript for retrieval: WITH QUERY sqlGetAllotmentArea(AllotmentArea_ID = self.id) COMPUTE AllotmentArea_ID, AreaName, AreaCode Note: The Proxy Role for the SkinScript is set to Manager. sqlGetAllotmentArea: Select * from AllotmentArea where AllotmentArea_ID = dtml-sqlvar AllotmentArea_ID type=string Roch ___ 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] Designing ZPatterns/Python-product-based, reusable applications - take 2
Itai Tavor wrote: This brings up another thing that bothers me: When I started learning object models and ZPatterns everyone advocated using Coad notation. Now Peter Coad himself is using UML and you're building TransWarp around UML. Is this a conspiracy to confuse me? ZPatterns is very much about objects and collaborations between objects. The Coad notation is very good for talking about objects like this. TransWarp is more about classes, and generating customized classes from a mixture of existing classes and aspects. You can understand aspects as declarations about how to handle certain kinds of behaviour. UML is very good for talking about classes and the relationships that can exist between objects of particular classes. Often, I tend to think in Coad, but write in UML. -- Steve Alexander Software Engineer Cat-Box limited ___ 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] New Zcatalog bug on b2?
Chris
I also have this error with 2.3.1b2
Here is the line which calls the search:
sr = self.searchResults({'Type' : type, 'sort_on':'lowercase_title_'})
fyi. type = 'TypeTest'
The indexes are as follows:
Status = Text Index
Type = Field Index
Identifier = Field Index
lowercase_title_ = Field Index
parent_identifiers_ = Keyword Index
The meta types are like this:
Title
id
identifier
There are only 13 records in the catalog.
Cheers
-Andy
Chris McDonough wrote:
Julio,
Can you give us the actual index names that you're putting in the request to
search against, the query values you're passing in to each index, and the
contents of the sort_on parameter for that request? What kinds of indexes
are referred to by each of the index names in the query?
- Original Message -
From: "Jlio Dinis Silva" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 16, 2001 2:28 PM
Subject: [Zope-dev] New Zcatalog bug on b2?
When passing in the REQUEST the var sort_on into the
searchREsults method I get this error:
Zope Errorr
Zope has encountered an error while publishing this resource.
Error Type: TypeError
Error Value: len() of unsized object
With this traceback:
Traceback (innermost last):
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py,
line 223, in publish_module
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py,
line 187, in publish
File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Zope/__init__.py,
line 221, in zpublisher_exception_hook
(Object: Traversable)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py,
line 171, in publish
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/mapply.py,
line
160, in mapply
(Object: executeSearch)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py,
line 112, in call_object
(Object: executeSearch)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/OFS/DTMLMethod.py,
line 189, in __call__
(Object: executeSearch)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_String
.py,
line 538, in __call__
(Object: executeSearch)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Let.py
,
line 146, in render
(Object: Results="Catalog(REQUEST=REQUEST)")
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Util.p
y,
line 334, in eval
(Object: Catalog(REQUEST=REQUEST))
(Info: REQUEST)
File string, line 0, in ?
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/ZCatalog
.py,
line 530, in searchResults
(Object: Traversable)
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.
py,
line 654, in searchResults
File
/usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.
py,
line 591, in _indexedSearch
TypeError: (see above)
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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 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] ZPatterns: getItem returns None
On Sat, 17 Mar 2001, Roch'e Compaan wrote: When I call getItem(existing_id) on the specialist, it returns None. In my experience, getItem will return None if *anything* goes wrong with data retieval or object creation. Sometimes you get a traceback in the STUPID_LOG, and sometimes you don't (and I haven't figured out the pattern yet). Test everything you can independently, and simplify everything to the bare minimum until you get it to work, and then add back the other variables, etc. --RDM ___ 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 )
Object serialization (was Re: [Zope-dev] FTP interface being worked on?)
I hope folks don't mind if I resume the object serialization thread on
the mailing list.
Chris McDonough wrote:
I wonder if yet another interface is really required. If you think
about it, isn't the FTP interface basically a file system serialization
format?
Yes! [...] It's probably not even fair to call this kind of
serialization "filesystem serialization" because it's the sort of
representation of objects that can be used by FTP, WebDAV, etc. It's just a
human-readable representation of Zope objects that fits into a
filesystem-like model that attempts to preserve most object information
(although there's no guarantee that it won't be lossy).
The "no guarantee" lossy part bothers me.
For our purposes, we'd like to see lossless serialization that provides
full control over objects through FTP, WebDAV, etc.
Lossy serialization will cause problems for round tripping objects, i.e.
getting them out of the object database, updating them, then putting
them back in.
One of our goals is to be able to use CVS to track our updates and
distribute our object database. We definitely do not want to be losing
information through serialization.
I understand your point about having each object's serialization "look
like" that kind of object, but isn't there also some value in the
consistency of XML representing every kind of object? For automated
tools, it seems like an XML representation is a great idea, and one that
could be exploited with a good client-side tool that understands the
Zope ODB DTD.
Yes, and this is great for XML export. But I see filesystem serialization
and XML export as different things.
No disagreement here. I wouldn't want to have to deal with the XML
representation when I'm using an FTP or WebDAV client.
Zope already has a little-known XML
format for representing python objects ("ppml", Python Pickle Markup
Language), which is the format which XML exports are done in. But when
developers work with filesystem reps of objects, I'd hate for them to have
to work with it.
Good point. So the XML format stays monothilic (i.e an XML export of
the root object creates one big file, not a directory full of
sub-directories and files representing objects) and when you want to
deal with files and directories you don't get the XML format, you get
something else.
That means that each object needs to support two serialization formats:
XML and the "filesystem serialization" format.
So I basically see three interfaces as necessary and sufficient:
1) XHTML - gets you started, can manage things with a browser
2) FTP - serialization to and from a filesystem
3) XML - the advanced management interface, easy to automate
To elaborate, first, the existing FTP serialization format could be
enhanced to be this "filesystem serialization" format.
Second, the XML serialization format could be the basis for some
sophisticated client side management tools based on XML-RPC. Unlike the
existing HTML (or XHTML) client side management interface, an XML
management interface could leverage XML libraries for parsing serialized
object data, and for communicating with Zope via XML-RPC.
Wow! Looks like you're planning ahead. I probably won't be available for a
little while (I'm off this week), but hopefully I can get that proposal
cleaned up and on the fishbowl and we can resume this discussion in that
Wiki.
Okay, I'll try to deal with the Wiki. But I have to admit that I find
the Wiki interface painful. Is it okay to keep using the mailing list
for discussions like this? I assume the keeper of the Wiki can copy and
paste useful bits into the Wiki as the mood strikes them.
Fred
--
Fred Wilson Horch mailto:[EMAIL PROTECTED]
Executive Director, EcoAccess http://ecoaccess.org/
P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354
___
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] FTP interface being worked on?
Hi again, I'm commenting by e-mail because the Wiki interface is too horrible for me to face on a Saturday night when I should be doing other things. ;-) Chris McDonough wrote: I've put the proposal up at http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst em. Let me know what you think! This is a great start. My major question is I don't understand the design decision to allow lossy representation. Seems to me this is a recipe for disaster. You aren't working with Microsoft on this one, are you? ;-) Will there be some undocumented API call that only Zope employees know about to get the serialized lossless representation? ;-) The proposal states in part: "Lossless" general serialization is not an explicit goal. If a developer wishes to make his or her object serializable to a directory structure, he or she will need to implement methods of an API on the object instance which allow it to be represented adequately enough to be reconstructable into its original Python representation when it's "imported". If this API is not implemented by the developer, the result is undefined I think lossless serialization should be an explicit goal. If a developer doesn't provide specific object serialization methods, then a default method (perhaps XML) should be invoked that is lossless even if hard to work with. The worst thing you can do is make some things hidden in the ZODB and only available through a certain interface. The whole point for us is to get full control of our objects through CVS. I need to get started on something for our project so we can manage our objects via CVS by the beginning of May. I have taken a look at http://www.zope.org/Members/tseaver/FSDump and http://www.zope.org/Members/sspickle/ZCVSMixin. Can anyone tell me where my effort would best be spent? Would it be best for me to start with FSDump or ZCVSMixin and corrupt them to serve my evil plans, or should I start from scratch based on the object serialization discussion we've been having (but with the explicit goal of lossless serialization, unlike Chris' proposal)? To understand what I want to do, you can read my two project proposals at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/ftp_access/?cvsroot=ecoaccess http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/proposals/xml_rpc/?cvsroot=ecoaccess Thanks in advance for any advice! Fred -- Fred Wilson Horch mailto:[EMAIL PROTECTED] Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8354 ___ 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 )
