abstracting frameworks non-goal

[Kevin Dangoor]

On 9/22/05, Jeremy Jones <zane...@bellsouth.net> wrote:
[lots of snippage]
> Isolating the exception into a TG specific exception
> makes more sense to me. It accomplishes the same thing and keeps the
> Pythonicity of the CP redirect. Creating a TG.redirect exception would
> currently get a +0 from me unless there is serious thoughts on going
> with other web frameworks in the future, in which case I would give it a +1.

Since Jeremy brought this up, I figured I'd toss this out for the
record... and yes, I realize that Jeremy is not actually suggesting we
abstract things out. I just want to emphasize this point...

I've seen attempts to abstract out frameworks in Javaland (anything
that involves making more Interfaces must be good, right?), and
they're not pretty.

Abstracting out the major parts of TurboGears (MochiKit, Kid, CherryPy
and SQLObject) in order to be able to theoretically switch them out is
a non-goal. Maybe even an anti-goal.

One strength we have here is that there are other people with
completely different needs using these tools. That means that even as
we work on making things easier and more fun to use in a TurboGears
context, there are other people working on improving CherryPy, for
example, for their own nefarious purposes (bwahahaha). By not hiding
away CP, we're able to make use of improvements as soon as they
appear.

And, if you go to the CP site and find a cool bit of CP code, you
should be able to use that directly with TurboGears without a second
thought.

Things should be wrapped in a TurboGears wrapper if we're adding code
that integrates multiple tools (like the Kid<->CherryPy link that
happens in turbogears.expose).

Kevin

[Fabian Neumann]

Kevin Dangoor wrote:
> I've seen attempts to abstract out frameworks in Javaland (anything
> that involves making more Interfaces must be good, right?), and
> they're not pretty.
>
> Abstracting out the major parts of TurboGears (MochiKit, Kid, CherryPy
> and SQLObject) in order to be able to theoretically switch them out is
> a non-goal. Maybe even an anti-goal.

I second that. I'm not an expert in framework-building, but I say: keep
TurboGears's idea of a megaframework alive (you made quite a buzz by
calling it like this :).

As Kevin says in TG's philosophy statement an important side-goal is to
improve CherryPy, Kid, etc. by the needs that arise from TurboGear's
users. Don't [only] improve the glue, improve the tools!

Ok, I should've read your next paragraph:

> One strength we have here is that there are other people with

> ...

Nothing more to add.

Fabian

[Jeremy Jones]

Kevin Dangoor wrote:

>On 9/22/05, Jeremy Jones <zane...@bellsouth.net> wrote:
>[lots of snippage]
>
>
>> Isolating the exception into a TG specific exception
>>makes more sense to me. It accomplishes the same thing and keeps the
>>Pythonicity of the CP redirect. Creating a TG.redirect exception would
>>currently get a +0 from me unless there is serious thoughts on going
>>with other web frameworks in the future, in which case I would give it a +1.
>>
>>
>
>Since Jeremy brought this up, I figured I'd toss this out for the
>record... and yes, I realize that Jeremy is not actually suggesting we
>abstract things out. I just want to emphasize this point...
>
>I've seen attempts to abstract out frameworks in Javaland (anything
>that involves making more Interfaces must be good, right?), and
>they're not pretty.
>
>Abstracting out the major parts of TurboGears (MochiKit, Kid, CherryPy
>and SQLObject) in order to be able to theoretically switch them out is
>a non-goal. Maybe even an anti-goal.
>
>

Since Fabian already gave a second, I'll give a third. I'll go with
simplicity over *perceived* flexibility, especially when the tools
you've combined *really* do offer tons of flexibility. I like your
position (and choice of words) of "anti-goal".

>One strength we have here is that there are other people with
>completely different needs using these tools. That means that even as
>we work on making things easier and more fun to use in a TurboGears
>context, there are other people working on improving CherryPy, for
>example, for their own nefarious purposes (bwahahaha). By not hiding
>away CP, we're able to make use of improvements as soon as they
>appear.
>
>And, if you go to the CP site and find a cool bit of CP code, you
>should be able to use that directly with TurboGears without a second
>thought.
>
>

You mean you expect cooperation between two open source projects? ;-)
I like that. You don't see that very often in the corporate sector.

>Things should be wrapped in a TurboGears wrapper if we're adding code
>that integrates multiple tools (like the Kid<->CherryPy link that
>happens in turbogears.expose).
>
>Kevin
>
>
>

My optimism and excitement WRT TG increases daily. Thanks, Kevin.


- JMJ