[rhmessaging-commits] rhmessaging commits: r1188 - mgmt/notes.

Author: justi9 Date: 2007-10-30 16:59:27 -0400 (Tue, 30 Oct 2007) New Revision: 1188 Added: mgmt/notes/errors.txt mgmt/notes/justin-todo.txt mgmt/notes/wooly-overview.txt Removed: mgmt/notes/Errors mgmt/notes/InterfaceQuestions mgmt/notes/ProtocolQuestions mgmt/notes/Todo mgmt/notes/WoolyOverview Log: Renames some files in notes Deleted: mgmt/notes/Errors =================================================================== --- mgmt/notes/Errors 2007-10-30 20:55:56 UTC (rev 1187) +++ mgmt/notes/Errors 2007-10-30 20:59:27 UTC (rev 1188) @@ -1,3 +0,0 @@ -[justin@localhost cumindev]$ cumindev-etags -/home/justin/cumindev/cumin/python/cumin/.#model.py: No such file or directory - Deleted: mgmt/notes/InterfaceQuestions =================================================================== --- mgmt/notes/InterfaceQuestions 2007-10-30 20:55:56 UTC (rev 1187) +++ mgmt/notes/InterfaceQuestions 2007-10-30 20:59:27 UTC (rev 1188) @@ -1,5 +0,0 @@ - * Should the default exchange appear in the UI at all? - - * Is there any place in the UI for transient queues and exchanges? - It would seem not, except perhaps in status information. - Deleted: mgmt/notes/ProtocolQuestions =================================================================== --- mgmt/notes/ProtocolQuestions 2007-10-30 20:55:56 UTC (rev 1187) +++ mgmt/notes/ProtocolQuestions 2007-10-30 20:59:27 UTC (rev 1188) @@ -1,19 +0,0 @@ - * Why use null for the default exchange name? It would seem - consistent and more convenient in developing software to use a name - such as "amq.default" - - * Can the routing key of the default binding to the default exchange - for new queues be changed? How different is the default exchange - from other types of exchanges? The docs suggest that the default - binding is for "point and shoot" use of the broker, so it would - make sense if the default exchange only supported simple - queue-named routing keys, no? - - * I didn't run into anything that spelled out the multiplicity of - bindings vis a vis queues. I assumed that queues and exchanges - support many bindings. - - * Can a queue, for instance, be in more than one realm? - - * It strikes me that UML would answer many of my questions. - Deleted: mgmt/notes/Todo =================================================================== --- mgmt/notes/Todo 2007-10-30 20:55:56 UTC (rev 1187) +++ mgmt/notes/Todo 2007-10-30 20:59:27 UTC (rev 1188) @@ -1,111 +0,0 @@ -Big picture - - * A more-or-less complete demonstration of an admin UI - -Higher - -Lower - - * more form inputs, non scalar ones too - - * Add an error banner to form - - * use wsgiref instead of BaseHTTPServer - - * Make sure HTTPServer handles concurrent requests; need to look at - documentation - - - It does not, and it's not easily changed. Will need to switch to - wsgi stuff, I believe. - - * Change declared charset to iso-8859???, not utf-8, since it's - important to be honest - - * Make it a little simpler to express hrefs - - * Make form help buttons pop up a (for now, empty) help page - - * Icons: machine looking thing for vhost. For Cumin in general, I'm - not sure. The hammer and screwdriver? - - * Make item counts in tab labels a little grayer, that is, less - intense than the name - - * If debug is enabled, append a comment to the response containing - render and process traces - - * Add ability to send a test message to a queue - - * Add favicon and a mapping in the server to serve it - - * Separate wooly stuff into its own devel subdir - - * Consider having a cssclass set on widgets - - * Use page attributes for session errors, redirect - - * See if we can eliminate the attr/param distinction, and use whether - or not a param is added to a widget via add_param to do that - - * Add a parameter that takes a modelclass - - * Servers tab - - - Add server to group - - - Find/connect in bulk - - - Add checkboxes and bulk operations - - - Add an ungrouped radio button - - * Func host view - - - Remove config tab - - * Cluster - - - Add load balance action - - - Add remove action - - - Stop, start - - - Display load, profiles (?) - - * Add group type to group add,edit - - * Consider making add_child, add_param, add_mode, add_tab, - etc. return their argument - - * Add a CuminItemSet with add/edit/remove href parts - - * Rename ServerGroupType to ServerGroupCategory - - * Add a frame() accessor to Widget - - * Add a sanity check traversal to the widget tree and to the - registered sets of widgets and parameters - - * Add more bindings to the demo data - - * Add producers to the default exchange - - * queue: link consumers stat to consumers view - - * exch: link bindings, producers stats to respective views - - * model: get rid of the old *_count stat fields and use the new ones - - * Add rates to stats views - - * Right now, non cumin pages don't print their stack traces in the - log - - * Move q,e to server level (using default vhost) - - * Replace all those inline td styles with a class attr - - * Make sure nav links are so marked - - * Make the status lights also be links to an appropriate view Deleted: mgmt/notes/WoolyOverview =================================================================== --- mgmt/notes/WoolyOverview 2007-10-30 20:55:56 UTC (rev 1187) +++ mgmt/notes/WoolyOverview 2007-10-30 20:59:27 UTC (rev 1188) @@ -1,40 +0,0 @@ -Widget - - A display object - - Usually bound to a Template - - May have state represented in Parameters - - Lives in a tree of widgets - - Has a process method - - Manipulates state, both ui state and model state - - Called in the process phase, before rendering - - Has a render method - - Produces HTML - - Called after all processing is done - -Template - - A string with placeholders such as {foo} - - A placeholder {foo} resolves to: widget.render_foo(...) - - Or it resolves to: widget.get_child("foo").render(...) - -Application - - The static state of the app - - Holds Pages - -Page - - A top-level widget with some extra methods for producing HTTP - responses - - The root widget of all widget trees is a page - -Parameter - - Represents state for the life of the request/response - - Attached to a widget - - Stores its session-level state on a Session - - Marshals and unmarshals itself to url params - -Session - - The main source of state - - Can be "branched" for producing "future states", URLs - -ModeSet - - A widget that shows only one of its children - - Used for producing various UI behaviors, tabs for instance - - Generally useful for controlling visibility Copied: mgmt/notes/errors.txt (from rev 1187, mgmt/notes/Errors) =================================================================== --- mgmt/notes/errors.txt (rev 0) +++ mgmt/notes/errors.txt 2007-10-30 20:59:27 UTC (rev 1188) @@ -0,0 +1,3 @@ +[justin@localhost cumindev]$ cumindev-etags +/home/justin/cumindev/cumin/python/cumin/.#model.py: No such file or directory + Copied: mgmt/notes/justin-todo.txt (from rev 1187, mgmt/notes/Todo) =================================================================== --- mgmt/notes/justin-todo.txt (rev 0) +++ mgmt/notes/justin-todo.txt 2007-10-30 20:59:27 UTC (rev 1188) @@ -0,0 +1,111 @@ +Big picture + + * A more-or-less complete demonstration of an admin UI + +Higher + +Lower + + * more form inputs, non scalar ones too + + * Add an error banner to form + + * use wsgiref instead of BaseHTTPServer + + * Make sure HTTPServer handles concurrent requests; need to look at + documentation + + - It does not, and it's not easily changed. Will need to switch to + wsgi stuff, I believe. + + * Change declared charset to iso-8859???, not utf-8, since it's + important to be honest + + * Make it a little simpler to express hrefs + + * Make form help buttons pop up a (for now, empty) help page + + * Icons: machine looking thing for vhost. For Cumin in general, I'm + not sure. The hammer and screwdriver? + + * Make item counts in tab labels a little grayer, that is, less + intense than the name + + * If debug is enabled, append a comment to the response containing + render and process traces + + * Add ability to send a test message to a queue + + * Add favicon and a mapping in the server to serve it + + * Separate wooly stuff into its own devel subdir + + * Consider having a cssclass set on widgets + + * Use page attributes for session errors, redirect + + * See if we can eliminate the attr/param distinction, and use whether + or not a param is added to a widget via add_param to do that + + * Add a parameter that takes a modelclass + + * Servers tab + + - Add server to group + + - Find/connect in bulk + + - Add checkboxes and bulk operations + + - Add an ungrouped radio button + + * Func host view + + - Remove config tab + + * Cluster + + - Add load balance action + + - Add remove action + + - Stop, start + + - Display load, profiles (?) + + * Add group type to group add,edit + + * Consider making add_child, add_param, add_mode, add_tab, + etc. return their argument + + * Add a CuminItemSet with add/edit/remove href parts + + * Rename ServerGroupType to ServerGroupCategory + + * Add a frame() accessor to Widget + + * Add a sanity check traversal to the widget tree and to the + registered sets of widgets and parameters + + * Add more bindings to the demo data + + * Add producers to the default exchange + + * queue: link consumers stat to consumers view + + * exch: link bindings, producers stats to respective views + + * model: get rid of the old *_count stat fields and use the new ones + + * Add rates to stats views + + * Right now, non cumin pages don't print their stack traces in the + log + + * Move q,e to server level (using default vhost) + + * Replace all those inline td styles with a class attr + + * Make sure nav links are so marked + + * Make the status lights also be links to an appropriate view Copied: mgmt/notes/wooly-overview.txt (from rev 1187, mgmt/notes/WoolyOverview) =================================================================== --- mgmt/notes/wooly-overview.txt (rev 0) +++ mgmt/notes/wooly-overview.txt 2007-10-30 20:59:27 UTC (rev 1188) @@ -0,0 +1,40 @@ +Widget + - A display object + - Usually bound to a Template + - May have state represented in Parameters + - Lives in a tree of widgets + - Has a process method + - Manipulates state, both ui state and model state + - Called in the process phase, before rendering + - Has a render method + - Produces HTML + - Called after all processing is done + +Template + - A string with placeholders such as {foo} + - A placeholder {foo} resolves to: widget.render_foo(...) + - Or it resolves to: widget.get_child("foo").render(...) + +Application + - The static state of the app + - Holds Pages + +Page + - A top-level widget with some extra methods for producing HTTP + responses + - The root widget of all widget trees is a page + +Parameter + - Represents state for the life of the request/response + - Attached to a widget + - Stores its session-level state on a Session + - Marshals and unmarshals itself to url params + +Session + - The main source of state + - Can be "branched" for producing "future states", URLs + +ModeSet + - A widget that shows only one of its children + - Used for producing various UI behaviors, tabs for instance + - Generally useful for controlling visibility