Choose A or B, C or D, and E or F
Eric Hawthorne
I thought turbogears was supposed to be a best-of-breed vertical glueing meta-framework
WITH AN OPINION !
This is certainly why I chose it. Yet going forward, we have:
A or B. SQLObject (simple, limited) or SQLAlchemy (complex, powerful, choice-laden)
C or D. ToscaWidgets vs TGWidgets
E or F. Kid (simple, limited?) or Genshi (some kind of swiss-army knife of templating?)
Quoting re: kid or genshi "So if you can't make the decision, you could try both of them in a
short time. and you'll find they are almost the same in syntax."
Ok I recognize that "Best of Breed" might evolve, but this has to be managed oh so
carefully so as not to alienate developers who've made a heavy investment in using
your previous opinion of what was best-of-breed. The decisions about B.O.B. in TG have
to be so good that they can be stuck with and fully supported with enthusiasm for,
say, at least 3 years!!!!
Not a complaint, just a caution intended to be constructive.
(UNNECESSARY) CHOICE IS BAD. COMPLEXITY IS A CANCER THAT MULTIPLIES AND KILLS
How can TG's roadmap be managed so as to eliminate the need for new and existing developers
(users of the meta-framework) to make choices and
change choices, in areas where it's arguably "6 of one and a half-dozen of the other" ?
Kenneth McDonald
> ... The decisions about B.O.B. in TG have
> to be so good that they can be stuck with and fully supported with
> enthusiasm for,
> say, at least 3 years!!!!
Seriously, I don't know of any Web framework that remains reasonably
stable over
a three year period. The best you can hope for is that the old features
are retained so
your legacy code still functions, which seems likely in this case.
Personally, I've never used templating engines and don't like them. I
think they combine
all of the problems of debugging HTML/CSS _and_ all of the problems of
debugging your
development language, without any of the editor etc. support. Easier to
just code (on the
server side) a markup language similar to (on the client side) Bob
Ippolito's MochiKit.dom.
Though it would be nice if a standard package for that emerged.
Hope you find what you're looking for,
Ken
Eric Hawthorne
which may explain my desire to see a modicum of stability in the tools
support. Some tools achieve this. E.g. the Java platform as a whole,
and the Eclipse IDE. They improve, but they stick with their key
decisions for long enough that you can plan a real-sized project
around it. Now python web dev is the bees knees, but I'm just trying
to point out that the major value in Turbogears is in fact its ability
to get out of your way in an elegant fashion and let you code the
business logic and the look and feel of your webapp. No fuss, no muss
with the "standard" internal concerns, thanks to a lot of hard work on
several peoples' part. But the idea should definitely NOT be to get
every web app
developer involved in key architectural decisions again. The idea ought to be to
handle a lot of that for them. Let's specialize the innovation. Some
for infrastructure
improvement, and some for new wild app development. If I need to make
so many architectural subchoices (rather than just the wise choice to
select Turbogears), then
heck I may as well just go back to choosing from all the ugly variants
of Java web framework layers.
Ed Singleton
Turbogears doesn't change quick enough. It will probably be quite a
while until SQLAlchemy is the main ORM. I think the very nature of TG
is that it is suited to people who like to be fairly cutting edge.
If you want stability, then Java is definitely a much better language
to work in.
Choice is good. Complexity is fun.
Ed
Dominique Eav
> (...)
> If I need to make
> so many architectural subchoices (rather than just the wise choice to
> select Turbogears), then
> heck I may as well just go back to choosing from all the ugly variants
> of Java web framework layers.
You don't need to. Go with the defaults : Kid, SQLObject and TGWidgets
for now. These work pretty well in most cases - every case I've gotten
into, in fact, and I believe my needs are fairly common. Of course, I
can feel the geekish itch (newer components ! more functionality !) and
I'm glad TG allows me to use them if I'm not afraid. But the defaults
are here. If what you'd like is to be sure the defaults won't change,
I'm afraid you're asking for too much.
dom
Dominique Eav
> Personally, I feel quite differently. I get frustrated that
> Turbogears doesn't change quick enough. It will probably be quite a
> while until SQLAlchemy is the main ORM. I think the very nature of TG
> is that it is suited to people who like to be fairly cutting edge.
>
> If you want stability, then Java is definitely a much better language
> to work in.
>
> Choice is good. Complexity is fun.
TG is suited to people who like to be cutting edge *but* a lot of work
is done to ensure some stability (the one you're frustrated with - I
know how you feel : "where is CP3 ?" :) ). I think TG should try to
satisfy as well tech geeks and web developers aiming for safety. Both
may feel frustrated for now : the first suffer from the inertia of the
defaults and the second are permanently exposed to {newer, better}
components advertisement on the ML. I'm confident that we're heading for
a better balance. TG is not a toy for geeks, and it is suitable for
production development.
That said, complexity is fun, but this would better describe java web
frameworks IMHO, not TG...
dom
sams...@gmail.com
On Mar 30, 11:02 am, "Eric Hawthorne" <poeticsoftw...@gmail.com>
wrote:
> Editorial comment:
> E or F. Kid (simple, limited?) or Genshi (some kind of swiss-army knife of
> templating?)
With all due respect, I think you are misunderstanding Kid vs.
Genshi. I just converted my templates to Genshi and I can tell you
that Genshi from a user's perspective seems like kid version 1.1. It's
a natural continuation from Kid. The only reason it doesn't seem like
one is because it has a different name.
And I agree with some of the other posters...more quicker change
(while being really well documented....there's the rub).
I haven't used the widgets yet...but my impression is that tosca
widgets are pretty much version 1.1 of tgwidgets. Again, just a
different name.
You are being given the choice of using the current stable 1.0
release, or the 1.1 release components...only those are in Beta.
The only significant difference seems to be the orms....that isn't
quite the same thing.
Noah Gift
same thoughts. Maybe we could just break down in a Matrix what you
get with the defaults and what you lose or doesn't work with the new
ways and throw it into the turbogears wiki.
People that are more knowledgeable than me can probably lay this out
better, but here is an idea of how to start:
http://docs.turbogears.org/1.0/MatrixOfOptions
I put a link from rough docs/uncategorized to this page:
http://docs.turbogears.org/1.0/RoughDocs#preview
-Noah
Paul Johnston
I agree this is something of a problem, but TG is still great for me. I
would ask one question:
Are you prepared to dig into the TG source and do some debugging?
Yes - favor SQLAlchemy, Genshi and ToscaWidgets
No - favor SQLObject, Kid and TGWidgets
The problems that the newer technologies bring are being addressed rapidly.
BTW, regarding your Matrix, please move this into RoughDocs ASAP, it
does not belong in the official docs. There is already some info on this
- see http://docs.turbogears.org/1.0/SQLObjectVsSQLAlchemy
Paul
Noah Gift
>
> Hi,
>
> I agree this is something of a problem, but TG is still great for me. I
> would ask one question:
>
> Are you prepared to dig into the TG source and do some debugging?
>
> Yes - favor SQLAlchemy, Genshi and ToscaWidgets
> No - favor SQLObject, Kid and TGWidgets
>
> The problems that the newer technologies bring are being addressed rapidly.
That is a good way to put it I agree.
>
> BTW, regarding your Matrix, please move this into RoughDocs ASAP, it
> does not belong in the official docs. There is already some info on this
> - see http://docs.turbogears.org/1.0/SQLObjectVsSQLAlchemy
Just moved it to
http://docs.turbogears.org/1.0/RoughDocsMatrixOfOptions. I may or may
not have time to update all of this section by myself, but it does
seem useful to break down these discussions to the matrix as I think
what many people want to know is "how does this affect me". At that
point you can just point people to a matrix that says..."if you use
this configuration you get...this ...etc."