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__.__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.
>
> 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
--
http://mail.python.org/mailman/listinfo/python-list
