[Bielefeld-pm] Woodstock heißt je tzt Mojo

[Sebastian Riedel]

05.05.2006 11:48 Mario Minati:
> Ich hoffe, dass Sebastian demnächst mal seine neuen Ideen zum Thema
> Web-framework niederschreibt, damit man seine Gedanken  
> nachverfolgen kann.

Ich wuerde ganz gerne waehrend der Entwicklung bloggen,
allerdings auf einem Mojo powered blog. :)

Kann sich aber nurnoch um ein paar Tage handeln bis das geht,
also rechne mit einem Update von http://oook.de diese Woche.

Wie ich schon (irgendwo) geschrieben habe,
Mojo soll die naechste Inkarnation von Catalyst werden,
und besonders im Bereich Usability gewaltig zulegen.

Catalyst ist jetzt ungefaehr 1 1/2 Jahre alt,
genug Zeit zu lernen welche Features sinnvoll und welche Humbug sind.
Mojo wird nun die guten Features uebernehmen und die unsinnigen  
ersetzen.

Unsinning sind z.B.
* selbst neustartender Test-Server -> wird ersetzt durch eine bessere  
Klassenstruktur
   die eine Module::Refresh basierende Loesung moeglich macht (welche  
keinen Neustart benoetigt!)
* der Dispatcher, jede "Action" in einem "Controller" hat einen  
"private path"
   welcher dann an einen "public path" gebunden wird -> wird ersetzt  
durch eine viel einfachere
   Loesung welche auf einer Mini-Sprache basieren wird (welche aber  
ebenfalls Perl code ist),
   diese Idee stammt von Audrey Tang und wird bereits in Jifty  
eingesetzt.

   Beispiel alt:

     package MyApp::Controller::Foo;
     use base 'Catalyst::Controller';
     sub bar : Local {
         my ( $self, $c ) = @_;
         $c->response->body('Hello World!');
     }

   Beispiel neu:

     package MyApp::Dispatcher::Foo;
     use Mojo::Dispatcher::Vortex;
     on '/foo/bar' => run {
         my $c = shift;
         $c->response->content('Hello World!');
     }

   Dies hat viele Vorteile, so laesst sich die Mini-Sprache  
verschachteln und um neue Funktionen erweitern.
   Im ersten Beispiel wurden nur 'on' und 'run' benutzt, hier mal ein  
umfangreicheres Beispiel.

     package MyApp::Dispatcher::Foo;
     use Mojo::Dispatcher::Vortex;
     under qr{foo/(\d+)} => [
         run => {
             my $c = shift;
             $c->stash->{test} = $1;
         },
         on '*/*' => run {
             my $c = shift;
             $c->response->content( $c->stash->{test} );
         }
     ];

   Ja, es wird ueberall regex benutzt, und trotzdem ist es schneller  
als Catalyst. :)

* Der alte Test-Server funktioniert nicht mit Internet Explorer und  
hat sehr viele
   bugs die niemand mehr reparieren kann (oder will) -> Mojo hat  
einen neuen
   POE basierenden Test-Server, der sogar fuer den produktiv Einsatz  
verwendbar ist.

* Catalyst ist erweiterbar, aber es bedarf genauer Kenntnisse ueber  
Interna
   und Multiple Inheritance -> Mojo hat eine ganz einfache plugin api  
die Plagger
   sehr aehnlich ist, plugins lassen sich sogar zur Laufzeit  
austauschen!
   Und das beste, Engine und Dispatcher sind *nur plugins* in Mojo!!!

   $c->mojo->plugins->register('Something'); # laedt  
Mojo::Plugin::Something

   # Minimales plugin, welches einen event handler registriert
   package Mojo::Plugin::Something;
   use base 'Mojo::Plugin';
   sub initialize {
       my $self = shift;
       $self->register( test => sub {} );
   }

   $c->mojo->plugins->run('test'); # Ruft alle event handler fuer das  
event 'test' auf

   Dies ist sehr einfach zu verstehen und trotzdem sehr vielseitig  
verwendbar.

* Catalyst ist sehr MVC orientiert -> Mojo wird nur zwischen  
Dispatcher und Component unterscheiden,
   die Namen sind geziehlt generisch, das hat zwei Gruende, zum einen  
wird es einfacher sein nicht-MVC
   Anwendungen mit Mojo zu schreiben, zum anderen macht die strikte  
Trennung sowieso wenig Sinn da 80%
   aller Anwendungen nur eine View und eine Model Klasse haben.

   Beispiel alt:

   % find lib/Neutrino/
   lib/Neutrino/Controller
   lib/Neutrino/Controller/Foo.pm
   lib/Neutrino/Controller/Bar.pm
   lib/Neutrino/Controller/Baz.pm
   lib/Neutrino/Model
   lib/Neutrino/Model/BlogDB.pm
   lib/Neutrino/View
   lib/Neutrino/View/TT.pm
   lib/Neutrino/Something/Else.pm
   lib/Neutrino/Another/Snippet.pm

   Beispiel neu:

   % find lib/Neutrino/
   lib/Neutrino/Dispatcher
   lib/Neutrino/Dispatcher/Foo.pm
   lib/Neutrino/Dispatcher/Bar.pm
   lib/Neutrino/Dispatcher/Baz.pm
   lib/Neutrino/Component
   lib/Neutrino/Component/BlogDB.pm
   lib/Neutrino/Component/TT.pm
   lib/Neutrino/Component/Something.pm
   lib/Neutrino/Component/Snippet.pm

   Dies ist eines der Usability Features von denen ich sprach.
   Components sind also einfach Code Schnipsel zur Wiederverwendung,
   nicht nur Models und Views.

* Catalyst hat viele Plugins, Models und Views -> das ist gut und  
schlecht,
   wer beginnt Catalyst zu lernen muss zuerst lernen sich fuer  
Komponenten zu entscheiden.
   Das macht es denen die gerade mit Perl beginnen sehr schwer,  
deshalb wird es in Mojo
   einen empfohlenen Weg geben, auch wenn alles genauso austauschbar  
wie in Catalyst ist.

   z.b. wird Mojo Log::Log4perl, Test::WWW::Mechanize,  
Template::Toolkit, DBIx::Class, POE
   und weitere "best practices" als Standard verwenden.

Das sind nur ein paar Punkte, hoffe das reicht fuers erste.:)

--
sebastian