Hi all! How can I control the way an attribute of a product is readed? __getattr__? __getattribute__? I try the __getattribute__ way but it modifies the property pages Example: I create an object instance of the product and like: Property1 = 'Some text' Property2 = 2006-10-18 I would like to call Property2 like object.Property2 and retrieve the data with the current locale For spanish locale I would like to retrieve 18-10-2006 But if I read the property pages of this object I would like to conserve the given data Is this possible? Thanks! -- Mis Cosas http://blogs.sistes.net/Garito
--On 18. Oktober 2006 16:15:37 +0200 Garito <garito@sistes.net> wrote:
Hi all!
How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
I try the __getattribute__ way but it modifies the property pages
Example:
I create an object instance of the product and like:
Property1 = 'Some text' Property2 = 2006-10-18
I would like to call Property2 like
object.Property2 and retrieve the data with the current locale
Don't do that. Make a clear separation between the storage layer and any kind of presentation issues. If you need your internal data represented in a fancy way, write a dedicated accessor method and use this one inside your templates (or whatever) instead of accessing the data directly. -aj
Andreas Jung escribió:
--On 18. Oktober 2006 16:15:37 +0200 Garito <garito@sistes.net> wrote:
Hi all!
How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
I try the __getattribute__ way but it modifies the property pages
Example:
I create an object instance of the product and like:
Property1 = 'Some text' Property2 = 2006-10-18
I would like to call Property2 like
object.Property2 and retrieve the data with the current locale
Don't do that. Make a clear separation between the storage layer and any kind of presentation issues. If you need your internal data represented in a fancy way, write a dedicated accessor method and use this one inside your templates (or whatever) instead of accessing the data directly.
-aj
Then I can't create a property that stores a tal expression for example? I would like to write things like: object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona' and ask it like: print object.property -> 'Barcelona' or <tal:city tal:replace='here/property' /> -> 'Barcelona' Is this possible? Thanks!!! -- Mis Cosas http://blogs.sistes.net/Garito
--On 18. Oktober 2006 18:53:05 +0200 Garito <garito@sistes.net> wrote:
Andreas Jung escribió:
--On 18. Oktober 2006 16:15:37 +0200 Garito <garito@sistes.net> wrote:
Hi all!
How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
I try the __getattribute__ way but it modifies the property pages
Example:
I create an object instance of the product and like:
Property1 = 'Some text' Property2 = 2006-10-18
I would like to call Property2 like
object.Property2 and retrieve the data with the current locale
Don't do that. Make a clear separation between the storage layer and any kind of presentation issues. If you need your internal data represented in a fancy way, write a dedicated accessor method and use this one inside your templates (or whatever) instead of accessing the data directly.
-aj
Then I can't create a property that stores a tal expression for example?
I would like to write things like:
object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona'
and ask it like:
print object.property -> 'Barcelona'
or
<tal:city tal:replace='here/property' /> -> 'Barcelona'
This posting is totally weird. Sorry, but I have really no idea what you're trying to do. It makes absolutely no sense. -aj
Andreas Jung escribió:
--On 18. Oktober 2006 18:53:05 +0200 Garito <garito@sistes.net> wrote:
Andreas Jung escribió:
--On 18. Oktober 2006 16:15:37 +0200 Garito <garito@sistes.net> wrote:
Hi all!
How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
I try the __getattribute__ way but it modifies the property pages
Example:
I create an object instance of the product and like:
Property1 = 'Some text' Property2 = 2006-10-18
I would like to call Property2 like
object.Property2 and retrieve the data with the current locale
Don't do that. Make a clear separation between the storage layer and any kind of presentation issues. If you need your internal data represented in a fancy way, write a dedicated accessor method and use this one inside your templates (or whatever) instead of accessing the data directly.
-aj
Then I can't create a property that stores a tal expression for example?
I would like to write things like:
object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona'
and ask it like:
print object.property -> 'Barcelona'
or
<tal:city tal:replace='here/property' /> -> 'Barcelona'
This posting is totally weird. Sorry, but I have really no idea what you're trying to do. It makes absolutely no sense.
-aj
I only try to create a model but I'm searching the best way to create it I try to create properties "like" this is (in the last example): object.property "is like" object.anotherproperty Is this possible? -- Mis Cosas http://blogs.sistes.net/Garito
--On 18. Oktober 2006 19:17:42 +0200 Garito <garito@sistes.net> wrote:
I only try to create a model but I'm searching the best way to create it
I try to create properties "like" this is (in the last example):
object.property "is like" object.anotherproperty
You got already multiple advices. Write a method "anotherproperty()" and do whatever you like with in this method. You can call it from TALES as here/anotherproperty. TALES bascially deals with attributes and methods in the same way. -aj
Andreas Jung escribió:
--On 18. Oktober 2006 19:17:42 +0200 Garito <garito@sistes.net> wrote:
I only try to create a model but I'm searching the best way to create it
I try to create properties "like" this is (in the last example):
object.property "is like" object.anotherproperty
You got already multiple advices. Write a method "anotherproperty()" and do whatever you like with in this method. You can call it from TALES as here/anotherproperty. TALES bascially deals with attributes and methods in the same way.
-aj
Sure! But I need to write a method for every "like" property but I would like (if is possible) a way to evaluate if a property is a TALES property automatically Perhaps the property could begin like "tal:<expression" If a property begins with "tal:" I would like to pre-process automatically Is this possible? -- Mis Cosas http://blogs.sistes.net/Garito
--On 18. Oktober 2006 19:41:07 +0200 Garito <garito@sistes.net> wrote:
You got already multiple advices. Write a method "anotherproperty()" and do whatever you like with in this method. You can call it from TALES as here/anotherproperty. TALES bascially deals with attributes and methods in the same way.
-aj
Sure! But I need to write a method for every "like" property but I would like (if is possible) a way to evaluate if a property is a TALES property automatically
Do you *really*, *really*, *really* need this feature? You can of course implement your own __getattr__() method....but every Python programmer would likely slap you left and right...these are the last comments on this issue.. it's still to weird in my opinion. -aj
Andreas Jung escribió:
--On 18. Oktober 2006 19:41:07 +0200 Garito <garito@sistes.net> wrote:
You got already multiple advices. Write a method "anotherproperty()" and do whatever you like with in this method. You can call it from TALES as here/anotherproperty. TALES bascially deals with attributes and methods in the same way.
-aj
Sure! But I need to write a method for every "like" property but I would like (if is possible) a way to evaluate if a property is a TALES property automatically
Do you *really*, *really*, *really* need this feature? You can of course implement your own __getattr__() method....but every Python programmer would likely slap you left and right...these are the last comments on this issue.. it's still to weird in my opinion.
-aj
Yes I think about __getattr__() method but I don't have any idea about how to retrive the original property And another question about this is if implementing __getattr__ method the property manager works ok or not (for me works ok if property manager displays the tal expression instead of the process of the expression will __getattr_ be the method I'm looking for? Thanks Aj and sorry for my weird questions -- Mis Cosas http://blogs.sistes.net/Garito
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Oct 2006, at 12:53, Garito wrote:
Then I can't create a property that stores a tal expression for example?
I would like to write things like:
object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona'
and ask it like:
print object.property -> 'Barcelona'
or
<tal:city tal:replace='here/property' /> -> 'Barcelona'
Google for ComputedAttribute. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFNmNuRAx5nvEhZLIRAkRcAJ4lfb9YMZGCgMnyhwokS9b9JocsEQCdEMh1 FSIjkr9Ijvr6LpR1vIPXrHI= =ugZY -----END PGP SIGNATURE-----
Hi Garito, I saw in another thread you still need this. If I'm not wrong what you are pretending is to somehow render zpt on the fly. So, here is my idea:
I would like to write things like:
object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona'
and ask it like:
print object.property -> 'Barcelona'
or
<tal:city tal:replace='here/property' /> -> 'Barcelona'
Is this possible? I think you could perhaps create a new class to store the tal expression attributes, let's say you called it ExpressionAttribute. This class must be callable and be able to evaluate tal expressions. This is a small sketch of how I think it should look like:
from Products.PageTemplates.ZopeTemplate import ZopeTemplate class ExpressionAttribute: #Here I also assume that you only enter the expressions #without html and the tal part, like: 'here/property' #Please also noticed that all sintax errors in your zpt #code must be catched somewhere def __init__(self, id, talExpr): self.talExpr = '<span tal:replace="%s"/>' % talExpr #I'm not sure about this, but I think it will create a Template on #the fly. self.zpt = ZopePageTemplate(id, text = self.talExpr) #Note: I really don't know if you have to pass other parameters to #pt_render, ie: the container of your property. You will have to test #this. def __call__(self): return self.zpt.pt_render() Then, in the __init__ of your zope product you will need to do things like this: class YourProd(...): def __init__(self,prop1,prop2,prop3,...): #This is a normal property self.prop1 = prop1 #This two are tal expression properties self.prop2 = ExpressionAttribute(prop1) self.prop3 = ExpressionAttribute(prop1) Then, I guess you can call it as: yourProdObj.prop3 or in tal: here/prop3 I'm not sure about what I wrote and if this is what you are looking for. I just hope it helps. Regards Josef
Josef Meile escribió:
Hi Garito,
I saw in another thread you still need this. If I'm not wrong what you are pretending is to somehow render zpt on the fly. So, here is my idea:
I would like to write things like:
object.property = 'here/anotherproperty' object.anotherproperty = 'Barcelona'
and ask it like:
print object.property -> 'Barcelona'
or
<tal:city tal:replace='here/property' /> -> 'Barcelona'
Is this possible? I think you could perhaps create a new class to store the tal expression attributes, let's say you called it ExpressionAttribute. This class must be callable and be able to evaluate tal expressions. This is a small sketch of how I think it should look like:
from Products.PageTemplates.ZopeTemplate import ZopeTemplate
class ExpressionAttribute: #Here I also assume that you only enter the expressions #without html and the tal part, like: 'here/property' #Please also noticed that all sintax errors in your zpt #code must be catched somewhere def __init__(self, id, talExpr): self.talExpr = '<span tal:replace="%s"/>' % talExpr
#I'm not sure about this, but I think it will create a Template on #the fly. self.zpt = ZopePageTemplate(id, text = self.talExpr)
#Note: I really don't know if you have to pass other parameters to #pt_render, ie: the container of your property. You will have to test #this. def __call__(self): return self.zpt.pt_render()
Then, in the __init__ of your zope product you will need to do things like this:
class YourProd(...): def __init__(self,prop1,prop2,prop3,...): #This is a normal property self.prop1 = prop1
#This two are tal expression properties self.prop2 = ExpressionAttribute(prop1) self.prop3 = ExpressionAttribute(prop1)
Then, I guess you can call it as: yourProdObj.prop3 or in tal: here/prop3
I'm not sure about what I wrote and if this is what you are looking for. I just hope it helps.
Regards Josef _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) Hi, Josef! Thank you for your help but I think your aproach is a little complicate I'm asking for this because it seems to be the simplest way (at least in my brain)
I prefer the new aproach I'm searching for (see "How to create a new TAL statement?" thread) But thank you so much for your idea!!! -- Mis Cosas http://blogs.sistes.net/Garito
----- Original Message ----- From: "Garito" <garito@sistes.net> To: "Lista Zope Internacional" <zope@zope.org> Sent: Wednesday, October 18, 2006 10:15 AM Subject: [Zope] How to do...
Hi all!
How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
I try the __getattribute__ way but it modifies the property pages
Example:
I create an object instance of the product and like:
Property1 = 'Some text' Property2 = 2006-10-18
I would like to call Property2 like
object.Property2 and retrieve the data with the current locale
For spanish locale I would like to retrieve 18-10-2006
But if I read the property pages of this object I would like to conserve the given data
Is this possible?
Reading/displaying stored data should not change the stored data! You should determine what internal data storage format you want and keep it consistent. When you retrieve data for presentation/display you can reformat the data prior to display (eg. for localization), but you should not overwrite the stored data with the new format (this will cause you serious difficulties as your data 'reading' routines will never know what format the data is stored in - unless you also store some formatting information, but in most cases this is a bad idea!) Jonathan
Garito wrote at 2006-10-18 16:15 +0200:
... How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
A "product" is an extension mechanism for Zope. Usually, a "product" does not have attributes (you are interested in). But inside your product you may have defined classes instances of which you place into the Zope hierarchy (<http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html> speaks about site building objects). The standard Python way to access their attributes ("__getattr__" and "__getattribute__") will work but has caveats: It is *very* easy to create infinite loops with it and their "self" with not be acquisition wrapped. The Zope specific safer way is to implement "__bobo_traverse__". Both the publisher as well as "[un]restrictedTraverse" (which is internally used by TALES path expressions) use "__bobo_traverse__" when defined. However, Python's "getattr" will not use it. -- Dieter
Dieter Maurer escribió:
Garito wrote at 2006-10-18 16:15 +0200:
... How can I control the way an attribute of a product is readed? __getattr__? __getattribute__?
A "product" is an extension mechanism for Zope. Usually, a "product" does not have attributes (you are interested in).
But inside your product you may have defined classes instances of which you place into the Zope hierarchy (<http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html> speaks about site building objects).
The standard Python way to access their attributes ("__getattr__" and "__getattribute__") will work but has caveats: It is *very* easy to create infinite loops with it and their "self" with not be acquisition wrapped.
The Zope specific safer way is to implement "__bobo_traverse__". Both the publisher as well as "[un]restrictedTraverse" (which is internally used by TALES path expressions) use "__bobo_traverse__" when defined. However, Python's "getattr" will not use it.
Hi, Dieter! How can I create an accessor to read (not to write) and preprocess all properties? Thanks! -- Mis Cosas http://blogs.sistes.net/Garito
Garito wrote at 2006-10-18 20:27 +0200:
.... How can I create an accessor to read (not to write) and preprocess all properties?
If you are only willing to write a single method that should do for all properties, then you will need to use "__getattr__". You remember I have warned you: "__getattr__" is difficult and error prone! Even me, I have spend hours to understand why I get occasional "__getattr__" infinite loops... And I know, in principle, all the potential caveats... -- Dieter
Dieter Maurer escribió:
Garito wrote at 2006-10-18 20:27 +0200:
.... How can I create an accessor to read (not to write) and preprocess all properties?
If you are only willing to write a single method that should do for all properties, then you will need to use "__getattr__".
You remember I have warned you: "__getattr__" is difficult and error prone!
Even me, I have spend hours to understand why I get occasional "__getattr__" infinite loops... And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors? Thanks a lot! -- Mis Cosas http://blogs.sistes.net/Garito
--On 20. Oktober 2006 14:20:51 +0200 Garito <garito@sistes.net> wrote:
And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors?
You got already multiple useful advices how to proceed. Take one! Follow the road that almost all reasonable Zope developers would use: write your own accessor methods or use ComputedAttribute or work with Python properties. But you should forget your (weird) idea. Get it out of your head. Now! -aj
Andreas Jung escribió:
--On 20. Oktober 2006 14:20:51 +0200 Garito <garito@sistes.net> wrote:
And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors?
You got already multiple useful advices how to proceed. Take one! Follow the road that almost all reasonable Zope developers would use: write your own accessor methods or use ComputedAttribute or work with Python properties. But you should forget your (weird) idea. Get it out of your head. Now!
-aj
Sorry but you don't know the whole project If there are a test to do I'll do it because I need to evaluate if Zope is my solution or not There are things on Zope that I like a lot but there are things I don't If Zope is not my solution I need to found the right solution No weird anything: Zope could do the work or not, easy, don't you thing so? Perhaps Zope 3? I don't know (I'm asking to you) But, please, don't tell me to forget my idea is like if I tell you what I think about the things I don't like about Zope and the I says: Zopers, forget Zope because I don't like ZClass or DTML Sorry again (for my expressions fault) -- Mis Cosas http://blogs.sistes.net/Garito
--On 20. Oktober 2006 14:41:58 +0200 Garito <garito@sistes.net> wrote:
-aj
Sorry but you don't know the whole project
No project can be as scary as your requirements of your original posting :-)
If there are a test to do I'll do it because I need to evaluate if Zope is my solution or not
Zope and Python are likely a prefect choice to your (unknown) problem but you need to understand some basic principles of both.
But, please, don't tell me to forget my idea is like if I tell you what I think about the things I don't like about Zope and the I says: Zopers, forget Zope because I don't like ZClass or DTML
So why don't you follow the "standard" way? Dieter pointed you using __getattr__() but I doubt that it is the right choice for you because you with your small Python background you will definitely run into problems that will be hard for you to be resolved on your own. So take the common road. This is less painful. -aj
Andreas Jung escribió:
--On 20. Oktober 2006 14:41:58 +0200 Garito <garito@sistes.net> wrote:
-aj
Sorry but you don't know the whole project
No project can be as scary as your requirements of your original posting :-)
If there are a test to do I'll do it because I need to evaluate if Zope is my solution or not
Zope and Python are likely a prefect choice to your (unknown) problem but you need to understand some basic principles of both.
But, please, don't tell me to forget my idea is like if I tell you what I think about the things I don't like about Zope and the I says: Zopers, forget Zope because I don't like ZClass or DTML
So why don't you follow the "standard" way? Dieter pointed you using __getattr__() but I doubt that it is the right choice for you because you with your small Python background you will definitely run into problems that will be hard for you to be resolved on your own. So take the common road. This is less painful.
-aj
I agree with you: my Python background is uncompleted but I'll learn Python/Zope as deep as I need to create the product I'm looking for There are some Zope standard ways to do the job but my experience tells me to avoid some programmers responsability because programmers make mistakes (I know it because I make mistakes ;-) ) The requieriment of my product is to be simple to use even if the morphology of this product is a little hard or weird The simplest way is to implement the "general accessor" as I thing but I don't know if Zope do it possible If not I can find another way to do the same but the accessor way seems the *simplest* one I try to find the mother cell to describe *every* entity. Is that goal what is weird but, boys, weird problems wants weird solutions Perhaps new ways begins as weird projects If you thing __getattr__ will be the solutions perhaps I could try it but if you point me to avoid the recursive problems I could do the job Can you point me to a product or a paper to understand the __getattr__ problems? Thanks!!!!! -- Mis Cosas http://blogs.sistes.net/Garito
--On 20. Oktober 2006 15:08:26 +0200 Garito <garito@sistes.net> wrote:
If you thing __getattr__ will be the solutions perhaps I could try it but if you point me to avoid the recursive problems I could do the job
Can you point me to a product or a paper to understand the __getattr__ problems?
Dieter told you already that you will into infinite recursions when accessing attrs of the same instance within __getattr__(). You should be able to find about related threads by using Google. I hope you can extract the magic Google words from this thread. -aj
Andreas Jung escribió:
--On 20. Oktober 2006 15:08:26 +0200 Garito <garito@sistes.net> wrote:
If you thing __getattr__ will be the solutions perhaps I could try it but if you point me to avoid the recursive problems I could do the job
Can you point me to a product or a paper to understand the __getattr__ problems?
Dieter told you already that you will into infinite recursions when accessing attrs of the same instance within __getattr__(). You should be able to find about related threads by using Google. I hope you can extract the magic Google words from this thread.
-aj
A, ok! Sure I'll search at google and I'll be back with more explicit questions Thanks a lot! -- Mis Cosas http://blogs.sistes.net/Garito
Garito wrote at 2006-10-20 14:20 +0200:
Dieter Maurer escribió:
You remember I have warned you: "__getattr__" is difficult and error prone!
Even me, I have spend hours to understand why I get occasional "__getattr__" infinite loops... And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors?
It is quite difficult to learn all kinds of problems from an example. I think I already have publicly described my "__getattr__" problems. Thus, you can search the mailing list archive... An example product where "__getattr__" is used is "BTreeFolder2". -- Dieter
Dieter Maurer escribió:
Garito wrote at 2006-10-20 14:20 +0200:
Dieter Maurer escribió:
You remember I have warned you: "__getattr__" is difficult and error prone!
Even me, I have spend hours to understand why I get occasional "__getattr__" infinite loops... And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors?
It is quite difficult to learn all kinds of problems from an example.
I think I already have publicly described my "__getattr__" problems. Thus, you can search the mailing list archive...
An example product where "__getattr__" is used is "BTreeFolder2".
Thank you! I'll try and I will be back with new questions!! -- Mis Cosas http://blogs.sistes.net/Garito
Forgive my ignorance, I have a question. If I set the 'security' setting in internet options : 'Open files based on content not file extension' to Disable and the try to access a page rendered by python script then I get the following javascript error on the page: "This content might not be displayed properly.The file was restricted because the content does'nt match its security information" But if I enable the settings in Internet Options-->Security, ie 'Open files based on content not file extension' then the above error does not occur There seems a conflict between the extension type set by Zope and the MIME in Internet Explorer as it is seeing it has a script. How can I resolve the error , keeping the property 'Open files based on content not file extension' to Disable ? Do I have to set the MIME types in every file or it could be set at a single location in some zope configuration file? Any help would be appreciated. Thanks Sudesh ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Garito" <garito@sistes.net> Cc: "Lista Zope Internacional" <zope@zope.org> Sent: Friday, October 20, 2006 12:10 PM Subject: Re: [Zope] How to do...
Garito wrote at 2006-10-20 14:20 +0200:
Dieter Maurer escribió:
You remember I have warned you: "__getattr__" is difficult and error prone!
Even me, I have spend hours to understand why I get occasional "__getattr__" infinite loops... And I know, in principle, all the potential caveats...
Can you point me to some example/product to try to avoid this kind of errors?
It is quite difficult to learn all kinds of problems from an example.
I think I already have publicly described my "__getattr__" problems. Thus, you can search the mailing list archive...
An example product where "__getattr__" is used is "BTreeFolder2".
-- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On 27. Dezember 2006 16:11:15 -0500 Sudesh soni <sudesh.soni@ebusinessware.com> wrote:
Forgive my ignorance, I have a question.
If I set the 'security' setting in internet options :
'Open files based on content not file extension' to Disable
and the try to access a page rendered by python script then I get the following javascript error on the page:
"This content might not be displayed properly.The file was restricted because the content does'nt match its security information"
But if I enable the settings in Internet Options-->Security, ie 'Open files based on content not file extension' then the above error does not occur
There seems a conflict between the extension type set by Zope and the MIME in Internet Explorer as it is seeing it has a script.
How can I resolve the error , keeping the property 'Open files based on content not file extension' to Disable ?
Do I have to set the MIME types in every file or it could be set at a single location in some zope configuration file?
IE's behavior is stupid and broken in many way. Not only different IE versions behave differently but also it depends on the Windows version. One of the stupid errors I've encountered lately: you write a script to generate a CSV file, you set the proper mime-type however IE does not recognize the response a CSV as long the URL *including* the query string does not end with '.csv'. - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFk3a3CJIWIbr9KYwRAqmzAJsH0ZmqRyoI+oRguOFiiwa9ET9QrgCeMebc J/HPU6I/N6CgmLKPNnKdOvc= =Ks6D -----END PGP SIGNATURE-----
Sudesh soni wrote at 2006-12-27 16:11 -0500:
Forgive my ignorance, I have a question.
If I set the 'security' setting in internet options :
'Open files based on content not file extension' to Disable
and the try to access a page rendered by python script then I get the following javascript error on the page:
"This content might not be displayed properly.The file was restricted because the content does'nt match its security information"
You have told your browser that the file type is determined by the "file" extension. This might mean that all your urls need to end in the proper extension, i.e. ".js" for Javascript. While file extensions might be nice on the desktop, it may be less nice on the Internet where we do not (yet) have full compatibility with MS desktop standards (such as specific extensions to indicate type). -- Dieter
Garito wrote:
object.Property2 and retrieve the data with the current locale
For spanish locale I would like to retrieve 18-10-2006
Rather than torturing yourself with all this weirdness, maybe you should look at using Zope 3's locale support in your app, whether it's zope 2 or zope 3... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers escribió:
Garito wrote:
object.Property2 and retrieve the data with the current locale
For spanish locale I would like to retrieve 18-10-2006
Rather than torturing yourself with all this weirdness, maybe you should look at using Zope 3's locale support in your app, whether it's zope 2 or zope 3...
cheers,
Chris
Sure, but I don't need only localization, I need to preprocess the properties before read them Is this possible? -- Mis Cosas http://blogs.sistes.net/Garito
----- Original Message ----- From: "Garito" <garito@sistes.net> To: "Chris Withers" <chris@simplistix.co.uk> Cc: "Lista Zope Internacional" <zope@zope.org> Sent: Thursday, October 19, 2006 8:46 AM Subject: Re: [Zope] How to do...
Chris Withers escribió:
Garito wrote:
object.Property2 and retrieve the data with the current locale
For spanish locale I would like to retrieve 18-10-2006
Rather than torturing yourself with all this weirdness, maybe you should look at using Zope 3's locale support in your app, whether it's zope 2 or zope 3...
cheers,
Chris
Sure, but I don't need only localization, I need to preprocess the properties before read them
Is this possible?
I am not sure what you mean when you say you want to preprocess the properties before reading them. There are 2 possible cases (that I can think of) in which preprocessing could occur: 1) in response to a user request, you access the stored data, process the data, then display the data. However, you are still 'reading' the data before you can process it. 2) you need to process stored data as a result of some external or timed event (ie. not in response to a user request). In this case you use cron/wget/stepper/etc. to activate a routine which accesses the stored data, processes the data, saves the data (either overwriting the old data or creating a new data element). However, you are still 'reading' the data before you can process it. Before you can process data you need to 'read' (access) the data. If you mean something different when you say 'read' let us know, it may eliminate some confusion! Jonathan
Garito wrote:
Sure, but I don't need only localization, I need to preprocess the properties before read them
I'm afraid your entire approach is likely to end you in a world of pain... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (8)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Garito -
Jens Vagelpohl -
Jonathan -
Josef Meile -
Sudesh soni