Converting Currently Existing TG2 Apps into Tortuga Plugins, thoughts?

[Lee Olayvar]

I'd like to start programming some of the plugins i'll be needing for Tortuga now, but given that Tortuga cant handle that currently, any thoughts on how bad it would be to do it strictly in Turbogears?

They are relatively small apps ofcourse, and it would be just that (ie, a special polling plugin, not a whole site to facilitate the poll), so im hoping i can get away with making them for TG2 and then later converting them to Tortuga.

Any thoughts on how hard that would be? Are there some areas of TG2 that i should _not_ use because converting it to Tortuga would be near impossible? ..etc?

Thanks,
--
Lee Olayvar

[Mark Ramm]

From my perspective as a turbogears guy I expect that we'll see:

* a well defined way to use TurboGears to create content for display
in tortuga gadgets.
* a well defined way to embed Tortuga in a larger TurboGears application
* a well defined way to share master templates across an application
where some pages are served by Tortuga and others are served by
TurboGears 2.

This last one may require a bit more explanation. Paste has a cascade
feature where it tries several WSGI applications in order to find out
which one will answer the request. The plan is to be able to use the
paste cascade with Tortuga to allow it the first crack at handling the
request, and then pass control over to TurboGears (or django) to see
if that handles the request.

You do in this case want some consistent styling of pages across
Tortuga+turbogears, which is why sharing some templates may be a good
idea.

I would also expect that we can do some integration the other way round:

* TurboGears applications could render Tortuga Containers and Gadgets.
* Tortuga could "pubish" the sitemap to TurboGears so that we provide
helpers to automatically link to Tortuga content.
* A TurboGears 2 application should be able to be used to create
Tortuga pages, and tortuga content.

Of course all of this is still in flux, and the details will all have
to be hammered out in actual code, but I think all of the above will
actually be pretty easy to implement, and should provide us with most
if not all of the tools we need to make TG2 and Tortuga integration
seem seamless.

--Mark Ramm

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

[Ian Charnas]

I'm committed to working with Mark and the other Turbogears folks to
make as many of these things happen as possible. Right now I'm on
vacation so I don't want to dive into this too deeply.

ian

[Lee Olayvar]

Well i am going to start a couple turbogears apps that i'll be needing in Tortuga. Eventually when the plugin system for tortuga is in the works, i can start converting my turgo-apps to be tortuga plugins. Hopefully i can get some decent chunks of code that wont need complete rewrites.. Seeing as i'll be using a DB, which will need to be converted into tortuga-db, the file system to store audio files, which will need converting to fit with Checkpoint. Ofcourse templating will also be converted, but that should be easy since nothing i am making now will be looking pretty, so templating is not even a concern.

--
Lee Olayvar

[Jorge Vargas]

I know this is the part of things that hasn't been talked about but I
think ideally a tg2 app should be a Tortuga plugin if it quacks like a
duck. Rather than if it extends some class or what not. In other words
if we could build the plugin system in a way that an application which
defines X, where X is a minimum set of rules then it is a Tortuga
plugin (if configured like so) Here is a start on what X should be

1- it defines some entry point (not really on a setuptools kind of
way, but could be) for example set_tortuga_plugin or some callback to
"configure"
2- it defnies a tortuga-like storage, although it could have storage
of it's own, like what you are suggesting now
3- it defines a yet to define signal/event system

in an ideal world I'll like to be able to run a TG2 app standalone but
if tortuga is found and it (the app) understands that then it could be
run as such, with very little configuration. I believe this is very
important to provide a very small learning curve. Ideally this
intergrfation should be almost like WSGI, the simplest api possible
yet the most powerful thing around. Also I'm not saying that we use
WSGI for config I find it clumsy when it comes to configuration, but
we could use something inspired in tg2.configuration (AppConfig) and a
webob-wrapper to generate a dict of info.
,

[Lee Olayvar]

It sounds nice, and i would think something may be possible on that front (but really i have no idea how it would be done), but my thoughts are that integration such as you mentioned can only go so far. Its the little integration stuff that would ultimately make me think a TG2 app would have a hard time integrating into a cms oob. Things like a block in a sidebar of recently posted topics in a forum, or most active forum users, would be harder to integrate imo.

On the otherhand, if an app were to be made both tortuga compliant, and tg2 compliant, that may be handy. Having a forum tg2 app to run standalone, aswell as integrate tightly with tortuga (if installed as a tortuga plugin) would be a nifty.

--
Lee Olayvar

[Ian Charnas]

I want to take more of a 'quacks like a duck' approach. I want plugin
integration to be accomplished mostly through entrypoints. Plugins
can add stuff to the admin interface via entrypoints... they can
modify the url processing method via entrypoints... and so on. When
an entrypoint's output will end up on the web interface, I prefer the
plugin outputs actual html and not some data structure. This avoids
all those ugly hacks you see in other systems when developers try to
trick the system into displaying what they want. Style will be kept
uniform through intelligent use of css.

I don't write interfaces and parent classes and such unless they're
actually *really* necessary, because unnecessary abstraction causes
bloat and ugly hacks when programmers try to get around the interfaces
to accomplish their tasks.

I *do* like to write examples though. Lots and lots of examples. So
developers will get a good foundation on how to write plugins through
the examples, and then they can browse through the "api", which will
consist of config, rendering, database, and what the entrypoints are
and how they work.

[Chris B - JK at asciiking dot com]

On Dec 7, 11:03 am, "Ian Charnas" <ian.char...@gmail.com> wrote:
> I want to take more of a 'quacks like a duck' approach. I want plugin
> integration to be accomplished mostly through entrypoints. Plugins
> can add stuff to the admin interface via entrypoints... they can
> modify the url processing method via entrypoints... and so on. When
> an entrypoint's output will end up on the web interface, I prefer the
> plugin outputs actual html and not some data structure. This avoids
> all those ugly hacks you see in other systems when developers try to
> trick the system into displaying what they want. Style will be kept
> uniform through intelligent use of css.

The reasons for having Tortuga plug-ins go away if they look and act
too much like TurboGears apps or WSGI modules. What makes something a
CMS plug-in as opposed to something, well, not a plug-in is that it
uses the API (that will be) provided and provides functionality that
is relevant to extending CMS functionality. The main thing that I see
writing Tortuga plug-ins for is describing document sets that contain
complex or dynamic data types.

There's a sense in which *any* web app can be construed as a document
set, but pragmatically there may be limits to the situations in which
that is the most productive approach. I don't know what the limits
are, but it's possible. ;-)

> I don't write interfaces and parent classes and such unless they're
> actually *really* necessary, because unnecessary abstraction causes
> bloat and ugly hacks when programmers try to get around the interfaces
> to accomplish their tasks.

The real challenge will be making the interface that is both simple
enough and functional enough to get used. From the TurboGears list,
it's 5 lines of code to embed a WSGI app like Tortuga into a TG app.
Making it look pretty and providing access to the data across those
boundaries is a little more challenging, which is why I'm excited
about this capability in Tortuga. It's one thing to graft an app into
the site tree. It's another thing altogether to have a consistent way
to share both presentation and content.

> I *do* like to write examples though. Lots and lots of examples. So
> developers will get a good foundation on how to write plugins through
> the examples, and then they can browse through the "api", which will
> consist of config, rendering, database, and what the entrypoints are
> and how they work.

For those of us who want to start coding yesterday, I think that the
developers preview already provides important insight into what a CMS
plug-in should do, which is:

1) Provide the stuff that you would type in if you followed the
example. **or**
2) Perform document 'translations', i.e. provide infrastructure for
complex content types to be derived from simple inputs.

In other words, I think that 2 useful likely entry points can be
implied from the example. #1 is pretty straight forward, but #2 is
really exciting. At it's core, building a Tortuga site is going to be
very much likely building a TurboGears site. The content and
presentation of a Tortuga document map to the model and view of the
MVC pattern as implemented in TG2, even using the same APIs (Alchemy
and Genshi). The exciting plug-ins will be those that extend user
defined content types in the way that Tortuga core provides i18n and
workflow.

Simple things that someone like I can do (being longer on
implementation than coding) would be building a pilot site with TG2.
When Tortuga is ready, we've already seen how the template and model
code will be imported.

Much more challenging will be writing the transformational kind of
code that extends the functionality of user content. While the i18n
and workflows provide examples of what we can expect to do with plug-
ins, implementation will be vastly simpler when those classes have
been generalized, i.e. it's probably OK and fun to speculate about
possible applications, but it won't be productive to write code yet.

Which I think brings us back to the original question. If someone
wants to have content ready for Tortuga when it's ready then they can
recycle Alchemy Objects and Genshi Templates from a TG2 app, gaining
some professional features when they do so. If it turns out that the
part of the site already developed won't benefit from Tortuga, but
future development would, then Tortuga can be built as a WSGI app and
called from TG2 or visa versa.

Chris

[Lee Olayvar]

Yea, despite how much i don't want to start programming things that will need to be converted, i think i have to. This stall in early development is killing me hehe.

Anyone know if Tortuga will be using any specific Image/Audio library? I'm assuming PIL for imaging, and for Audio i have specific mp3 tagging needs so i'll probably go with something custom, but i do wanna stick to whatever Tortuga will be using wherever possible.

--
Lee Olayvar

[Ian Charnas]

> Anyone know if Tortuga will be using any specific Image/Audio library? I'm
> assuming PIL for imaging, and for Audio i have specific mp3 tagging needs so
> i'll probably go with something custom, but i do wanna stick to whatever
> Tortuga will be using wherever possible.

I don't imagine Tortuga core will use an Image or Audio library. The
'gallery' plugin would use PIL, unless there's something even better
that I don't know about.

-Ian

[Chris B - JK at asciiking dot com]

On Dec 14, 7:38 am, "Lee Olayvar" <leeolay...@gmail.com> wrote:
> Yea, despite how much i don't want to start programming things that will
> need to be converted, i think i have to. This stall in early development is
> killing me hehe.

I guess what I'm saying is that for the core of a given site,
conversion from TG2 to Tortuga won't be bad. You just give Tortuga
your SQLAlchemy model and your Genshi Template. The only extra work is
writing the controller for it work on TurboGears while you're waiting
for Tortuga; Just look at http://turbogears.com/2.0/docs/ if you think
that is going to be any kind of a hassle.

Chris