Only with these options: 1) Controllers as the subway way (not classes) 2) Cheetah and not kid 3) Other subway features
Or even let the user choose what components to use. The web app should then support as many items as it can, providing an abstract layer for each of them. For example - FormEncode/Atocha - Cheetah/Kid - Class controllers/Filesystem controllers - and so on...
Another thing... the tg administration interfaces (like catwalk and i18n) must be closed for now until products are in.
On 12/17/05, Peter Hunt <floydoph...@gmail.com> wrote:
Peter Hunt wrote: > Thoughts? I am in support of it.
I'm extremely happy you're in support of unfication.
To begin with, the lead developers of Subway, Turbogears, SQLObject/FormEncode, and Cherrypy [1] should get together for some kind of chat or IRC session and hash out an agreement on principle issues such as
- If there is a shared desire to work together towards one megaframework - Division of responsibilities - Architectural issues (WSGI support, etc) - User Marketing Strategy: How to attract further developers to the cause. - How to do it better than RoR - Possible fundraising from python users - etc...
[1] and perhaps some of the Templating module authors, but that may be premature at this stage.
> Peter Hunt wrote: > > Thoughts? I am in support of it.
> I'm extremely happy you're in support of unfication.
> To begin with, the lead developers of Subway, Turbogears, > SQLObject/FormEncode, and Cherrypy [1] should get together for some > kind of chat or IRC session and hash out an agreement on principle > issues such as
> - If there is a shared desire to work together towards one > megaframework > - Division of responsibilities > - Architectural issues (WSGI support, etc) > - User Marketing Strategy: How to attract further developers to the > cause. > - How to do it better than RoR > - Possible fundraising from python users > - etc...
> [1] and perhaps some of the Templating module authors, but that may be > premature at this stage.
Lethalman wrote: > Only with these options: > 1) Controllers as the subway way (not classes)
My impression is that there's not a huge commitment to the class structure in TG, but the decorators are pretty essential. That doesn't seem incompatible with Subway.
> 2) Cheetah and not kid
There's no way they'll switch to Kid. But configurable templates (or just noticing .tmpl on a filename) is quite possible. I think with some of these things the issue isn't technical, but documentation. They (well, mostly Kevin) don't/doesn't want to document things in a piecemeal fashion, or add complexity by presenting different options at each turn.
> 3) Other subway features
Well sure, this is the thing you are offering in return for other compromises ;) Kevin has added a bunch of developers fairly quickly, so I don't think he's overly protective either.
Another option is for Subway's model to become another flavor instead of a separate framework. If you use Cheetah, for instance, that might just mean different scaffolding. Though, all considered, that's the only really substantive difference I see. I think controller differences should be resolveable. They aren't using schemabuilder in TG and some other stuff, but even if that overlaps with other developments there I see no reason why there wouldn't be room for both.
Anyway, if you guys want to move forward on this you should probably move on this fast, since TurboGears is trying to quickly reach 1.0, and the APIs are calcifying quickly as a result.
> Only with these options: > 1) Controllers as the subway way (not classes) > 2) Cheetah and not kid > 3) Other subway features
> Or even let the user choose what components to use. The web app should > then support as many items as it can, providing an abstract layer for > each of them. For example > - FormEncode/Atocha > - Cheetah/Kid > - Class controllers/Filesystem controllers > - and so on... > Another thing... the tg administration interfaces (like catwalk and > i18n) must be closed for now until products are in.
Wow, I think the TurboGears folks are interested in exploring the possibility of a project merge, but this seems like quite a large list of up-front non-negotiable items.
Before we get mired in the discussion of these points, perhaps we ought to take a step back:
1) What can the TurboGears project gain from merging with subway?
2) What can the SubWay project gain from merging with TurboGears?
3) What can the python community gain from these two projects merging?
As a TurboGears and Python user, I feel like I am best equipped to answer questions 2 and 3. But I think we need good answers to all there of these questions if there is any chance to make this merger fly.
I promise to write more on questions 2 and 3 this evening. But for now, anybody have from this list have some good ideas for answering question 1?
hi I come from TG, about your post could you elaborated a little more on
Lethalman wrote: > Only with these options: > 1) Controllers as the subway way (not classes) > 2) Cheetah and not kid
why if cheetah and I quote "Cheetah should make code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates." you don't use classes for the controller?
> Or even let the user choose what components to use. The web app should > then support as many items as it can, providing an abstract layer for > each of them. For example > - FormEncode/Atocha > - Cheetah/Kid > - Class controllers/Filesystem controllers > - and so on...
That could be a solution but we need to think that will require a lot since everything will have to be check a lot, and we will provide more then one way to do the same thing, which is an overkill. On the other hand one of the things about TG is aims to use the best for each part of it.
> Another thing... the tg administration interfaces (like catwalk and > i18n) must be closed for now until products are in.
Mark Ramm wrote: >>Only with these options: >>1) Controllers as the subway way (not classes) >>2) Cheetah and not kid >>3) Other subway features
>>Or even let the user choose what components to use. The web app should >>then support as many items as it can, providing an abstract layer for >>each of them. For example >>- FormEncode/Atocha >>- Cheetah/Kid >>- Class controllers/Filesystem controllers >>- and so on...
>>Another thing... the tg administration interfaces (like catwalk and >>i18n) must be closed for now until products are in.
>Wow, I think the TurboGears folks are interested in exploring the >possibility of a project merge, but this seems like quite a large list >of up-front non-negotiable items.
>Before we get mired in the discussion of these points, perhaps we >ought to take a step back:
>1) What can the TurboGears project gain from merging with subway?
>2) What can the SubWay project gain from merging with TurboGears?
>3) What can the python community gain from these two projects merging?
>As a TurboGears and Python user, I feel like I am best equipped to >answer questions 2 and 3. But I think we need good answers to all >there of these questions if there is any chance to make this merger >fly.
>I promise to write more on questions 2 and 3 this evening. But for >now, anybody have from this list have some good ideas for answering >question 1?
>--Mark Ramm
1) Subway features which TurboGears has not 2) Popularity 3) All in one web frameworks
jorge.var...@gmail.com wrote: >hi I come from TG, about your post could you elaborated a little more >on
>Lethalman wrote:
>>Only with these options: >>1) Controllers as the subway way (not classes) >>2) Cheetah and not kid
>why if cheetah and I quote "Cheetah should make code reuse easy by >providing an object-oriented interface to templates that is accessible >from Python code or other Cheetah templates." you don't use classes for >the controller?
Ok, no problems... sometimes classes are better. This is not the main problem...
> >1) What can the TurboGears project gain from merging with subway? > >2) What can the SubWay project gain from merging with TurboGears? > >3) What can the python community gain from these two projects merging? > 1) Subway features which TurboGears has not > 2) Popularity > 3) All in one web frameworks
OK, 2 and 3 are very understandable to me. can you help me understand 1 better?
I'm sure Kevin is all for adding new features which Subway has and TurboGears has not, but what are they?
My main concern is that if we accommodate to the "everything has to work with cheetah and controllers can optionally not be classes" it will hugely slow down TurboGears development, make testing very difficult. This has to be weighed against what subway and the subway developers can bring to the table.
I think the idea is great, but the devil is going to be in the details.
Mark Ramm wrote: >>>1) What can the TurboGears project gain from merging with subway?
>>>2) What can the SubWay project gain from merging with TurboGears?
>>>3) What can the python community gain from these two projects merging?
>>1) Subway features which TurboGears has not >>2) Popularity >>3) All in one web frameworks
>OK, 2 and 3 are very understandable to me. can you help me understand >1 better?
2) Subway is more code-featured against TurboGears but marketing has gone to TG 3) Create and collaborate to a unique framework so users don't get painfully on choosing and increase development
>I'm sure Kevin is all for adding new features which Subway has and >TurboGears has not, but what are they?
Form handling, cherryflow and other small things...
>My main concern is that if we accommodate to the "everything has to >work with cheetah and controllers can optionally not be classes" it >will hugely slow down TurboGears development, make testing very >difficult. This has to be weighed against what subway and the subway >developers can bring to the table.
Code is not a problem... much of the Subway code is made for non-class controllers.
I notice that this thread says that the marketing has gone to TG. I only started using TG a few weeks ago. When I was looking for a Python framework, it was mainly the difference in the 2 websites that sold me.
Subway's website is a lot of text. Few images much less screencasts. Documentation, howto's, etc are harder to find. It may have more features but I was not able to determine that at a glance.
TG has done a better job with documentation. It can be a lot better but that is in process. I am really looking forward to the next few devcasts because I really don't understand formencode.
aw wrote: >I notice that this thread says that the marketing has gone to TG. I >only started using TG a few weeks ago. When I was looking for a Python >framework, it was mainly the difference in the 2 websites that sold me.
>Subway's website is a lot of text. Few images much less screencasts. >Documentation, howto's, etc are harder to find. It may have more >features but I was not able to determine that at a glance.
>TG has done a better job with documentation. It can be a lot better >but that is in process. I am really looking forward to the next few >devcasts because I really don't understand formencode.
I don't have any non-negotiable items. I'm willing to talk it over.
TurboGears has a lot to gain from Subway. We do form handling in a pretty unique and convenient way, and we also have CherryFlow. Controllers are also automatically set up instead of manually added on the tree, and I think this is an important feature TG is lacking.
I think we should have an IRC meeting of everyone concerned.
> I notice that this thread says that the marketing has gone to TG. I > only started using TG a few weeks ago. When I was looking for a Python > framework, it was mainly the difference in the 2 websites that sold me.
> Subway's website is a lot of text. Few images much less screencasts. > Documentation, howto's, etc are harder to find. It may have more > features but I was not able to determine that at a glance.
> TG has done a better job with documentation. It can be a lot better > but that is in process. I am really looking forward to the next few > devcasts because I really don't understand formencode.
