cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stev...@outerthought.org
Subject [WIKI-UPDATE] CocoonFeatureRequests OurWishlists GT2003Usability GT2003HackathonUsability Mon Oct 6 18:00:04 2003
Date Mon, 06 Oct 2003 16:00:04 GMT
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
+ 
+ 



Mime
View raw message