Comments on article "Time for a Quixote based Mega-Framework ?"

beza1e1 on Time for a Quixote based Mega-Framework ?

beza1e1 — 2005-10-21T12:19:15Z

Yesterday i hacked together quixote and feedparser. So now i can do:

import server
from feed_directory import Feed, Category
server.Root = Category([Feed("feed.xml"), Feed("slashdot.xml")], 'feeds')
server.run(server.create_publisher, port=8080)

Category and Feed are Objects, which are traversed by quixote. This works better and more dynamically, than a file based approach in my eyes.

btw the really nifty thing is the caching and automagically refetching Feed object, which simply wraps feedparser.Feed :)

phil on Time for a Quixote based Mega-Framework ?

phil — 2005-10-19T20:13:18Z

Well, we could dissert one decade on web frameworks, but still we'd need to choose one ... And there's enough candidates for teh app.

May be i'll wait for Mickael's TurboZCherryPloRails Giga-framework :-) It seems so hype!

Jkx on Time for a Quixote based Mega-Framework ?

Jkx — 2005-10-19T19:49:49Z

Ok, this is a short answer but: - I don't really like the regex url of Django too. I really think that url=Instance() (Ã la CherryPy) is a good way to solve most of issues.

For the UI component, I really think this is far too much complex for a web app.
The Zope.Interface is not a really funny module, and too much verbose (for me). But it can provide a good way to reusability that a good point.
Not talking about Zope3 ...

-- Jkx

Michael Watkins on Time for a Quixote based Mega-Framework ?

Michael Watkins — 2005-10-19T17:22:05Z

Clearly what works for one doesn't work for another... Myself I hate the way Django gets at URLs. regex? Yuk!

With respect to traversing the URL, I also don't find a series of UI objects calling each other as the tree is traversed to be hard to understand:

# and in my UI collection
RootUI
   CalendarUI
      CalendarItemUI
         EventUI
   DocumentUI
      ViewUI (index)
      EditUI
   ... etc

That's similar to a good ol' file system:

/
calendar/
   an item/
   another item/
documents/
   doc1
   doc2
   doc2/version1

Easy enough to implement in Quixote, although no doubt a few more tutorials or HOWTOs on trickier cases would be useful.

I'm not sold on what you call Component Oriented Programming, assuming you are speaking to the Zope Interfaces methodology. Its interesting and I can see its utility, but for now good clean object design continues to work for me.

You might have a play around with Dulcinea's "spec" module... it may not become immediately obvious but employing "specs" you can design objects with great reusability without diving whole hog into the IInterfaceThis and IImplementThat model.

But whatever turns one's crank! I can appreciate Zope3's approach even if I choose not to use it nor suffer the performance the overhead implied.

Its all what one gets used to but after having built a number of Quixote applications I've never found myself pining for the fjords[1]. Quixote allows you to write fairly complex applications relatively quickly and with a high degree of stability and safety; it also allows you to make a complete mess of the job too.

That's its charm! Cheers - Mike

[1] a Monty Pythonism

Jkx on Time for a Quixote based Mega-Framework ?

Jkx — 2005-10-19T16:20:22Z

The major Quixote stuff, is the scgi protocol. But I really hate the way Quixote handle the url. Playing wit h the index (sometimes method, or class method) is something that will kill most newbies enthousiast.

Another issue, is the lack of component oriented programming. This could be done easily w/ cherryPy (for example) and the defaut way of life in Django, but still missing in Quixote. I hope zope.interface will be used soon here.

But hurring up .. TurboGears and Django are really moving fast

Michael Watkins on Time for a Quixote based Mega-Framework ?

Michael Watkins — 2005-10-19T15:13:38Z

I agree with you wholeheartedly on this... and the quick hit clearly is with the Troika of Durus/Dulcinea/Quixote.

Maybe a video ... :-)