Your SlideShare is downloading. ×
BarCampLondon6: Agavi
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

BarCampLondon6: Agavi

591
views

Published on

A presentation on the Agavi framework I gave at BarCamp London #6 on March 28, 2009.

A presentation on the Agavi framework I gave at BarCamp London #6 on March 28, 2009.

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
591
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
















































































































































































  • Transcript

    • 1. Agavi PHP MVC Framework
    • 2. David Zülke
    • 3. David Zuelke
    • 4. • Managing Partner (and Co-Founder) at Bitextender GmbH, based in Munich.de • We’ve been doing development, consulting and training for 5+ years. • The company behind Agavi, backing and developing it.
    • 5. But let’s move on to the non-boring stuff, shall we?
    • 6. From Mojavi to Agavi
    • 7. From Mojavi to Agavi A brief history lesson.
    • 8. Mojavi 1, 2 and 3 were developed by Sean Kerr.
    • 9. Mojavi 1, 2 and 3 were developed by Sean Kerr. Development wasn’t open and transparent, despite the license (and awesomeness!), and died eventually.
    • 10. Mojavi 1, 2 and 3 were developed by Sean Kerr. Development wasn’t open and transparent, despite the license (and awesomeness!), and died eventually. Forked in 2005 and given the name Agavi (presumably because Agave plants grow in the Mojave desert).
    • 11. Mojavi 1, 2 and 3 were developed by Sean Kerr. Development wasn’t open and transparent, despite the license (and awesomeness!), and died eventually. Forked in 2005 and given the name Agavi (presumably because Agave plants grow in the Mojave desert). Since late 2005, Agavi is maintained by Bitextender.
    • 12. Mojavi 1, 2 and 3 were developed by Sean Kerr. Development wasn’t open and transparent, despite the license (and awesomeness!), and died eventually. Forked in 2005 and given the name Agavi (presumably because Agave plants grow in the Mojave desert). Since late 2005, Agavi is maintained by Bitextender. symfony is also based on Mojavi 3.
    • 13. Mojavi 1, 2 and 3 were developed by Sean Kerr. Development wasn’t open and transparent, despite the license (and awesomeness!), and died eventually. Forked in 2005 and given the name Agavi (presumably because Agave plants grow in the Mojave desert). Since late 2005, Agavi is maintained by Bitextender. symfony is also based on Mojavi 3. Not too much Mojavi 3 legacy code left anymore.
    • 14. Speaking of Mojavi...
    • 15. Speaking of Mojavi... Sean Kerr is back from the dead, and loves Agavi!
    • 16. Speaking of Mojavi... Sean Kerr is back from the dead, and loves Agavi!
    • 17. Speaking of Mojavi... Sean Kerr is back from the dead, and loves Agavi!
    • 18. Agavi
    • 19. Agavi Key Features and Differences.
    • 20. No Assumptions
    • 21. No Assumptions Being PHP based, it works best for websites and other HTTP-based stuff, but you can use it to write any app.
    • 22. No Assumptions Being PHP based, it works best for websites and other HTTP-based stuff, but you can use it to write any app. No requirements for specific template engines, DBMSes, ORMs, client side JS libraries etc.
    • 23. No Assumptions Being PHP based, it works best for websites and other HTTP-based stuff, but you can use it to write any app. No requirements for specific template engines, DBMSes, ORMs, client side JS libraries etc. Abstraction of HTTP request method verbs, output types, response implementations etc.
    • 24. No Assumptions Being PHP based, it works best for websites and other HTTP-based stuff, but you can use it to write any app. No requirements for specific template engines, DBMSes, ORMs, client side JS libraries etc. Abstraction of HTTP request method verbs, output types, response implementations etc. Form Handling is independent of libraries, template engines etc.
    • 25. Reuse Code
    • 26. Reuse Code The right things are done in the right places, and the framework prevents common mistakes.
    • 27. Reuse Code The right things are done in the right places, and the framework prevents common mistakes. Exposing Actions of a web application through a SOAP web service API etc. can be done in minutes.
    • 28. Reuse Code The right things are done in the right places, and the framework prevents common mistakes. Exposing Actions of a web application through a SOAP web service API etc. can be done in minutes. Want an RSS feed of your latest products? It’s just a new output type away.
    • 29. Reuse Code The right things are done in the right places, and the framework prevents common mistakes. Exposing Actions of a web application through a SOAP web service API etc. can be done in minutes. Want an RSS feed of your latest products? It’s just a new output type away. Want to return JSON for Ajax features? Have it done when a JS framework sends the right request headers!
    • 30. Environments and Contexts
    • 31. Environments and Contexts An Environment is bootstrapped for every box or developer. Could be “production”, or “dev-joecool” etc.
    • 32. Environments and Contexts An Environment is bootstrapped for every box or developer. Could be “production”, or “dev-joecool” etc. A Context represents a way of accessing the application, like “web”, “soap” or “console”.
    • 33. Environments and Contexts An Environment is bootstrapped for every box or developer. Could be “production”, or “dev-joecool” etc. A Context represents a way of accessing the application, like “web”, “soap” or “console”. Any configuration can be specific to one or more Environment(s) and/or Context(s). → no more copying and overwriting of DB configs!
    • 34. Modules, Actions, Views etc
    • 35. Modules, Actions, Views etc An Application has a number of Modules.
    • 36. Modules, Actions, Views etc An Application has a number of Modules. Each Module has Actions with corresponding Views and Templates, as well as various configuration files that control caching, validation and so on.
    • 37. Modules, Actions, Views etc An Application has a number of Modules. Each Module has Actions with corresponding Views and Templates, as well as various configuration files that control caching, validation and so on. Actions, which can also be nested into folders, contain application logic, make calls to Models, and have one or more Views (“Error”, “Success”, “Input” etc.)
    • 38. Modules, Actions, Views etc An Application has a number of Modules. Each Module has Actions with corresponding Views and Templates, as well as various configuration files that control caching, validation and so on. Actions, which can also be nested into folders, contain application logic, make calls to Models, and have one or more Views (“Error”, “Success”, “Input” etc.) Views handle presentation, usually using Templates.
    • 39. Execution Containers
    • 40. Execution Containers Every Action execution happens in an isolated Container.
    • 41. Execution Containers Every Action execution happens in an isolated Container. Every container has it’s own request data, response, filters etc.
    • 42. Execution Containers Every Action execution happens in an isolated Container. Every container has it’s own request data, response, filters etc. A normal execution does not affect the “outside world”.
    • 43. Execution Containers Every Action execution happens in an isolated Container. Every container has it’s own request data, response, filters etc. A normal execution does not affect the “outside world”. Internal forwarding can be done by returning a new Container from a View.
    • 44. Filters
    • 45. Filters Global Filters or per-Action/Container filters.
    • 46. Filters Global Filters or per-Action/Container filters. Wrap the execution, and call the next Filter in the chain - like an Onion or a Russian Nested Doll.
    • 47. Filters Global Filters or per-Action/Container filters. Wrap the execution, and call the next Filter in the chain - like an Onion or a Russian Nested Doll. Features like Security or Form Handling are implemented using Filters inside Agavi.
    • 48. Filters Global Filters or per-Action/Container filters. Wrap the execution, and call the next Filter in the chain - like an Onion or a Russian Nested Doll. Features like Security or Form Handling are implemented using Filters inside Agavi. Flow can be redirected internally, response info can be modified etc; numerous possibilities.
    • 49. Layers and Layouts
    • 50. Layers and Layouts A View can leave instructions on Templates to render; these are called Layers.
    • 51. Layers and Layouts A View can leave instructions on Templates to render; these are called Layers. Each Layer has access to the output of the previous Layers, and can define Slots - Containers with Actions that are run before rendering, returning the content.
    • 52. Layers and Layouts A View can leave instructions on Templates to render; these are called Layers. Each Layer has access to the output of the previous Layers, and can define Slots - Containers with Actions that are run before rendering, returning the content. Layer and Slot definitions can be made in a configuration file; the result is a Layout.
    • 53. Layers and Layouts A View can leave instructions on Templates to render; these are called Layers. Each Layer has access to the output of the previous Layers, and can define Slots - Containers with Actions that are run before rendering, returning the content. Layer and Slot definitions can be made in a configuration file; the result is a Layout. All this can be done programmatically, as well.
    • 54. Routing
    • 55. Routing Used for matching URLs, SOAP method names.
    • 56. Routing Used for matching URLs, SOAP method names. Every route can have children.
    • 57. Routing Used for matching URLs, SOAP method names. Every route can have children. Callbacks can control and modify behavior on matching or when generating URLs.
    • 58. Routing Used for matching URLs, SOAP method names. Every route can have children. Callbacks can control and modify behavior on matching or when generating URLs. Routes can also set Output Types, force continuing of execution even though they matched, and much more.
    • 59. Routing Used for matching URLs, SOAP method names. Every route can have children. Callbacks can control and modify behavior on matching or when generating URLs. Routes can also set Output Types, force continuing of execution even though they matched, and much more. Also very nice for refactoring existing applications.
    • 60. Form Handling
    • 61. Form Handling Form Population Filter makes form handling a breeze.
    • 62. Form Handling Form Population Filter makes form handling a breeze. Can pre-populate forms using given values.
    • 63. Form Handling Form Population Filter makes form handling a breeze. Can pre-populate forms using given values. Re-populates a form when an error occurred.
    • 64. Form Handling Form Population Filter makes form handling a breeze. Can pre-populate forms using given values. Re-populates a form when an error occurred. Highlights erroneous fields and labels.
    • 65. Form Handling Form Population Filter makes form handling a breeze. Can pre-populate forms using given values. Re-populates a form when an error occurred. Highlights erroneous fields and labels. Can insert error messages into the document.
    • 66. Form Handling Form Population Filter makes form handling a breeze. Can pre-populate forms using given values. Re-populates a form when an error occurred. Highlights erroneous fields and labels. Can insert error messages into the document. All without a single line of code in templates.
    • 67. Caching
    • 68. Caching Cache the entire execution of a request, or just parts.
    • 69. Caching Cache the entire execution of a request, or just parts. Action-based, so a Slot that runs can be cached, too.
    • 70. Caching Cache the entire execution of a request, or just parts. Action-based, so a Slot that runs can be cached, too. Output can be cached on a per-layer basis, so that the outer master template always runs even when cached.
    • 71. Caching Cache the entire execution of a request, or just parts. Action-based, so a Slot that runs can be cached, too. Output can be cached on a per-layer basis, so that the outer master template always runs even when cached. Also caches cookies (with correct lifetime!), HTTP headers that were set etc.
    • 72. Caching Cache the entire execution of a request, or just parts. Action-based, so a Slot that runs can be cached, too. Output can be cached on a per-layer basis, so that the outer master template always runs even when cached. Also caches cookies (with correct lifetime!), HTTP headers that were set etc. Stampede Protection will be included in Agavi 1.0
    • 73. Validation
    • 74. Validation Validates not only request parameters, but also Files, Cookies and HTTP Headers.
    • 75. Validation Validates not only request parameters, but also Files, Cookies and HTTP Headers. Default settings mean you only have access to data you validated.
    • 76. Validation Validates not only request parameters, but also Files, Cookies and HTTP Headers. Default settings mean you only have access to data you validated. Drastically reduces the possibility of programmer errors.
    • 77. Validation Validates not only request parameters, but also Files, Cookies and HTTP Headers. Default settings mean you only have access to data you validated. Drastically reduces the possibility of programmer errors. Validators can have dependencies (“only validate email if checkbox is on”), different severities, handle arrays, normalize values (e.g. make Unix TS from date value).
    • 78. Security
    • 79. Security Security Filter is the internal mechanism to auto-check against credentials, authentication status etc.
    • 80. Security Security Filter is the internal mechanism to auto-check against credentials, authentication status etc. Ships with plain and RBAC implementations, easily extensible.
    • 81. Security Security Filter is the internal mechanism to auto-check against credentials, authentication status etc. Ships with plain and RBAC implementations, easily extensible. Provided implementations work with the standard getCredentials() and isSecure() methods on Actions; any other behavior, additional authentication levels etc can be implemented in a custom Security Filter.
    • 82. Internationalization
    • 83. Internationalization Bundles the Unicode CLDR database with information about all locales of this world.
    • 84. Internationalization Bundles the Unicode CLDR database with information about all locales of this world. Functions for translating text, formatting and parsing dates, numbers and currency values, calendar and timezone operations, locale information (e.g. list of all countries in Japanese language etc.)
    • 85. Internationalization Bundles the Unicode CLDR database with information about all locales of this world. Functions for translating text, formatting and parsing dates, numbers and currency values, calendar and timezone operations, locale information (e.g. list of all countries in Japanese language etc.) Parts of the functionality are ports of ICU, IBM’s Java/C library for globalization.
    • 86. That was 12 slides full of bullet points. Genuinely sorry.
    • 87. Showcase
    • 88. Showcase Proof that it’s not just all theory.
    • 89. The Chuckwalla
    • 90. The Chuckwalla A fat lizard from the Mojave desert (likely eats Agaves).
    • 91. The Chuckwalla A fat lizard from the Mojave desert (likely eats Agaves). Was a prototype IRC bot application with an IRC Context and a Web interface.
    • 92. The Chuckwalla A fat lizard from the Mojave desert (likely eats Agaves). Was a prototype IRC bot application with an IRC Context and a Web interface. IRC Routing implementation matched patterns against incoming messages.
    • 93. The Chuckwalla A fat lizard from the Mojave desert (likely eats Agaves). Was a prototype IRC bot application with an IRC Context and a Web interface. IRC Routing implementation matched patterns against incoming messages. <configuration context=quot;ircquot;> <!-- so someone can type quot;!seen Wombertquot; on IRC --> <route pattern=quot;^!seen (username:S+)$quot; action=quot;LastSeenquot; /> </configuration> <configuration context=quot;webquot;> <!-- on the web, the URL is /seen/Wombert --> <route pattern=quot;^/seen/(username:S+)$quot; action=quot;LastSeenquot; /> </configuration>
    • 94. Hands-On
    • 95. Hands-On The Agavi Sample Application
    • 96. !e End
    • 97. Oh wait.
    • 98. One More Thing...
    • 99. One More Thing... We have a brand new Agavi Guide! Much more comprehensive than the old Tutorial.
    • 100. Questions?
    • 101. Thank You for Attending! Shoot me an E-Mail: david.zuelke@bitextender.com Follow @dzuelke and @agavi on Twitter Slides are available online at http://talks.wombert.de/ http://agavi.org/ is the Agavi website With Trac, Mailing Lists, PEAR Channel, Docs, ... Join the Agavi IRC channel: #agavi on irc.freenode.net