[rhmessaging-commits] rhmessaging commits: r1188 - mgmt/notes.
rhmessaging-commits at lists.jboss.org
rhmessaging-commits at lists.jboss.org
Tue Oct 30 16:59:27 EDT 2007
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 at 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 at 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
More information about the rhmessaging-commits
mailing list