Overriding builtin getattr method

[Raja Raman Sundararajan]

Hello guys,
I have data stored in the database which has special characters
like <, > etc.
Case 1: Whenever I wanted to present the output to a browser
I need to escape these special characters into the browser
equivalent like &lt; &gt; etc.( for example by using the cgi module)
Case 2: Whenever I wanted to present the output to some client other
than a browser, I wanted to present the data as it is stored in the
database.

For doing this I thought of overriding the __builtin__.__getattr__
method.
I am wondering if there is any other way of achieving this. I have
loads of files that get the attribute values of objects stored in the
database and I do not want to manually change the way of DB access in
those files. I rather prefer a centralized way to achieve this.

Good inputs are always appreciated.

Raja

 

[Raja Raman Sundararajan]

Correction: I meant __builtin__.getattr method and not the other one I
mentioned.

Thanks
Raja

Raja Raman Sundararajan skrev:

 

[Gabriel Genellina]

Hello guys,
I have data stored in the database which has special characters
like <, > etc.
Case 1: Whenever I wanted to present the output to a browser
I need to escape these special characters into the browser
equivalent like &lt; &gt; etc.( for example by using the cgi module)
Case 2: Whenever I wanted to present the output to some client other
than a browser, I wanted to present the data as it is stored in the
database.

For doing this I thought of overriding the __builtin__.__getattr__
method.

Not very reasonable on the source object itself. Escaping <&> is a
*presentation* requirement and should be managed at that level. For
example, in a PageTemplate, using tal:content or tal:attribute does
the right escaping.

I am wondering if there is any other way of achieving this. I have
loads of files that get the attribute values of objects stored in the
database and I do not want to manually change the way of DB access in
those files. I rather prefer a centralized way to achieve this.

If your data contains a '<', that's OK, it's the real contents and
should remain that way.
If you have to build an HTML page, escape those characters at *that* stage.
If you have to write a CSV file, perhaps a '<' is irrelevant but a
',' is problematic.
For some Windows text controls you have to escape '&' characters.
None of these operations should make you to change your data, or the
way you access your data. You invoke them at the presentation stage,
depending on the final target.



Gabriel Genellina
Softlab SRL






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

 

[Diez B. Roggisch]

I have data stored in the database which has special characters
The centralized approach to this is certainly not achieved by
overloading getattr alone - because even if it was possible to do so
(which it isn't), the implementation needed a way to know when to use
escaping or not. Which would be signaled by some means, e.g. a
thread-local variable or even a global (shudder).

This signal gets set in the code that decides that it wants the data
escaped - or not. And thus the code looks like this:

needs_escaping()
work_with_objects()
no_escaping_anymore()

But that is fragile, think of work_with_objects() throwing an exception
and the no_escaping_anymore() isn't called again.

So the better approach is to gather the data as it is, and when you
transform it to something that requires escaping, do it there.

That means: the way to do it is to use one of the gazillion web
templating systems that already do this escaping for you.

Diez

 

[Raja Raman Sundararajan]

Hello Gabriel Genellina and Diez B. Roggisch,
Thanks for sharing your opinions. I agree with Gabriel when he
talks about the separation between the presentation and the DB level
access and the drawbacks of introducing character manipulation. The
problem that I am facing right now is that the presentation layer uses
several different page rendering machines (about 12).
Some of them use the escaping techniques that presents browser reserved
characters to be "unrunnable" <,> we just some examples, so far so
great. But the other presentation layer engines(about 9) used are basic
(optimized for fast rendering) and do not use such filtering/encoding
mechanisms. Since the amount of files that is used by the "basic"
rendering machines are quite high, I am forced to fix the problem in a
much lower level.

I have found a work around for it...since the pages presented by the
basic rendering machines knows about objects fetched from the DB and
the type of request(which presentation engine to use) generated, I
collect information about these in a struct. This struct also contains
information about the level of encoding needed.

I overrode __getattribute__ method (which is always called when
one fetches an attribute of an object) in the base class and introduced
encoding level in the class. The __getattribute__ then checks for the
level of encoding needed depending on the infor from the struct and
returns the encoded data to the presentation layer when needed. The
business object or the functional layer is unaffected as the default
value returned by the __getattribute__ is the unencoded data from the
DB.

Raja


Diez B. Roggisch skrev: