/todo/site.todo
Unknown | 204 lines | 197 code | 7 blank | 0 comment | 0 complexity | 9af3085769f089a1cfba6ba6535be3db MD5 | raw file
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 133 134 135 136 137 138 - google code site 139 - differences betweenteen old zoop and new zoop page 140 - differences 141 - general naming conventions 142 - include all outside dependencies 143 - no pear 144 - only support PHP 5.1.x and above 145 - magic naming schemes 146 - different magic naming conventions for zones and pages 147 - api changes 148 - and changes to class names and method names 149 - new ways to access zone and page paramaters 150 - new apis 151 - view a colorized virtual path 152 - link both to and from a topic on the users mailing list for people to discuss 153 - have a "magic" section for every place we use convention over configuration - try to have the best of both worlds 154 - design goals page 155 - provide a clear migration path to PHP 5 156 - external site 157 - set up a server for it 158 - have a place to browse the source 159 - allow you to specify a version number 160 - use a checked out version 161 - use syntax hilighting 162 - maybe have a way to view just snippets of code 163 - by line number 164 - by by classs 165 - by function 166 - allow you to specify a version number 167 - nice looking directory listings 168 - set up all of the examples and example apps so that they work 169 - eventually we may need to move the documentation there so we can add more structure to it 170 171 - google code site 172 - overhaul the wiki and remove all the cruft 173 - development web site 174 - hosting 175 - steves box 176 - ryans box 177 - google app hosting (if they support php someday) 178 - content 179 - examples and example apps 180 - make sure that they all actually run 181 - make them automatically clear that data at specified times and rebuild some sample data as a way of testing 182 - set up usable installs of each 183 - links to the code 184 - all source code (including examples and docs) 185 - syntax highlighted 186 - pulled straight from subversion 187 - allow you to specify the version 188 - allow you to specify specific line numbers 189 - allow you to put special comments delimiting code blocks you want to be able to pull out and display 190 - current version of the docs 191 - compare similar applications built with different frameworks 192 - make some nice apps is the best way possible with zoop 193 - invite other framework authors to come here and embarass us with how much better their framework is 194 - have them write up articles on how much better theirs is 195 - pick ideas that we really think improve on ours and add them to zoop 196 - try to highlight ways that zoop is better 197 - application framework comparison 198 - structured info on the featuers, strenghts, and weaknesses of each framework 199 - come up with a good list of things that a framework can / should do 200 - have authors, experts, and users rate each framework 201 - allow challenges to invite someone to give arguments as to why they deserved a higher score than someone else 202 - use the application comparisons to highlight arguments 203 - invite authors and experts from other frameworks to maintain info on their site 204 - post an article on the future of zoop to the zoop users site