[tg-trunk] Re: #803 ExtendingVisitFramework

Sun, 30 Apr 2006 16:22:28 -0700

On 4/30/06, jvanasco <[EMAIL PROTECTED]> wrote:

well my main reason for suggesting it is that right now , its the only
'hardcoded' and required element to turbogears. 

got a point there

 everything else is
fully customized and adaptable ( ie, thanks to sqlalchemy support you
could migrate an existing app to TG without any change to your DB )

if there's a hook to do a change to visit tracking, then TG becomes a
full on 100% adaptable integration framework.

but again, visit is so simple, do you have a use case where you will need more from visit then what it provides right now?

i've been working on fixing identity all morning  (SA support was
broken.  now its fixed ) - and there's some code in the SO and SA
providers that uses internal classes ( TG_ -- i believe this is for
backwards compatibility ) if a user/group/permission class is not
defined in app.cfg

yes that's what that cherry py get request does.

-- visit could use the same principle: offer an
override class + hook funcitons in model.py, or just use the defaults.
it would be a whole lot cleaner and more efficient than the current
plugin system.

again is this needed?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk
-~----------~----~----~----~------~----~------~--~---

Reply via email to