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

[Mario Minati]

Sebastian Riedel schrieb:
> 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
>
> _______________________________________________
> Bielefeld-pm mailing list
> Bielefeld-pm at pm.org
> http://mail.pm.org/mailman/listinfo/bielefeld-pm
>
>   
Hallo Sebastian,

danke für Deine Einführung in das Gedankenkonzept von Mojo.

Ich bin sehr gespannt auf das erste Release und hoffe bald Zeit zu haben 
mich dort einzuarbeiten.
Die Verwendung von best-practice Modulen begrüsse ich, gerade mit POE 
habe ich schon gute Erfahrungen gesammelt.

Gruß,
Mario