Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]12551[/thread]

Mojo, eine neue Art von Web Framework (Seite 4)

Leser: 10


<< |< 1 2 3 4 5 >| >> 46 Einträge, 5 Seiten
lichtkind
 2008-11-08 22:31
#116111 #116111
User since
2004-03-22
5681 Artikel
ModeratorIn + EditorIn
[Homepage]
user image
weniger abhängikeiten sind ein klarer vorteil aber nicht der wichtigste denk ich.
Wiki:Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.
Ronnie
 2008-11-08 22:54
#116112 #116112
User since
2003-08-14
2022 Artikel
BenutzerIn
[default_avatar]
Gast+2008-11-08 21:24:05--
Ahso, nur weil das halbe CPAN installiert wird und Module wiederverendet werden und nicht nur die Core-Module verwendet werden, ist eine "Applikation" schlecht. Eine tolle Begründung.

Nein, aber wenn eine Applikation 154 Abhängigkeiten hat - würde ich es auch nicht als elegant bezeichnen. Es spricht nichts gegen die Verwendung von existierenden Modulen - dafür ist das CPAN da. Aber irgendwo ist ein subjektive Grenze dessen was man für vernünftig hält. Dazu kommt, das ich eben einen ersten Eindruck geschildert habe - mehr nicht. Wenn man mit mehreren Sprachen und deren Frameworks vergleicht (oder das von außen geschieht) ist es eben ein Argument, ob eine Applikation eine handvoll Abhängigkeiten aufweist (die u.U. in einem Guss kommen) oder derer eine unüberschaubare Vielzahl.
Gast Gast
 2008-11-08 22:58
#116113 #116113
@lichtkind, mein Problem ist einfacher Natur

Es gibt soviele Frameworks, dass man sich kaum noch entscheiden
kann, welches man verwenden soll. Dazu kommt, dass die meisten
Frameworks miserable dokumentiert sind und wenn man dann viel
Zeit investiert hat eine Applikation zu entwickeln, dann kommt da
schon wieder was neues auf CPAN was noch besser und cooler sein
soll. Davon betroffen sind nicht nur Web-Frameworks.

Soll ich jetzt wieder Zeit investieren, wenn dann in 1-2 Jahren wieder
was neues da ist, noch besser als Mojo bzw. Mojolicious? Es gibt viele
gute Perl-Entwickler, die aber alle unfähig sind, sich zusammen zu raufen
und gemeinsam etwas zu entwickeln, was auch eine längere Zukunft hat.

Python und Ruby machen es uns vor. Warum kann Perl das nicht auch?

Viele Wege sind gut, aber zuviele Wege sind kompliziert.
Gast Gast
 2008-11-08 23:04
#116114 #116114
@Ronnie, so wie Catalyst?

Mir ist ein Framework mit einer starken Community über mehrere Jahre und vielen Abhängigkeiten lieber als jedes Jahr ein neues Framework, welcher Art auch immer.
lichtkind
 2008-11-09 00:39
#116116 #116116
User since
2004-03-22
5681 Artikel
ModeratorIn + EditorIn
[Homepage]
user image
Gast: in Ruby und Python gibt es ebenfalls etliche Rahmenwerke, weswegen ich deine betrachtung negativer als notwendig ansehe. es ist "normal" das es mehrere ansätze gibt. vielleicht hättest du dich weniger geärgert wenn du eher erkannt hättest was etwas für dich ist oder wenn du es auch mehr schätzen kannst was du beim scheinbar sinnlosen einarbeiten in andere rahmenwerke gelernt hast.

sri hat nie davon nur gesprochen catalyst eretzen zu wollen, sondern er erkennt den vorteil wenn die nächste generation catatalyst auf mojo aufsetzt. wie gesagt meta.
Wiki:Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.
topeg
 2008-11-09 01:22
#116119 #116119
User since
2006-07-10
2611 Artikel
BenutzerIn

user image
Ich sehe das so:

1. Die meisten Frameworks wurden in freiwilliger Leistung geschrieben, erweitert und gepflegt.
Darum halte ich es für etwas schofel, diese Arbeit zu generell zu kritisieren. Eine konstruktive Kritik, oder gar einen Codebeitrag halte ich dagegen für sinnvoll und sollte immer erwünscht sein.

2. Jeder der sich an die Arbeit macht um ein Framework zu entwerfen und schreiben, denkt sich etwas dabei. Mal ist es Unzufriedenheit mit den Bestehenden, mal Neugier, oder auch eine Idee einer anderen Herangehensweise.
Ich will nicht abstreiten, dass einige Systeme schlecht entworfen oder programmiert sind, aber man sollte dennoch versuchen zu verstehen, was sich der Programmierer dabei gedacht hat und unter Umständen Verbesserungen vorschlagen.

3. Es gibt eine Menge Rahmenwerke, aber deshalb alle außer eines zu verdammen ist der Falsche weg. (und welches sollte es dann sein?)
Das wäre so als würde man jemanden den Mund verbieten.
Besser währe es wohl Beschreibungen und Beispiele zusammen zu tragen und eventuell bei der Dokumentation zu helfen. Das brächte viel mehr, als einfach über die Vielfalt zu jammern.



Selbst wenn es 10.000 verschiedenen Frameworks gäbe, die man alle betrachten müsste um ein ideales für sein Projekt zu finden, so dürfte das nicht so lange dauern, wie selbst eines zu schreiben, was ja die alternative währe wenn es keine gäbe. :-)
GwenDragon
 2008-11-09 12:54
#116121 #116121
User since
2005-01-17
14608 Artikel
Admin1
[Homepage]
user image
Bitte keine Rumpöbeleien auf niedrigem Niveau, und keine Postings am Thema vorbei, sonst behalten sich die Moderatoren vor, das dann ohne Rückfrage zu löschen.
bloonix
 2008-11-09 13:47
#116123 #116123
User since
2005-12-17
1615 Artikel
HausmeisterIn
[Homepage]
user image
@sri
Mojo klingt recht interessant. Da ich in naher Zukunft 1-2
Projekte am Hals habe, werde ich es mir ganz sicher mal
anschauen. Ich hoffe nur, dass es mit der Dokumentation
noch klappt und das du Glück mit deinem Antrag hast.
What is a good module? That's hard to say.
What is good code? That's also hard to say.
One man's Thing of Beauty is another's man's Evil Hack.
bloonix
 2008-11-09 13:52
#116124 #116124
User since
2005-12-17
1615 Artikel
HausmeisterIn
[Homepage]
user image
...
What is a good module? That's hard to say.
What is good code? That's also hard to say.
One man's Thing of Beauty is another's man's Evil Hack.
pq
 2008-11-09 15:20
#116133 #116133
User since
2003-08-04
12208 Artikel
Admin1
[Homepage]
user image
ein grosses manko in diesem forum ist, dass man als gast keinen namen angeben kann.
(wie soll man eine diskussion vernünftig verfolgen, wenn da 3 gäste schreiben, und alle als "Gast"?)

natürlich kann jeder "Gast" genauso gute oder schlechte kritik üben wie ein angemeldeter benutzer.
aber imho sollte ein forum gastpostings erst freischalten lassen, das würde nämlich unterbinden,
dass sich diskussionsteilnehmer gegenseitig anpöbeln.

hier bleibt im schlimmsten fall nur die sperrung des threads, und wenn es weiter um das thema
lanx vs. gast geht, dann werde ich das auch tun. hier geht es um mojo, und wenn ihr ansonsten
ein problem miteinander habt, dann macht das in einem extra thread aus.
danke.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
<< |< 1 2 3 4 5 >| >> 46 Einträge, 5 Seiten



View all threads created 2008-09-27 16:53.