This is more a factor of how TurboBlog is written than of how
TurboGears itself works.

you could easily have a turboblog class that you import and
instantiate in your root controller that does all the request
handling, and a module of model objects that you import in model.py to
get the model working.   Ultimately this could be 2-4 lines of code to
plug the blog into your application.

In TG2 you can also load a bunch of WSGI applications together into
one site using the Paste Deploy composite wsgi app stuff.  This allows
you to mount various TG2 (or other wsgi apps) at various points in the
tree and have them all work together to provide a bigger site.

http://pythonpaste.org/deploy/#composite-applications

There's even a tool Deliverance that allows you to theme all of your
"composite apps" in the same way, and even lets you build sites that
include stuff from  non-python, non-wsgi applicatons -- as long as
they output HTML.

http://deliverance.openplans.org/configuration.html#rule-and-theme

One of the things we have to do, and have to do better than we've been
doing is to make this stuff accessible to more people, and to make a
stronger attempt at making one "right" way to do it, and to focus our
attention on creating better docs for some of this stuff.

As I see it the problem is not that this is hard to do, but that it's
hard to make everybody do it the same way, and that we haven't made it
obvious how to do it.

--Mark Ramm


On Tue, Nov 4, 2008 at 1:35 AM, vandevel <[EMAIL PROTECTED]> wrote:
>
> Specifically, it is my understanding that Turbogears provides no
> standard mechanism for "plugging in" new functionality.
> For example, lets say I have an existing Turbogears site and I need
> blog functionality. Sure I could use Turboblog
> but I would either have merge my existing site with the Turboblog
> codebase or I would have to host the blog as a distinct app.
> Using Django for example, I have the option of plugging in a blog app
> such as basic blog or banjo without too much fuss.
> It may very well be that Turbogears does in fact provide this
> functionality, but if so, there is no obvious indication that it is
> possible.
>
>
>
> On Nov 3, 3:57 pm, "Mark Ramm" <[EMAIL PROTECTED]> wrote:
>> > As much as I had enjoyed using Turbogears for the past couple of
>> > years, I had moved on to django because django
>> > offered more flexibility in terms of developing component based
>> > applications. Turbogears simply does not provide the facilities
>> > that would allow one to harness components in an extensible manner.
>>
>> I think this last bit deserves a little more detail.   What exactly
>> are you saying that TurboGears does not allow?
>>
>> This is not some kind of rhetorical question, I would very much like
>> to know what you think is missing from TG or TG2 that django provides.
>>
>> To me it seems like the turbogears registration module, silverplate,
>> and others have shown that this is possible, even if it's not been
>> done as much as it has in Django, and even if the way to do this stuff
>> may not be as well documented or as obvious as it is in Django (which
>> I admit are significant issues that we need to resolve).
>>
>> ---Mark
> >
>



-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" 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?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to