All Go for Django...

I'm most probably gonne use Django for my little project.
I need a framework that I don't have to fight but still provides me with an efficient tool to make things fast.

My initial assuption that Django would get in my way have been shattered enough to make me put my hopes in Django. Another reason is that I don't have time or want to search any more, I want to start prototyping.

I think an apology might be in place

I must admit I didn't give Django a fair examination, now that I have visited it I am much more happy about it. As I mention before it does what I want but not in a fasion I like.

Well, the easy of making applikations with Django have convinced me that running
setup commands to get started isn't that bad after all.

I'm suspecting I will run into limitations of Django but reading the tutorial was really fun.
Allot of stuff is made for you automatically.

I think I'll keep reviewing this for a while.

"Google"

The number one top ten of stupid answer a person could give another person asking a question on a online-forum or mailing-list is "Google", even so the answer is give more often when answers that actually help people.

The main reason for people not realizing how stupid they behave is they fail to recognize that people are different and that a large amount of people isn't like them.
Correction, they know that people are different and that people are not like them, but instead of trying to understand how they work and accept them as they are they incorrectly judge these people as being stupid.

"Repeat after me three times: Being different or thinking different isn't the same as being stupid."

Many people that ask questions on online-forum prefer to use relational methods for gathering information and are rather taught fact by someone in person than seeking it in solitude.
You could say that their information function is relation based or extrovert, compared to "the rational person" who's function is introvert and maybe more goal oriented (short term closure).

A false sense of all mighty knowledge
For "the rational person" the difference in knowing fact and knowing how to get facts are now days getting kind of blurred, and (of course) I blame the Internet and in particular Google ;-)
This is a contributing factor in the "Google" answer on online questions because the "know-it-all" person knows he could use Google to find the answer, hence he has a feeling of knowing the answer and then feels entitled to actually answer it (with "Google"). When in fact he didn't have the answer or worse he did but didn't put an afford in formulating an answer him self (because it's easier and "everybody should be tough to do thing my way").

This will not end, but as with the Swedish language protectionists at "skrivihop.nu", "rational people" can learn new behaviour, the problem is no one have told them, until now.
Well some rational people doesn't want to change there behaviour, but the rest of us have already learned to ignore them :-)

Cocktail party problem

Cocktail party problem or as I used to call it when I when to the university, the cocktail problem. It turned out to be a completely different problem though.

Anyway this is a really cool example on how to use the SOM-neural network to separate two sound sources. Accually the example works so well I'm starting to think they are faking it.
I might also have missed something very important, being a 1200CC chaos machine and all.

There is just too much stuff out there

After spending some time researching different web app. solutions in Python (while trying to avoid treason by looking at Rails directly ;-) I'm over whelmed. There is just too much project going on.
I guess doing rdb based web apps in python is in fashion *lol*

TurboGear: Same same different different

TurboGear is really just some other stuff pack together to a package, it might accually be pretty brilliant.

TurboGear combineds MochiKit (Javascript libarary), Kid (TAL and XSLT inspired XML template language), CherryPy (web app. framework) and SQLObject (ORM). It also uses ElementTree (Fredrik Lunds XML library), FormEncode (form validation framework), TestGears (unit-test) , and json-py (json-python bridge).

Accually this are all software that sound amazingly interesting and those I haven't check out (and approved like SQLObject, which imo is the best Python ORM out there, and CherryPy, which imo is the best simple web app. framework out there even though I'm still looking.

Kit is a possiblity, I will either choose Kit or TAL I guess, it all depends if Kit does what TAL doesn't do for me, e.g. let me define a component library of visual components (not macros).

No go for Django

I'm pretty sure Django is what I want, or should I say Django does what I want to do, but I'm pretty sure I don't want Django to "tell" me how to do it.

Cheetah Template

CherryPy got an bonus tutorial but it required Cheetah Template too run so I had to get that and check it out.

Well they are claming to "encourages clean separation of content, graphic design, and program code", but I can't for the world see how. It's basically Python Classes written in HTML.

One thing that made me interested was the fact that you could inherite a template from a sub-template. But after a time of thinking I recall why this is a bad idea. The one thing I hat the most in TAL is METAL, the macro language in TAL. METAL lets you reuse snippets defined in other template (METAL templates).

Well the bad thing about this is (part from the METAL implementation being unintuitive to a Python programmer because snippets are included not callable which would have made it possible to give arguments to a snippet).
Ok the bad thing (again) is co-location and co-location leads to unmanagable code, if you don't believe me check out Plone and try to change the site design.

I want to have a template language that uses layers instead of inheritance, that's how I work now days. E.g. I create a top layer template, it calls a set of renderNextLayer methods (usually just on called renderContent, more complex designs then that is accutally very rare).
When I call the top layer template I give it the renderContent callable as an argument.
Off couse this method works in all template languages that allow you to supply variable names including Cheetah.

Simple but slow cherry

One of the things that stand-out when acctually running CherryPy is that it's remarkably slow. For a single use with the most simples Hello World it take almost secs to return a page, I would have expected a simple web app. framework to be faster, even the monolit Zope is much faster (not starting up though but with few Products installed that ain't that slow either).

Webware

Well I checked out Webware for 5 minutes, and I can only say that I don't have reason for evaluating futher. If I should use a complex framework I would use Zope 3.

Yield your self

Fantastic!

I just tried the tutorial example #09 in the CherryPy distribution and that's all about generators. Namely you can public a generator factory, using yield to return bits and pieces of the page with out bothering to append the data in a temp variable.

How cool is that (well a little bit, a tiny-iny bit, oh sod of).

Here's the example:

"""
Bonus Tutorial: Using generators to return result bodies

Instead of returning a complete result string, you 
can use the yield statement to return one result part 
after another. This may be convenient in situations 
where using a template package like CherryPy or Cheetah
would be overkill, and messy string concatenation too 
uncool. ;-)
"""

import cherrypy


class GeneratorDemo:
 
   def header(self):
       return "<html><body><h2>Generators rule!</h2>"
 
   def footer(self):
       return "</body></html>"
 
   def index(self):
       # Let's make up a list of users for presentation purposes
       users = ['Remi', 'Carlos', 'Hendrik', 'Lorenzo Lamas']
     
       # Every yield line adds one part to the total result body.
       yield self.header()
       yield "<h3>List of users:</h3>"
     
       for user in users:
           yield "%s
" % user
         
       yield self.footer()
   index.exposed = True

cherrypy.root = GeneratorDemo()


if __name__ == '__main__':
   cherrypy.config.update(file = 'tutorial.conf')
   cherrypy.server.start()

Jag har varit otrogen...

Jag har dom senaste 5 åren jobbat med ett ramverk för webbapplikationer om heter Zope, det är ett komplext och kompetent system med många fiffiga finesser och allt man behöver är inkluderat (webbserver, scriptspråk, transkationsserver, databas, säkerhet med mera).

På senare tid har en ny generation (den tredje generationen) Zope 3 av Zope växt fram och efter att ha bråkat med Zope 3 större del av hösten kan jag nu lägga den på hylla (eftersom uppdraget är där Zope 3 användes är slut).

Men det goda i det hela är att jag börjat omvärdera hur lämpligt Zope är för att lösa alla tänkbara problem. Även om jag fortfarande anser att Zope är extremt lämpligt för webbpubliceringsapplikationer som CMS, e-handel, Intranet och portaler är det inte alltid det bästa verktyget för jobbet. Faktum är att jag många gånger misslyckats med Zope, egentligen lika många gånger som jag lyckats.

Zope 3 är visserligen mycket renare än in föregångare (Zope 2) och det innebär att det både
är enklare att lyfta in externa lösningar in i Zope 3 och att Zope 3's komponenter enklare
kan återanvändas utanför Zope 3. Men Zope 3 dikterar fortfarande, och kanske till och med
i större utsträckning än Zope 2, hur man skall designa sin webbapplikationer.

Enter CherryPy (vilket är den första i en trolig rad av Python baserade webbapplikationer ramverk som jag nu kommer att titta på för ett framtida spel projekt).

CherryPy har inte hälften av alla bells&whistles som Zope plattformen erbjuder, det mest
signifikanta är troligen avsaknaden av säkerhetssystem men det är en enkelt och strait forvard sätta att bygga webbapplikationer.

Enkelt beskriver kan man säga att man skapar klasser som man sedan instantierar och till delar
till en objekthierarki med start i cherrypy.root. Objekten metoder kan publicerar till webben genom antingen en dekorator eller att man tilldelar variabeln published=True på "metoden" (man kan göra sånt i Python eftersom funktioner och metoder är objekt).

Tre metoder kan användas som "default" metod, index(*arg, **kw), default(*arg, *kw), och __call__.
Det normala är att använda index eller default där index har företräde framför default.
Skillnaden mellan dom båda är att argumenten för index fås från webb requesten, medan argumenten för default är en kombination av webb request variabler och ej matchade URL element.

Exempel:

URL Anrop
/ root.index()
/?hello=world root.index(**kw={'hello':'world'})
/hello/kitten root.default(*arg=('hello', kitten')
/hello/kitten?hello=world root.default(*arg=('hello', kitten', **kw={'hello':'world'})


Hänger du med, läs CherryPys tutorial, dom förklarar det bättre.

CherryPy saknar skriptspråk eller snarare är skriptspråk agnostisk, vilket passar mig fin fint eftersom jag troligen vill skapa mitt eget skriptspråk (en variant av Zopes TAL språk).

CherryPy erbjuder inte så mycket mer, en inbyggd webserver som inte verkar speciellt imponerande, en filter funktion för att patcha in låg nivå hantering av request och response, en väldigt medioker konfigurerings funktion baserat på Pythons inbyggda .ini parser (men den räcker till väldigt bra för mina mål, man kan jämföra den med Zope3s mastodont konfigureringsspråk).

En sak jag är glad att CherryPy har out-of-the-box är sessions hantering, den är naturligtvis inte lika komplicerad som Zopes (duh!) men räcker troligen till för att hålla en cache av session
data för en användare.

Som jag nämde ovan saknar CherryPy ett system för säkerhet, visserligen har dom ett system för att publicera objekt och metoder (default är att metoder inte är accessbara från webben) men det finns inget system att hantera användare/grupper och inget system för rättigheter/roller.

Om jag väljer att gå vidare med CherryPy är det första jag kommer försöka göra att integrera
Zope 3's zope.security med CherryPy så jag kan definera åtkomsträttigheter.

Nästa ramverk för granskning blir django...
Vi hörs!

SQLObject och Zope3 security

(Jag kanske borde ha en teknik blogg istället för att maila er stupikvarten!)

Så jag skrev det på i min blogg istället.

I alla fall, mitt äventyr med SQLObject går vidare. Nästa steg i problematiken är att förse dom stackars objekten med en vettig säkerhets modell.

Enter Zope3. Detta är redan gjorts SQLOS projektet, men eftersom jag inte vill använda Zope3 som det är och absolute inte vill använda mig av "Containers" i ZODB
för att husera object (jag vill att dom skall få sväva fritt i sitt Python universum, eller något "slightly" mindre poetiskt). Så...

Så använder jag bara Zope3s zope.security, vilket pga av att zope3 är väldigt modulärat uppbyggt och har få dumheter (a la Acquisition
eller ExtensionClasses), är det super enkelt att återanvända
(eller, det är Zope3 så det är inte enkel men det är super gör-bart och efter att man skruvat fast huvudet igen, vilket har en tendens att lossna efter att man läst Zope3s dokumentation över hur saker funkar internt).

En annan liten down side med zope.security är att man faktiskt måste implementera "allting", men byggstenarna och de inre mekanismerna finns där och det är inte speciellt mycket som är allting när allt kommer omkring.

Ett annan litet problem är att zope.security implementerar isinstance eftersom isinstance i __builtins__ inte kan hantera objekt wrappade i en Proxy (naturligtvis). SQLObject verkar enligt utsago från skaparen av SQLOS alt SQLObject använda isinstance på flertal ställen vilket
innebär att jag måste antingen byta ut den i __builtins__ (aj), monkey patch in den i SQLObject eller helt enkelt patcha SQLObject (SQLOS monkey patchar tror jag, det kommer jag nog också göra).


Ett annat plus med zope.security är att dom definerar om restricted python från zope 2 på ett återanvändbart sätt. Det man kan skapa med det är 1. säkra användar programmerbara objekt (till en moo), 2. en säker intrepetator (till samma moo).

Alltså man kan göra en säker pythonbaserad moo, all data kan hållas i en SQL server av ditt val (eller mitt, vilket troligen blir postgres kanske mysql) inklusive python kod objekt eftersom SQLObject har en pickle data type (dvs för dom databas back-ends som kan hantera blobar förstås).

Nu skall jag testa att använda eventnet för att skapa en enkel multi-user mud. Eventnet är en modul för en nätverksbaserad eventloop för spel som verkar lovande.