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:
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 < > 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__.__g etattr__
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.
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_objec ts()
no_escaping_any more()
But that is fragile, think of work_with_objec ts() throwing an exception
and the no_escaping_any more() 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