PageRenderTime 42ms CodeModel.GetById 26ms RepoModel.GetById 0ms app.codeStats 0ms

/todo/site.todo

http://zoop.googlecode.com/
Unknown | 204 lines | 197 code | 7 blank | 0 comment | 0 complexity | 9af3085769f089a1cfba6ba6535be3db MD5 | raw file
Possible License(s): BSD-3-Clause, LGPL-2.1
  1. - new
  2. - figure out how to get file permissions to stick when you checkout/update zoop
  3. - get all of the examples working out of the box
  4. - set up a site where people can explore them
  5. - create a "zoop" app in apps that lets you
  6. - open up each example
  7. - browse it's code
  8. - same for apps
  9. - apps will require a build script to get them all set up though
  10. - old
  11. - google code site
  12. - update the site to reflect the new roadmap and relationship with old zoop
  13. - reference the roadmap indicated on the zoopframework site
  14. - http://zoopframework.com/about/1.5/release-notes
  15. - show how to set up the apps, including zap?
  16. - wiki
  17. - new page: mvc, design patterns, architectures, etc.
  18. - we've been using the common web-MVC terminology because it has been convenient but it's time to get explicit
  19. - list all the articles
  20. - overview of mvc and pac
  21. - general concept of separation of concerns and other patterns
  22. - history of the evolution of zoop controllers, models, views, etc
  23. - crazy mess of everything mixed together, the PHP that everyone hates
  24. - breaking presentation (html generation) out into templates
  25. - trying to implement pretty urls drove me to develop a routing system for requests
  26. - having all of the logic in the zones was obviously terrible, we started to break things out into objects
  27. - it became apparent that almost all of these needed to do db acess and had similar needs, hence DbObject
  28. - so we have templates, zones, and DbObject, not Models, Views and Controller base classes
  29. - controller is such a generic term our zones could be called a front controller (insert the Harry Feuks
  30. rant of several years ago)
  31. - new name for this design pattern
  32. - elements of MVC
  33. - the view has direct access to the model
  34. - are we doing this?
  35. - we have the controller passing stuff in but it is passing in domain objects directly
  36. not using some intermediary format
  37. - obsever pattern
  38. - obviously we don't generally do this on the web, zoop doesn't do this inherently, but it possible
  39. with comet and similar methods
  40. - the controller handles low level events and updates the model which in turn updates the views
  41. - history of MVC
  42. - smalltalk80
  43. - sun
  44. - next
  45. - the guys with the books
  46. - RoR
  47. - django
  48. - struts
  49. - etc
  50. - does anything adhere to strict MVC
  51. - can this work synchronously over the web
  52. - elements of a web app
  53. - routing requests
  54. - to the appropriate view
  55. - to modify the model
  56. - brokering between the view and the model (PAC style vs MVC style)
  57. - should this really be done by the controller?
  58. - one extreme: extract all data from the model in an intermediate format suitable for processing by the view
  59. - the middle ground: gathering appropriate model objects and passing them into the view
  60. - a little further: passing in a root app domain object and letting it get everything it wants from there
  61. - the other extreme: allowing the view to obtain all view objects itself
  62. - what good does the intermediate format do you
  63. - what works well with the templating language
  64. - how much work is done to reformat
  65. - if all data must be brokered it allows you to see exactly what data the view uses
  66. - if you only pass in root heirarchy objects though then you still won't be able to tell
  67. - is it easier to just look at the template to tell or to look at it here
  68. - where should authorization logic go
  69. - in the view?
  70. - in the broker?
  71. - in the model?
  72. - will allowing the view to access the model result in tight coupling
  73. - it didn't have that affect in desktop apps, why would it here
  74. - why would views need it in any way other than anything else
  75. - if the accessors are good then they should be good with everything
  76. - yes you could dump a bunch of view specific stuff in there but you can't prevent all bad behavior any more
  77. than you can keep domain logic out of the template
  78. - decisions, decisions
  79. - if you opt for too little brokering you will sometimes have data that is too hard to format with the template
  80. language, or your templates will be have too much confusing logic that should be separated out
  81. - examples???
  82. - if you do too much brokering then you will do a ton of unnecessary work to reformat the data when it doesn't
  83. need to be reformatted
  84. - examples???
  85. - the awkwardness of the templating language is definitely a concern
  86. - should the reformatting of the info really be outside the view?
  87. - examples
  88. - putting data into a table
  89. - traverse it with DbObject accessors
  90. - have some utility for extracting the data in some format that a table object can understand
  91. - a heirarchical structure
  92. - same as table
  93. - handling events, changes to the model
  94. - navigation
  95. - authentication and authorization
  96. - authorization
  97. - validation
  98. - the main difference between a web app and a desktop app
  99. - there are two event loops
  100. - the request, response loop where events result in generating new views and altering the model
  101. - the local event loop that you handle with javascript that may update the current view or make new requests
  102. - TOC
  103. - Separation of Concerns
  104. - MVC
  105. - PAC and other relevant patterns
  106. - Evolution of Zoop, what Zoop allows you to do
  107. - include notes on how each element in zoop relates to the different patterns
  108. - Recommendation of a specific pattern
  109. - philosophy
  110. - speed (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html)
  111. - this works for developers as well as users
  112. - pain points
  113. - zoop is a distribution
  114. - we are not as opinionated as RoR
  115. - we don't want to reinvent every web component ever made
  116. - we want to take the best of what's out there and
  117. - aggreate it into a distrobution
  118. - wrap it up in the zoop stuff so it is easy to set up, configure and use
  119. - our setup provides sensible defaults
  120. - we try to allow you to swap components in and out as necessary
  121. - if new better stuff comes along you can use that
  122. - publish the release file
  123. - take the release info out and put it in release.todo
  124. - link it to the main project
  125. - downloads
  126. - set up scripts to create nightly snapshots
  127. - don't create the api docs anymore, put them online and let the user make them if he/she wants
  128. - create a wiki page on how to generate the docs yourself
  129. - create the new tarball
  130. - delete the previous days snapshot
  131. - upload the new snapshot
  132. - google code site
  133. - differences betweenteen old zoop and new zoop page
  134. - differences
  135. - general naming conventions
  136. - include all outside dependencies
  137. - no pear
  138. - only support PHP 5.1.x and above
  139. - magic naming schemes
  140. - different magic naming conventions for zones and pages
  141. - api changes
  142. - and changes to class names and method names
  143. - new ways to access zone and page paramaters
  144. - new apis
  145. - view a colorized virtual path
  146. - link both to and from a topic on the users mailing list for people to discuss
  147. - have a "magic" section for every place we use convention over configuration - try to have the best of both worlds
  148. - design goals page
  149. - provide a clear migration path to PHP 5
  150. - external site
  151. - set up a server for it
  152. - have a place to browse the source
  153. - allow you to specify a version number
  154. - use a checked out version
  155. - use syntax hilighting
  156. - maybe have a way to view just snippets of code
  157. - by line number
  158. - by by classs
  159. - by function
  160. - allow you to specify a version number
  161. - nice looking directory listings
  162. - set up all of the examples and example apps so that they work
  163. - eventually we may need to move the documentation there so we can add more structure to it
  164. - google code site
  165. - overhaul the wiki and remove all the cruft
  166. - development web site
  167. - hosting
  168. - steves box
  169. - ryans box
  170. - google app hosting (if they support php someday)
  171. - content
  172. - examples and example apps
  173. - make sure that they all actually run
  174. - make them automatically clear that data at specified times and rebuild some sample data as a way of testing
  175. - set up usable installs of each
  176. - links to the code
  177. - all source code (including examples and docs)
  178. - syntax highlighted
  179. - pulled straight from subversion
  180. - allow you to specify the version
  181. - allow you to specify specific line numbers
  182. - allow you to put special comments delimiting code blocks you want to be able to pull out and display
  183. - current version of the docs
  184. - compare similar applications built with different frameworks
  185. - make some nice apps is the best way possible with zoop
  186. - invite other framework authors to come here and embarass us with how much better their framework is
  187. - have them write up articles on how much better theirs is
  188. - pick ideas that we really think improve on ours and add them to zoop
  189. - try to highlight ways that zoop is better
  190. - application framework comparison
  191. - structured info on the featuers, strenghts, and weaknesses of each framework
  192. - come up with a good list of things that a framework can / should do
  193. - have authors, experts, and users rate each framework
  194. - allow challenges to invite someone to give arguments as to why they deserved a higher score than someone else
  195. - use the application comparisons to highlight arguments
  196. - invite authors and experts from other frameworks to maintain info on their site
  197. - post an article on the future of zoop to the zoop users site