Flutterby™! : Yahoo UI Library

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Yahoo UI Library

2006-02-20 16:55:02.469752+00 by Dan Lyke 8 comments

This weekend I took a little time and played with TurboGears, which is basically an aggregation of a bunch of different Python[Wiki] toolkits. I'm impressed, SQLObject looks like a great little database abstraction that I'll be using in other Python[Wiki] applications, Kid is an HTML templating language that looks like it's up to the level of the one I wrote for Flutterby, and MochiKit "... makes JavaScript suck less". All of these talk rather nicely to CherryPy, the web development framework.

However, the reason I'm making this entry is that I wanted a place to hang the Yahoo! UI Library, a bunch of JavaScript[Wiki] code for hacking together web applications, and the Yahoo! Design Pattern Library a cookbook for using those things.

The one potential down side is that these probably use XML to communicate with the server, and the TurboGears integration uses their own more simply parsed protocol, but I believe that in my searching around there was mention of integrating the functionality that's not already into MochiKit in.

[ related topics: Web development User Interface Content Management Databases Python ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2006-02-20 22:20:48.630531+00 by: John Anderson

WRT MVC frameworks, have you looked at Django (Python) or Catalyst (Perl)? The latter has been working out well for me, largely because it builds on existing pieces that I'm quite happy with (Class::DBI, Template Toolkit, etc.)

I need to look at MochiKit; I've been using Prototype, but it's a bit masocistic figuring out how to accomplish stuff.

#Comment Re: made: 2006-02-20 23:33:49.224745+00 by: Dan Lyke

I haven't looked at Catalyst, mostly because I'm moving away from Perl, and while Ruby on Rails was appealing, I couldn't see using neurons on yet another language that sounded like it was essentially Python[Wiki].

Django seemed to be the MTA that shall not be named of web application development: rather than re-use existing code they rewrote everything from the ground up, and you can either do it their way or not at all. It seems tied fairly closely to Apache (all of the quickstarts I've seen so far have had "enable mod_rewrite, and..."), nobody likes their template language, and it seems (although I haven't done anything to verify this prejudice) like there isn't really a community around it, it's a couple of smart guys writing software, but not a sustainable open source project.

I'm excited about TurboGears because it seems like it's mostly about tying together frameworks which already solve problems well, and that sort of attitude leads towards later flexibility. It also feels like it's got a diverse group of people working on it, even though the archives are closed right now, and that feels more like something that's going to survive long-term.

CherryPy may make deployment a little more difficult, but if I have to do something that's not on my own server, then I'll cross that bridge...

#Comment Re: Django History made: 2006-02-21 02:14:29.361649+00 by: Roger [edit history]

Mm. Django's been in use long enough before going open-source that it pre-dates some of the components that TurboGears wraps (namely, Kid). Having lurked here a long while, I'm kind of surprised you're enjoying SQLObject --- it's not known for being terribly efficient (you'll find this on the TG email lists, where a growing contingent is salivating over SQLAlchemy, a late comer to the party). Specifically, the lists hold up Django's non-use of SQLObject as not-invented-here ... except Django wanted an ORM that behaved in a completely different fashion. Watching both projects, it's interesting how much "emotion" gets presented as "fact" (or, as we say, "Pythonic". Bah!)

Having been following TurboGears more closely, there's one list for developers and users, and I think because it has a more pleasing OTOB experience, it attracts a wider audience. OTOH, it's not clear to me anybody really has a solid grasp how all the parts will hold up in the long run.

What has appealed to me about Django is that it was "extracted" after having solved large-scale CMS projects. People know how to deploy Django applications to the masses.

Both hit different sweet spots, and neither is all that tightly coupled. You can use SQLAlchemy in TurboGears, or SQLObject in Django. It's only if you never venture OTOB that you're "stuck".

Ending on a positive: MochiKit does indeed rock, and the way TurboGears can readily interact with MochiKit via JSON (which is a widely supported alternative to XML transfers, BTW) is (IMHO) the best trick in TurboGears.

(Apologies for the frequent edits; apparently dropping out of lurker mode is taking some effort ;)

#Comment Re: [Entry #8678] Re: made: 2006-02-21 11:06:02.957068+00 by: Unknown, from NNTP

Dan Lyke <danlyke@flutterby.com> writes:

>    I haven't looked at Catalyst, mostly because I'm moving away from
>    Perl, and while Ruby on Rails was appealing, I couldn't see using
>    neurons on yet another language that sounded like it was essentially
>    Python [Wiki] .

I keep forgetting that I'm apparently the last person in the world who isn't[Wiki] moving away from Perl... 8^)=

> Django seemed to be the MTA that shall not be named of web application > development: [ snip ]

Ouch.

#Comment Re: made: 2006-02-21 13:52:05.296838+00 by: meuon

I'm taking apart a Python/Java/Javascript/XML/PostgreSQL kludge right now, and I'm thinking - so far, it could have just been a much simpler PHP App. Python looks good, but it also seems to not be baked yet. At least for web-apps, because it's not tied tightly into Apache as a module, it runs only as a CGI? At least in this kludge, cookies and auth are all kludges using Java and there are other places where Python and Java pass XML-ish data back and forth.

I'm just diving into Python seriously, and I'm not sure if what is wrong here is the Python, or the coder(s).

#Comment Re: [Entry #8678] Re: made: 2006-02-21 15:01:03.166951+00 by: Unknown, from NNTP

meuon <prefersanonymity_20@flutterby.com> writes:

>    I'm just diving into Python seriously, and I'm not sure if what is
>    wrong here is the Python, or the coder(s).

Both? 8^)=

#Comment Re: made: 2006-02-21 16:44:16.935106+00 by: Dan Lyke

Roger: Cool, thanks for the background. I've discovered quite a bit more JSON stuff of late, and I've also run across more of the criticism of SQLObject.

Meuon: All of the Python[Wiki] frameworks either use FastCGI rather than CGI, or have their own server built in with the assumption that your load balancer will proxy through the requests which need to be served dynamically. This helps bring a decoupling from Apache, which is one of my goals; that's just become way too clumsy and complex a piece of software.

John: Maybe it's issues of design, but I found that maintaining complex objects was becoming more and more difficult, that I was caught in a maze of twisty little "->{"s and "->["s and even the occasional "$$"s that was just getting too hard to keep up with.

#Comment Re: made: 2006-02-24 20:13:36.150247+00 by: baylink

Excuse me? mod_python?