#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 godoy):
Too many things for me again, so I'll just comment a few of them.
- Class naming convention -> We are pursuing PEP8 recommendations, so
there is the rule that should apply to our code in TG. Independente code
(widgets, plugins, etc.) aren't tied to this commitment, but code written
for TG should be changing and being written following these rules.
- Using "_" gives the idea of a JOIN --> Not to me. Neither in the naming
scheme I and other developers and DBAs here use, so this is really
subjective.
- Changing class names --> I don't see why it needs to be done, specially
with things that aren't exposed (visit and identity are tied internally,
you don't have to have visit to have identity -- just if you use it as one
of the means to find if a user is authenticated or not).
- Removing classes because they are available in the model --> What about
backwards compatibility? People who started their projects earlier should
do what? You've removed something that they didn't have to care before,
but now they need to look in the old version's code, find where what they
need is defined, copy it to their model.py and then they'll be able to
have their functionality back.
- Making the same functionality available for SO and SA --> I'm +1 for
patches that do that and only that, i.e., no renaming, no relocation.
This is a first step. Renaming, relocation, etc. is a second step and
should be done thinking about existent applications.
- Factoring code and reusing already existing code --> I'm +1 for patches
for that as well. Specially if all tests passes and there's no drawback
on that approach (sometimes code reuse bring collateral effects and code
duplication is intentional).
- Fixing table creation --> I'm +1 for a patch for that and only that,
without any renaming. Renamings should be done later, in a separate batch
of changes.
- Using "__" as in "tbl__tgvisit" --> I don't like and don't see a reason
for it. What is the meaning of "__" here? Python has special meanings
for "__" prefixing a name, making it private, "_" making it non-public.
Those are conventions widely used in Python code and I believe it is a
good thing to stick to them, since this is widely documented. But it is
just my opinion, I don't speak officially for TG or for the other
developers.
- identity.on = False for static --> I'm against that, at least another
person on the mailing list was as well. This prevent people from direct
linking to your static resources. A patch for the docs talking about this
possibility is welcome, but I don't believe that it should be changed in
the configuration files.
- Too many things to read and comment on a web interface is a really bad
and annoying thing. Discussions like that would be much more productive
at the trunk mailing list with an hyperlink here pointing to the
discussion. Decisions should be placed back here either as patches,
commit notes or even some text, just for feedback.
- These are mine and mine only opinions. Other people might agree or not
with this...
--
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
-~----------~----~----~----~------~----~------~--~---
