Your SlideShare is downloading. ×
WebNano - Ideas for Web Frameworks
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

WebNano - Ideas for Web Frameworks


Published on

My tech meeting talk (18.03.2010).

My tech meeting talk (18.03.2010).

Published in: Self Improvement

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. WebNano
    • Zbigniew Lukasiak (zby)
    Ideas for web libraries and frameworks
  • 2. Richard P. Gabriel "Worse is Better"
  • 3. Nickieben Bourbaki "Worse Is Better Is Worse"
  • 4. Nickieben Bourbaki a pen name of Richard Gabriel
  • 5. Frameworks are framing, libraries are liberating WebNano
  • 6. Frameworks tend to tie many functions together.
  • 7. Coupling
  • 8. Dave Rolsky ”Want Good Tools? Break Your Problems Down”
  • 9. Current frameworks not only deal with the web part of the task – but also create all the objects of the application.
  • 10. Bread::Board – specialized tool Dependency Injection Pattern
  • 11. My experiences (see WebNano tests): It works. But there are no good examples. Lacks integration with standard text config files.
  • 12. Needs to be at least as good as current solutions.
  • 13. Catalyst config files: View::TT: WRAPPER: '' Configuration for each component. Plus logic for loading global and local configs.
  • 14. And maybe we could also get rid of
  • 15. Endless adaptors. Like the many Catalyst views or models. Why not use TT directly? Or Email::Send?
  • 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. WebNano – main ideas Use of Bread::Board Controllers in Request Scope
  • 18. Object Oriented Programming (wikipedia): each instance of which ("objects") contains all the information needed to manipulate its own data structure ("members") My extension: object should contain all data most accessed by it's methods
  • 19. Catalyst controllers: sub index :Path :Args(0) { my ( $self, $c ) = @_; # Hello World $c->response->body( $c->welcome_message ); }
  • 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.
  • 23. Until I read series of blog posts, starting with nothingmuch articles on: Immutable Data Structures
  • 24. I like it - it simplifies a lot of things when used moderately.
  • 25. But it also means that a Catalyst controller cannot contain data about the request.
  • 26. This is a fundamental limitation.
  • 27. Controllers in Request Scope
  • 28. From the many Perl MVC web frameworks only Tatsumaki uses request scope controllers. Rails and Django do.
  • 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).
  • 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.
  • 31. Like with other variables: Create objects in the narrowest scope that needs them.
  • 32. And hopefully get rid of Stash.
  • 33. There are more ideas in Nano
  • 34. Questions?
  • 35. Links
    • 36.
    • 37.
    • 38.
    • 39.
    • 40.
    • 41.