#825: [PATCH] fix saprovider + finalize abstraction
--------------------------------+-------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: anonymous
Type: defect | Status: new
Priority: normal | Milestone: 1.0b1
Component: TurboGears | Version: 0.9a5
Severity: normal | Resolution:
Keywords: |
--------------------------------+-------------------------------------------
Comment (by [EMAIL PROTECTED]):
a- _ is currently being used both in the PEP style word_seperation and as
a semantic identifier for a join in visit_identity. i don't care which
one is more important to tg , but you can't use two conflicting naming
conventions. i'm just trying to clean it up -- some parts of code suggest
use in one context, others in another. if i look at a new db and i see a
visit table, a identity table, and a visit_identity table, i'm going to
assume that _ is being used to mark joins. if i open up tg and see
pep_style_variable_naming and then see visit_identity, i'm going to assume
that visit_identity is not an associative table. using both contexts is
confusing.
b- Removing classes because they are available in the model --> What about
backwards compatibility?
that was already decided in .9a5 to be irrelevant. if you look at the
SOprovider in trunk, you'll see that all the classes were already stripped
out and forced into model.py necessitating an upgrade. i migrated that
change to SA. also to note though, SO provider still has tg_permissions
in there, which is also in model.py -- i think someone forgot to delete
that.
c- i used "tbl _ _" as a prefix to show that the variable just held a
table definition. as the table was already prefixed with "tg _", i
thought it would be sloppy and misleading to prefix it "tbl_tg_". since
the class was named TG_Visit , i thought it would be even more confusing
to name it tg_visit , so "tbl__", which semantically says "hey, its a
table" to the next person who looks at that code was an obvious choice.
d- identity.on = False for static -->This prevent people from direct
linking to your static resources.
no, it causes a database hit on every page for every resource. have some
gifs + css on your page? there's a db query for each one. i averaged 24
database calls per page for identity alone. Thats completely unnecessary.
if you have static resources that you want to lock down, its 2 lines in
app.config to lock it down to put it back in on a per-directory basis (
some sort of image directory or otherwise ) .
e- i didn't rename any classes. i just renamed some variables used to
lookup classes
--
Ticket URL: <http://trac.turbogears.org/turbogears/ticket/825>
TurboGears <http://www.turbogears.org/>
TurboGears front-to-back web development
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Tickets" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-tickets
-~----------~----~----~----~------~----~------~--~---
