PageRenderTime 19ms CodeModel.GetById 14ms app.highlight 1ms RepoModel.GetById 1ms 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
  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