Sorry it was my fault, but lets keep the SO discussion on this thread (yes I just violated that a minut ago, I though I was replying to this thread)
On Thu, Jan 15, 2009 at 11:53 PM, Daniel Fetchinson <[email protected]> wrote: > >>>>> A show-stopper would be that TG2 uses by default the repoze.what SQL and >>>>> quickstart plugins, which only support SQLAlchemy. So supporting SO in >>>>> TG2 >>>>> would also mean porting both plugins to SO. >>>>> >>>> >>>> Also I don't think this should belong to the core. it should live in >>>> tgext.sqlobject, and hook into tg2 to replace the modules. >>> >>> Why do you think so? If integration of sqlobject is achievable I'd say >>> SO and SA are on the same footing, just as was the case with tg1. Why >>> should SA be favored? >>> >> Because TurboGears is a "best of framework" and SQLAlchemy is far >> superior, the only reason TG1.x had support for SA and SO was because >> of transition that transition is over. >> >>> I'm building on the assumption that support for sqlobject is doable in >>> a clean and elegant way. I'm not saying it's easy (in fact, until >>> today I thought it will never be done), but supposing that the code is >>> there, in that case, why do you think SA should be singled out? >> >> Because one of the goals of TG2 is to keep the core small. One of our >> mistakes with the TG1 code base was to add way too many things to the >> core, so the moment one part of it fail TG was blamed. Which is very >> bad PR. Specially went something was added to the core and the >> original author was gone, then no one wanted to maintain the code and >> it just keep making bad PR. >> >> As for SQLObject the project it's one a small bit of what it ones was, >> why will you want to use a project that is less in every aspect than >> the default? I can only think of 3 reasons >> - you have tons of code that depends on it, in that case maintaining >> tgext.sqlobject will mean less work than migrating to SA. > > This reason is my reason. > how many is tons? 100 classes ? 1000 queries? >> - you are just lazy >> - you don't want to migrate to 1.1, 1.5 > > These two don't apply :) > >> the main reason for 1.1 is genshi and SA support, the main reason for >> 1.5 is CP3 support, to me it seems none of the core developers has (to >> this day) a big investment in SO and if they do they are fine with 1.0 >> or 1.1 for that particular app. > > It certainly can be true that the core dev team has no big investment > in SO. If they do, don't you think they would be happy to use the > added benefits of tg2 for their SO-based tg1 apps? > no, almost everyone is using SA. core and not-core, the only people still using SO are - total newbies that don't know better and just quickstarted 1.0.x - people that don 't post to the list for help - people that don't post tickets to solve issues - you :) seriously the SO related traffic is very very low on this list. (at least in the last year) >> So from that I conclude that adding SO >> to the core will be a mistake as it will rapidly go unmaintained, and >> people will complain they are no docs or no example or etc, etc and >> that will create bad more PR. > > I'd say the only people who will use SO in tg2 are the ones who > already used it in tg1. This is because you are right, why would a new > tg2 user choose SO over SA when SA is fancier and newer? But those > people who have heavily invested in SO will not be the ones who will > complain, simply because they are familiar with SO already. > > Final thoughts: I can clearly see that SA is the fancy new > alternative, it's sexy and hyped and not without reason. But this > doesn't mean that SO's quality went down relative to what it was 1 or > 2 years ago. It was pretty good for what it was designed and it still > is. It doesn't suit everyone but it surely suits many people. It > doesn't have certain features that can be considered useful, but if an > app doesn't need those features it's not a disadvantage. SA isn't fancy or sexy or hyped, it is better. It is more flexible, it generates way better SQL, it's modular, it's better supported, it's more tested (in the wild), it scales better. supports non-mainstream db's better. > Similar > example: vim. Many people (including me) still use vim although it's > considered ancient, dead, outdated, non-fancy, non-sexy. But it's > pretty good in what it was meant to do and the mere existence of > fancier and sexier alternatives doesn't decrease it's quality. Some > people like this, some people like something else. > blasphemy, vim is one of the most active communities in open source. I'm sorry but there is nothing fancier or sexier than vim. your analogy may be "old is good because is old", but that is simply not true, the only thing that SO has better over SA is, the level of knowledge you have over it (that's a generic you, it may as well be me), if we go by that definition we will still be writing webapps in perl under CGI because "you know it" Final thoughts, write tgext.sqlobject, ask for ANY hooks the core will need for it, I'll commit them myself, When it's ready and stable we'll do a proper vote on here to include it on the core or not, or just let mark decide :) TurboGears is about bringing the best of each component into the mix, to provide the best web framework. And this proposal goes against that. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
