On Wed, Sep 17, 2008 at 8:21 AM, Mark Ramm <[EMAIL PROTECTED]>wrote: > > >> Who was the guy that asked the first question? One of the lead > >> developers of Django I assume? > > > > I'm guessing James Tauber? Of cloud27/Pinax fame? Definitely trying to > > "picking holes", IMO (although he chose straw men - he could have > > picked some serious holes!). > > James is correct, but it was Bennet not Tauber. ;) > > >> Mark, how did they know to ask you? I mean it was a great choice--- > >> but a weird one. Or did you volunteer? > > > > I agreed, it was an inspired choice. > > As I mentioned you'll have to thank Jacob for that one -- he's the one > who asked me to do it, and encouraged me not to pull my punches, but > to say what I really thought. > > You said exactly what I had been thinking (plus some!), with > > conviction and authority, without unnecessary antagonism. Brilliant. I > > had conversations with Jacob KM about exactly the things you talked > > about (e.g. WSGI<->Django middleware wrapper), and they are thinking > > of doing this, I think largely as a result of your talk. He confessed > > embarrassment as an engineer about the dependency graph, and was > > interested to learn more about how TG has handled easy_install (he > > didn't know you can supply your own egg repo via a html page). > > Kevin Teague has a great blog post abut the package installation > infrastructure that's available in python. He pretty much charts all > the options. > > http://www.bud.ca/blog/pony > > Though I do think it might be worth mentioning in the context of > Django that you could do something like distribute a tarball with all > of the packages django needs included and a paver script that lets you > install all the django dependencies before you install django itself. > > > > Two things I learned that Django does better than TG/Pylons, IMO: > > > > Style: > > > > Django stuff looks good. The culture in Django is more design > > orientated than TG, and I think that is a factor in their success. At > > PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler > > module[1], and one the Django folk's comments was "Sweet! But you > > Pylons guys always make things so ugly - get a designer to give you a > > style sheet already". They have a point IMHO. > > Well, we need to attract more designers ;) But seriously, this is a > point well taken, and we're trying to improve the out of the box > design experience for many TG related projects. And in the > particular case of the WSGI profiler, I think that Armin may be > getting involved, and he has some design sense. >
yes indeed. I have heard several times, from core tg people, that "I can't mix colors if my life depended on it" Any ideas on how to attract good CSS people? I include myself on that part. I can fix a CSS to make it awesome, when displayed in a text file not rendered by a browser :p > > > Apps: > > > > Django has a large amount of plugin apps > > (wiki/forums/openid/tagging/notifications/IM/IRC/etc) that add > > functionality to the whole stack (views, controllers, middleware, > > model). They can do this because they know the whole stack in advance. > > The included admin interface is a classic example. > > > I'm not 100% sure about this. you could still do this on TG1 its just hard. I guess the biggest problem TG1 has, which by the way TG2 doesn't, as you can mount apps or wsgi with a single line. Now the way you have INSTALLED_APPS in django (is that the name of the config variable?) and everything undestands that is enough to have a mirade of apps, now be aware that sometimes that functionality makes it look like a CMS, direct comparation to joomla, where you have a lot of components to choose from but a lot of them are badly written. > > > Pylons doesn't dictate the whole stack, so its more difficult for > > people to write plugin apps that need top-to-bottom access. However, > > TG does make some choices, which might enable us to do more plugins > > apps, but we still value choice. > > > but wsgi does. > RUM is likely the way forward here - if we write things to the RUM > Factory apis[2], controller/model interactions can be abstracted to > allow plugin apps to work with any stack component, in theory. One that TurboGears exists, is that we want to allow people to write > plugin apps that assume the existence of SQLAlchemy, can be mounted > easily by instantiating an object, and can assume that you have other > necessary components like Beaker sessions, automatic cross-database > transactions, genshi, mako and/or jinja. > > I think it would be interesting to create some of those plugins > towards the RUM data abstraction layer, but I don't at all think it's > necessary for most pluggable apps -- a very large majority of our > users are going to be using SQLAlchemy. And if they aren't we can > still use SA in plugins and have the transaction manager manage the > interactions between the plugin database commits and the ones that the > app does itself. I think this could be one of those issues you where talking at the 3th talk. It may be a good idea, it may not we should try it. maybe it will end up like buffet, after all how many people change ORM everyday? > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
