/todo/general.todo

http://zoop.googlecode.com/ · Unknown · 92 lines · 92 code · 0 blank · 0 comment · 0 complexity · bf4c68c7e264ee4ee86cb58d0efe93e3 MD5 · raw file

  1. - important stuff
  2. - add in sass: http://sass-lang.com/
  3. - set up pear channels
  4. - necessary modules
  5. - awesome permissions system
  6. - forms
  7. - validation
  8. - saving
  9. - ajax
  10. - use exceptions to help people get set up, don't automatically run schema changes
  11. - good solution for form validation
  12. - check fields on the client
  13. - check fields on the server that can't be checked on the client and return results
  14. - check fields on the server to see if they've been tampered with and throw and error if there's a problem
  15. - hilight fields that need to be fixed and give reasons
  16. - assign field names like _autosave[$classname][$id][$fieldname]
  17. - store the allowed autosave info in the session under a random token name
  18. - store the token in the form
  19. - create a Form::autosave function to be called on post
  20. - foreach _autosave field
  21. - verfify that it's an authorized field
  22. - create the object if necessary
  23. - save the field to the object
  24. - save object that you created
  25. - set up config.yaml in all stationary
  26. - include examples in stationary and tutorials explaining the following
  27. - check out from code.google.com
  28. - including modules
  29. - register class
  30. - setting up the tmp directory, should we have it automatically create sub dirs?
  31. - adding new zones, have ZoneDefault plus two other, document how to add new ones
  32. - better default main.tpl, fix the float problems
  33. - multiple layouts, per app, per zone, per page
  34. - non-default pages, set up several pages in multiple zones
  35. - db, how it get it set up right away
  36. - how to prevent sql injection
  37. - how to prevent script injection
  38. - session
  39. - dbobject
  40. - slightly less important stuff
  41. - creating new projects automatically
  42. - command line tool
  43. - creating zones automatically
  44. - command line tool to do it
  45. - auto configure the includes
  46. - migrations
  47. - create them automatically
  48. - apply all migrations
  49. - apply single migration
  50. - apply latest migratin
  51. - re-apply single / latest migration
  52. - retool zap
  53. - "zones" are identified by the object type, allow for aliases
  54. - an object type can supply code for a list of verbs
  55. - a verb / type can have any number of objects
  56. - capture and pass along flag information
  57. - theory
  58. - provide a wiki page with the theorys behind zoop
  59. - major points
  60. - systems theory (see rad page)
  61. - build a better wheel or steal someone else's
  62. - procedure
  63. - create an api that we need
  64. - find a library that does the heavy lifting
  65. - wrap it
  66. - if there are multiple options include and wrap all of them and use a factory method to choose one
  67. - if you decide you can beat the existing libraries fork one or write it from scratch
  68. - choose which one to use either in config or allow the request to be made in the code for each specific circumstance
  69. - this works best when there are many constantly evolving implementations out there so you might want to swap them in and out
  70. - examples
  71. -
  72. - DRY
  73. - use magic (convention over configuration in Rails terms) in select instances that are
  74. - commonly used
  75. - easily learned
  76. - already started here: http://code.google.com/p/zoop/wiki/Philosophy
  77. - yagni
  78. - Quick and dirty vs slow and clean or... fast and clean
  79. - examples of how we allow you start start with fast and clean but rigid code, but then allow to add flexibility without breaking things (getters, setters, scaffolding etc)
  80. - organic growth
  81. - motivation
  82. - work you want to do vs. work you have to do
  83. - instant gratification
  84. - getting something working quickly
  85. - open source vs closed sorce
  86. - we are not design pattern whores
  87. - we find solutions to problems and use design patterns when they fit
  88. - it seems like people are out there don't know how to actually solve problems so they study a bunch of design patterns and try to apply a standard design pattern to every single problem out there, but it's not always such a great fit
  89. - if I'm really just missing out here, just show me where
  90. - style
  91. - state the point
  92. - provide examlples in zoop