You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2003/10/06 18:00:04 UTC
[WIKI-UPDATE] CocoonFeatureRequests OurWishlists GT2003Usability GT2003HackathonUsability Mon Oct 6 18:00:04 2003
Page: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests , version: 3 on Mon Oct 6 15:37:47 2003 by 157.193.102.50
+ * implement the "select" attribute for cached include in the CIncludeTransformer (from bug 13329)
Page: http://wiki.cocoondev.org/Wiki.jsp?page=OurWishlists , version: 11 on Mon Oct 6 15:23:28 2003 by BertrandDelacretaz
+ * [CocoonFeatureRequests] is about Cocoon features
+
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Usability , version: 6 on Mon Oct 6 15:39:10 2003 by BertrandDelacretaz
+ See [GT2003HackathonUsability].
- !!! Matthew Langham takes the stage
-
- * How can be do to make Cocoon usability better?
-
- * How do we get people started?
-
- * What problems do newbies encounter?
-
- !! Possible improvements
-
- Matthew sees three areas (suggestions freely added by notetakers based on audience reactions and discussions):
-
- ! Getting started
- * Too many choices? (eg. FormHandling, InputModules etc.)
- ** Publish more Best Practices?
- ** Have better samples, more like tutorials than just simple tests of our stuff
- ** Samples which are also documentation, self-explaining
- ** Javadoc-like documentation of the sitemap (using annotations), XSLT and maybe other stuff. Modifying the TreeProcessor to ignore an "annotation" namespace would enable this
- ** Tool for 'JavaScriptDoc' [http://sourceforge.net/projects/jsdoc/] or [http://lxr.mozilla.org/mozilla/source/js/rhino/examples/jsdoc.js]
-
- * I don't understand the error messages
- ** Standardized terminology for error messages?
- ** Sitemap-level stack traces, to know which use of which component caused the problem (sitemap line number, pipeline reference, etc)
-
- * I don't understand the logs
- ** I have a hard time using the log system (selecting which categories to log, etc.)
- ** SAX-based architecture makes it hard to find out where an error occurs
- ** How do I turn off logs completely, for Production?
-
- Forrest has been good at leading beginners, after "forrest site" you get a message telling you what to do next, etc.
-
- ! Configuration (may be cleared up a bit with RealBlocks™)
- * cocoon.xconf
- * Sitemaps
- * Relationship between Cocoon configuration and container (TomCat, Jetty, Apache HTTPD) configuration and logs
-
- Sylvain has some suggestions:
-
- * Having default configurations in all components, so that an empty or nearly-empty cocoon.xconf would define "reasonable" defaults.
-
- * Dynamically discover components which implement certain roles to suppress the required declarations of components.
-
- * Use variable strings in .xconf files, for example for database URLs, usernames, etc.
-
- Seems hard to implement, and hiding everything might not help users?.
-
- But there's agreement on the basic idea: simplifying configurations.
-
- * What is Cocoon?
- ** After so many years, my Boss still asks this, what do I SAY?
-
- ! Change management
-
- * Moving from Dev server to a Production Server
- ** Blocks will help
- * Upgrading an existing server
- * Upgrading my project within a running Cocoon
-
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonUsability , version: 1 on Mon Oct 6 15:12:58 2003 by JeremyQuinn
New page created:
+ !!! Matthew Langham takes the stage
+
+ * How can be do to make Cocoon usability better?
+
+ * How do we get people started?
+
+ * What problems do newbies encounter?
+
+ !! Possible improvements
+
+ Matthew sees three areas (suggestions freely added by notetakers based on audience reactions and discussions):
+
+ ! Getting started
+ * Too many choices? (eg. FormHandling, InputModules etc.)
+ ** Publish more Best Practices?
+ ** Have better samples, more like tutorials than just simple tests of our stuff
+ ** Samples which are also documentation, self-explaining
+ ** Javadoc-like documentation of the sitemap (using annotations), XSLT and maybe other stuff. Modifying the TreeProcessor to ignore an "annotation" namespace would enable this
+ ** Tool for 'JavaScriptDoc' [sourceforge|http://sourceforge.net/projects/jsdoc/] or [mozilla|http://lxr.mozilla.org/mozilla/source/js/rhino/examples/jsdoc.js]
+
+ * I don't understand the error messages
+ ** Standardized terminology for error messages?
+ ** Sitemap-level stack traces, to know which use of which component caused the problem (sitemap line number, pipeline reference, etc)
+
+ * I don't understand the logs
+ ** I have a hard time using the log system (selecting which categories to log, etc.)
+ ** SAX-based architecture makes it hard to find out where an error occurs
+ ** How do I turn off logs completely, for Production?
+
+ Forrest has been good at leading beginners, after "forrest site" you get a message telling you what to do next, etc.
+
+ ! Configuration (may be cleared up a bit with RealBlocks™)
+ * cocoon.xconf
+ * Sitemaps
+ * Relationship between Cocoon configuration and container (TomCat, Jetty, Apache HTTPD) configuration and logs
+
+ Sylvain has some suggestions:
+
+ * Having default configurations in all components, so that an empty or nearly-empty cocoon.xconf would define "reasonable" defaults.
+
+ * Dynamically discover components which implement certain roles to suppress the required declarations of components.
+
+ * Use variable strings in .xconf files, for example for database URLs, usernames, etc.
+
+ Seems hard to implement, and hiding everything might not help users?.
+
+ But there's agreement on the basic idea: simplifying configurations.
+
+ * What is Cocoon?
+ ** After so many years, my Boss still asks this, what do I SAY?
+
+ ! Change management
+
+ * Moving from Dev server to a Production Server
+ ** Blocks will help
+ * Upgrading an existing server
+ * Upgrading my project within a running Cocoon
+
+