Author: dr
Date: Thu Feb 14 13:42:58 2008
New Revision: 7369
Log:
- Fixed typoes and set properties.
Modified:
experimental/MvcTools/design/requirements.txt (contents, props changed)
Modified: experimental/MvcTools/design/requirements.txt
==============================================================================
--- experimental/MvcTools/design/requirements.txt [iso-8859-1] (original)
+++ experimental/MvcTools/design/requirements.txt [iso-8859-1] Thu Feb 14
13:42:58 2008
@@ -10,7 +10,7 @@
The scope of this document is to describe the requirements for a component
providing classes to implement a MVC_ architecture for a web application.
This document does not describe the design of the named component, but only
-summarizes the requirements for it as discussed on the developer mailinglist.
+summarizes the requirements for it as discussed on the developer mailing list.
Where suitable, design related topics will be touched, but a dedicated design
document will follow later, defining APIs, classes and the architectural
structure of the component.
@@ -73,13 +73,13 @@
protocols and formats (for example HTTP-GET, HTTP-POST, SOAP for the input
part and HTML, PDF, ReST-webservices for the output part). Therefore,
protocols input and output formats should be abstracted into dedicated
-objects, which are not specific to a certain protocoll or format.
+objects, which are not specific to a certain protocol or format.
Controllers will only receive these abstracted data objects without
knowledge of the used format/protocol, to allow the re-use of 1 controller
with several different input/output sources.
-A benefic side-effect relates to controller-testing: Creating input and
+A beneficial side-effect relates to controller-testing: Creating input and
output mocks and fixtures allows straight-forward TDD.
Summary
@@ -109,7 +109,7 @@
Those two layers should be able to use any number of controllers per-request.
They handle the client-protocol, so that the controller doesn't have work on
raw input data (e.g. GET/POST/...) and does not have to generate any specific
-output format (e.g. HTML, XML, plain text,...) or anythingng that is
+output format (e.g. HTML, XML, plain text,...) or anything that is
protocol-specific. The two layers abstract I/O from the controller as
described in the specific section.
@@ -147,7 +147,7 @@
Routers must also provide a mechanism to create URLs from input-objects, that
may be used to access a certain controller and action with a certain
-view-manager and defined parameters. This method must be accesable from the
+view-manager and defined parameters. This method must be accessible from the
controllers and the view-manager.
Summary
@@ -228,7 +228,7 @@
Those errors cannot be handled by the controller, because they happen
outside of it. A configurable default controller will be called for all
error messages, so the application developer may decide to send
-messages, show or log the occured error. An error during the execution
+messages, show or log the occurred error. An error during the execution
of this default controller will cause a "500 - Internal server error".
As none of the given errors is meant to be displayed to the user of the
@@ -258,7 +258,7 @@
Testing a controller is the key to quality development. Testing manually each
controller can lead to disasters: It's boring to do and therefore humans
-cannot cover all controllers manually after each bugfix. The solution is
+cannot cover all controllers manually after each bug fix. The solution is
test-automation in PHP (e.g. using PHPUnit).
Controllers run with a single argument: An abstract input object.
@@ -295,7 +295,7 @@
======================
HTTP-GET should not be allowed to invoke changes on the model because this
-would cause a violation of HTTP standarts.
+would cause a violation of HTTP standards.
We should keep testing capabilities for the extensions to this component and
the applications build upon it in mind during the design and implementation
@@ -374,7 +374,7 @@
action and abstracts the request/response protocol.
Fixture_
- Fixtures are objects that are set to an arbitary state for testing
+ Fixtures are objects that are set to an arbitrary state for testing
purposes.
Abstraction_
Propchange: experimental/MvcTools/design/requirements.txt
------------------------------------------------------------------------------
svn:keywords = Author Date Revision
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
