cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Trivial Update of "CocoonBestPractices" by JeremyQuinn
Date Wed, 10 Oct 2007 17:01:39 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by JeremyQuinn:
http://wiki.apache.org/cocoon/CocoonBestPractices

------------------------------------------------------------------------------
  Luminas is a member of the Orixo XML Business Alliance. 
  
  This presentation is about best practises for  development of projects within Cocoon and
is a  distillation of techniques culled from the Cocoon mail  lists and my Orixo colleagues.
+ 
+ You can download or view the [http://people.apache.org/~jeremy/gt2004/talk.html presentation]
  
  = Contents =
  
@@ -31, +33 @@

   * Keep your use cases updated 
   * Find the happy balance 
  
- Use cases are a formalised way of describing how a piece  of software will work from the
point of view of specific  ‘actors’, eg. Users, Admins, The System etc. 
+ Use cases are a formalised way of describing how a piece  of software will work from the
point of view of specific  ‘actors’, eg. Users, Admins, The System etc. 
  
  Luminas are in the process of preparing their in-house  UseCaseML and sample XSLT for the
community to use. 
  
@@ -148, +150 @@

   * Mounting sub-sitemaps 
   * Simple static pipelines 
  
- Your top level (project) sitemap should be set up  carefully. Don’t rely on the default
components from the main  Cocoon sitemap, these could change when you update  Cocoon. Be specific.

+ Your top level (project) sitemap should be set up  carefully. Don’t rely on the default
components from the main  Cocoon sitemap, these could change when you update  Cocoon. Be specific.

  
  Declare the Components you actually use and  parameterise them according to how you need
to use  them in the project. 
  
- We declare authentication regions in the top-level Project  sitemap, but keep authentication
in it’s own sitemap. Some recommend using the container for authentication. 
+ We declare authentication regions in the top-level Project  sitemap, but keep authentication
in it’s own sitemap. Some recommend using the container for authentication. 
  
  If you have simple url patterns for simple static content,  that is re-used in many URIs,
the top-level Project  Sitemap is a good place for these.
  
@@ -177, +179 @@

  	 * Aids management 
   * Use good naming schemes. 
  
- Read and understand the Wiki entry :  “CleanerSiteMapsThroughResources”
+ Read and understand the Wiki entry :  “CleanerSiteMapsThroughResources”
  
  
  = Always use i18n =
@@ -195, +197 @@

  
  i18n dictionaries can be passed off to those with writing  skills i.e. they should not be
written by developers,  remember what they say about developers not being able  to write documentation
!!! 
  
- We have experienced problems with different Server  OSes outputting UTF-8 inconsistently,
specifically the  ‘high’ characters. Test thoroughly!!!
+ We have experienced problems with different Server  OSes outputting UTF-8 inconsistently,
specifically the  ‘high’ characters. Test thoroughly!!!
  
  
  = Relational Databases =
@@ -288, +290 @@

  
   * Test before committing 
   * Commit early, commit often 
-  * Don’t commit built material 
+  * Don’t commit built material 
-  * Don’t commit local customisation 
+  * Don’t commit local customisation 
   * Read commit-mails 
  
  Use Source Code Management tools like CVS or  Subversion etc. 
@@ -302, +304 @@

  
  Don't check-in generated build results, rebuild them on  each build-run. 
  
- Don’t commit local.build.properties. 
+ Don’t commit local.build.properties. 
  
  Provide commitmails and viewcvs.cgi on your repos. 
  
@@ -321, +323 @@

  
  If you have databases in your project, have scripts that  load a consistent test dataset
into them. 
  
- Choose one of the build patterns in the Wiki:  “YourCocoonBasedProject”,  “YourCocoonBasedProjectAnt16”,
“ProjectBuilding”. 
+ Choose one of the build patterns in the Wiki:  “YourCocoonBasedProject”,  “YourCocoonBasedProjectAnt16”,
“ProjectBuilding”. 
  
  The main criteria seem to be: 
  	One or many developers. 
@@ -341, +343 @@

  
  You can use it for notifying the group of the addition and  completion of bugs, tracking
their progress and  discussing their details. 
  
- “Bug” can seem like a very rude word to the hardworking developer .... I remember feeling
“That is not a  bug, it is the result of a poor specification !!”. 
+ “Bug” can seem like a very rude word to the hardworking developer .... I remember feeling
“That is not a  bug, it is the result of a poor specification !!”. 
  
- Remember, “Bugs” can include visual, behavioural,  communicative and logical problems
with all aspects of  the project, not just the source code. Bugs can include  enhancements
and feature requests. 
+ Remember, “Bugs” can include visual, behavioural,  communicative and logical problems
with all aspects of  the project, not just the source code. Bugs can include  enhancements
and feature requests. 
  
  Tip: Warn developers to mind their language if the client  is subscribed to Bugzilla as
well ;) 
  
@@ -359, +361 @@

  
  Disable dangerous components and features, including  views, cocoon-reload, cocoon-status,
cache-clearance  etc. 
  
- Don't run cocoon in a publicly-visible way. Close the ports used by your Servlet engine.
Run with a front-end proxy (see the Wiki:  “ApacheModProxy”). 
+ Don't run cocoon in a publicly-visible way. Close the ports used by your Servlet engine.
Run with a front-end proxy (see the Wiki:  “ApacheModProxy”). 
  
  Get Apache to provide error pages if the Servlet goes  down or is under maintenance. This
way developers  working directly from the Servlet, get to see verbose  error messages, while
users see something polite. 
  
@@ -373, +375 @@

  
   * Read the manual 
   * Search the Wiki or Mail Lists 
-  * Ask on the User’s 
+  * Ask on the User’s 
   * List Write your solution in the Wiki 
   * Report errors in the documentation 
  
@@ -395, +397 @@

  
  When pulling in external content, pass it through Tidy if  it is HTML, and clean it through
XSLT in an intelligent  way if it is XML, so that the mess made by others cannot  break your
processes. 
  
- When handling URIs, apply the “Process of least  surprise”, when handling form inputs,
provide sensible  defaults for missing values where possible. 
+ When handling URIs, apply the “Process of least  surprise”, when handling form inputs,
provide sensible  defaults for missing values where possible. 
  
  When sending pages, make sure you validate against the  relevant standards. When you output
HTML, validate  against the WAI standards. 
  
- Don’t fight against the SoC that is embedded in Cocoon,  embrace it, it is your friend!!!
There is a very good reason  Cocoon works like that. Even if you are a sole developer  prototyping
a project, separate!!! Sooner or later, other  people will be sharing the work.
+ Don’t fight against the SoC that is embedded in Cocoon,  embrace it, it is your friend!!!
There is a very good reason  Cocoon works like that. Even if you are a sole developer  prototyping
a project, separate!!! Sooner or later, other  people will be sharing the work.
  

Mime
View raw message