WebNano - Ideas for Web Frameworks

750 views
684 views

Published on

My London.pm tech meeting talk (18.03.2010).

Published in: Self Improvement
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
750
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

WebNano - Ideas for Web Frameworks

  1. 1. WebNano <ul><li>Zbigniew Lukasiak (zby) </li></ul>Ideas for web libraries and frameworks
  2. 2. Richard P. Gabriel &quot;Worse is Better&quot;
  3. 3. Nickieben Bourbaki &quot;Worse Is Better Is Worse&quot;
  4. 4. Nickieben Bourbaki a pen name of Richard Gabriel
  5. 5. Frameworks are framing, libraries are liberating WebNano
  6. 6. Frameworks tend to tie many functions together.
  7. 7. Coupling
  8. 8. Dave Rolsky ”Want Good Tools? Break Your Problems Down”
  9. 9. Current frameworks not only deal with the web part of the task – but also create all the objects of the application.
  10. 10. Bread::Board – specialized tool Dependency Injection Pattern
  11. 11. My experiences (see WebNano tests): It works. But there are no good examples. Lacks integration with standard text config files.
  12. 12. Needs to be at least as good as current solutions.
  13. 13. Catalyst config files: View::TT: WRAPPER: 'wrapper.tt' Configuration for each component. Plus logic for loading global and local configs.
  14. 14. And maybe we could also get rid of
  15. 15. Endless adaptors. Like the many Catalyst views or models. Why not use TT directly? Or Email::Send?
  16. 16. Adaptors add another layer where things can go wrong. They don't add new functionality. They are needed to fit outside libs into the framework. But why we need to squize them there?
  17. 17. WebNano – main ideas Use of Bread::Board Controllers in Request Scope
  18. 18. Object Oriented Programming (wikipedia): each instance of which (&quot;objects&quot;) contains all the information needed to manipulate its own data structure (&quot;members&quot;) My extension: object should contain all data most accessed by it's methods
  19. 19. Catalyst controllers: sub index :Path :Args(0) { my ( $self, $c ) = @_; # Hello World $c->response->body( $c->welcome_message ); }
  20. 20. $c is passed to all methods as an argument, because it is always needed In contrast $self is nearly never used in all examples from Catalyst::Tutorial
  21. 22. The answers never satisfied me. They looked like based on some incidental design choice, nothing that could not be changed.
  22. 23. Until I read series of blog posts, starting with nothingmuch articles on: Immutable Data Structures
  23. 24. I like it - it simplifies a lot of things when used moderately.
  24. 25. But it also means that a Catalyst controller cannot contain data about the request.
  25. 26. This is a fundamental limitation.
  26. 27. Controllers in Request Scope
  27. 28. From the many Perl MVC web frameworks only Tatsumaki uses request scope controllers. Rails and Django do.
  28. 29. Counter argument – what if you have something heavy that you need to use in the controller? No problem the controller can access objects from outer (application scope).
  29. 30. A simple rule of thumb for immutable objects: Objects from narrower scope can contain references to objects in outer scopes, but not the other way around.
  30. 31. Like with other variables: Create objects in the narrowest scope that needs them.
  31. 32. And hopefully get rid of Stash.
  32. 33. There are more ideas in Nano
  33. 34. Questions?
  34. 35. Links <ul><li>http://en.wikipedia.org/wiki/Worse_is_better
  35. 36. http://perlalchemy.blogspot.com/2010/02/frameworks-are-framing-libraries-are.html
  36. 37. http://github.com/zby/WebNano
  37. 38. http://blog.urth.org/2009/11/want-good-tools-break-your-problems-down.html
  38. 39. http://search.cpan.org/~stevan/Bread-Board-0.10/lib/Bread/Board.pm
  39. 40. http://blog.woobling.org/2009/05/immutable-data-structures.html
  40. 41. http://github.com/miyagawa/Tatsumaki </li></ul>

×