PageRenderTime 20ms CodeModel.GetById 7ms RepoModel.GetById 1ms app.codeStats 0ms

/todo/zoopProject.todo

http://zoop.googlecode.com/
Unknown | 132 lines | 131 code | 1 blank | 0 comment | 0 complexity | fb25f7459db2826ecb5b3977d39ade1f MD5 | raw file
Possible License(s): BSD-3-Clause, LGPL-2.1
  1. - configuration
  2. - get a yaml engine into the bootstrap process and move all configs to it
  3. - make all classes in all modules DYNAMICALLY LOADED!!!
  4. - future modules
  5. - mail
  6. - Message
  7. - SmartMessage
  8. - translate
  9. - xml
  10. - works with both php4 and php5
  11. - sequence
  12. - storage
  13. - fpdf
  14. - rospdf
  15. - spell
  16. - cli
  17. - server
  18. - smtp
  19. - http
  20. - session
  21. - sql???
  22. - some sort of guicontrols like thing
  23. - graphic
  24. - contexts for gd, imagemagic, fpdf, rospdf, flash, svg, etc.
  25. - graph
  26. - auth???
  27. - a package/module/bundle manager (like unto gems)
  28. - maybe use the pear module manager
  29. - or rpm
  30. - or apt-get/deb
  31. - roll your own?
  32. - wiki
  33. - have code for translating complicated wiki style formatting into:
  34. - html
  35. - graphic/xml
  36. - filter
  37. - look at the GetPost* functions in pehppy and also see what they have done with the php filtering extension
  38. - ajax
  39. - dojo?
  40. - rad/"scaffolding"
  41. - edit actual files or just produce code for you to copy and paste
  42. - cli first - open in textmate?
  43. - permissions
  44. - caching
  45. - template caching
  46. - url (virtual path) caching
  47. - data / object cache
  48. - query caching
  49. - app variables stored in shared memory
  50. - file (or memory or db) based caching of compiles resources
  51. - logging
  52. - performance logging
  53. - by page
  54. - with custom profile segments
  55. - error logging
  56. - assert / condition logging
  57. - audit logging
  58. - crawl
  59. - a way to crawl sites with a script and curl
  60. - can be used for testing or making an api to a website you don't control
  61. - work on existing modules
  62. - zone
  63. - automatically display templates?
  64. - automatically determine file output type?
  65. - skeleton
  66. - have more than one skeleton
  67. - autogenerate it
  68. - change the way zone params are handled
  69. - no more "function getParamNames..."
  70. - instead use $this->addZoneParam($paramName, $paramType, $extra)
  71. - $paramType is one of {int, identifier, regex, ...}
  72. - maybe default to identifier
  73. - also maybe put a limit on the length (like maybe 20 chars or so)
  74. - change the way page params are handled
  75. - allow you to have a paramsxxx function that corresponds to the pagexxx and postxxx functions
  76. - it will allow you to assign names, validation types and length limits as with zone params above
  77. - they will be optional but will default to using numric indicies for names as it does now, with type identifier and the same default length limit as the zone params above
  78. - apps to port
  79. - translate
  80. - directory
  81. - server module
  82. - http server
  83. - zoop app server
  84. - db server
  85. - dns server
  86. - mail server
  87. - differences
  88. - more advanced security system
  89. - controller
  90. - graphic system
  91. - translation system
  92. - session system
  93. - xml handling???
  94. - workflows
  95. - storage system
  96. - spell checker
  97. - routing mechanism
  98. - we don't have the overhead of complex pattern based routes : but we don't have the flexilibilty either : does it matter in practical terms
  99. - post functions
  100. - rails seems to separate out different actions in the controller whereas we make a switch statement in the post function
  101. - how do they handle the navigation???
  102. - do they prevent the dreaded "do you want to post this data again" message?
  103. - navigation, sequences, etc
  104. - smarty / mizithra tags escaped by default, no h() required
  105. - find often equates to putting sql in your code, we try to do that less
  106. - also the late static binding issue is less of a problem when we wrap everything
  107. - post functions vs the alternatives
  108. - button_to
  109. - you have to include any data that it needs, often you are going to just want data from the form
  110. - it creates a div???, why does it do that. then you need to make special style, mapped to every button to prevent it from doing that
  111. - error handling
  112. - we automatically never now anything in production (although it looks like it does this too)
  113. - design goal
  114. - keep global configurations global and local configurations local (and close to what they affect)
  115. - for example zone params go in the zone not in some big master config file
  116. - security
  117. - make sure you always do all validation
  118. - utils
  119. - make them all static members of a class, also probably just move utils.php into the app module
  120. - gpl
  121. - have a way with integrating with GPL software without exposing yourself to it's licencing conditions
  122. - make these separate projects that
  123. - create a chart server with open flash charts (http://teethgrinder.co.uk/open-flash-chart/tutorial.php) that
  124. adheres to some zoop specific API
  125. - actually only open flash charts one is GPL, version 2 is LGPL, the server might be useful on it's own
  126. - though it would abstract chart creation from the application and make it resuable
  127. - same for flowplayer (http://flowplayer.org/)
  128. - and pChart (http://pchart.sourceforge.net/)
  129. - media
  130. - integrate with open source flash video viewer flowplayer
  131. - make them all static members of a class, also probably just move utils.php into the app module