Author: Tobias Schlitt
Date: 2007-04-28 09:09:27 +0200 (Sat, 28 Apr 2007)
New Revision: 4941
Log:
- Fix spelling.
Modified:
trunk/ConsoleTools/design/design-1.3.txt
Modified: trunk/ConsoleTools/design/design-1.3.txt
===================================================================
--- trunk/ConsoleTools/design/design-1.3.txt 2007-04-28 06:59:41 UTC (rev
4940)
+++ trunk/ConsoleTools/design/design-1.3.txt 2007-04-28 07:09:27 UTC (rev
4941)
@@ -161,11 +161,11 @@
validate( mixed $result )
This method is responsible for validating a given result. The dialog will
submit the result it received to this method which will indicate if the
- result was valid by a boolean value. To manipulate / fix a retreived result,
+ result was valid by a boolean value. To manipulate / fix a retrieved result,
the dialog implementation can call the fixup() method.
fixup( mixed $result )
A validator can try to fix a given result to be valid. This manipulation can
- be ommited by simply returning the result again. An example for a fixup would
+ be omitted by simply returning the result again. An example for a fixup would
be to convert a date information into a Unix timestamp using strtotime(). The
validate method would then expect an integer value > 0. The dialog
implementation is responsible for calling fixup() as it thinks is appropriate
@@ -287,7 +287,7 @@
===============
The current functionality for handling options and arguments for a console
-based application in eZ Components (mainy the class ezcConsoleInput) has only
+based application in eZ Components (mainly the class ezcConsoleInput) has only
rudimentary support for dealing with arguments. The current possibility is to
either switch arguments on or off and does not allow to specify the following
things:
@@ -299,7 +299,7 @@
The goal of this design section is to provide these 3 features for argument
handling.
-Clearification of terms
+Clarification of terms
-----------------------
Parameter
@@ -328,7 +328,7 @@
In contrast to an option, an argument is not specified using a specific name,
but
by by the order of submission to the program. Arguments can only be given to a
-program, after all options have been speficied.
+program, after all options have been specified.
Example: ::
@@ -336,13 +336,13 @@
"baz" is the value of the first argument, 23 the value of the second one.
-Arguments seperator
+Arguments separator
~~~~~~~~~~~~~~~~~~~
In some cases the semantic for specifying parameters on the console is not
deterministic. Since the algorithm used to parse parameters cannot handle
-nondeterministic semantics, a seperator must be used to determine the border
-between options and arguments. The seperator used is "-- ", which indicates
+nondeterministic semantics, a separator must be used to determine the border
+between options and arguments. The separator used is "-- ", which indicates
that anything following it is an argument and does not belong to the option
before it.
@@ -352,7 +352,7 @@
foo.php --save "bar.txt" -a -- "baz" 23
In the first line, it is not possible to determine if "baz" is the value for
-the parameter "-a" or if it is an argument. The second line clearifies this.
+the parameter "-a" or if it is an argument. The second line clarifies this.
Basic design
------------
@@ -398,7 +398,7 @@
this property is true.
default
This property carries the default value for optional arguments. If these are
- not submitte, the default value will be used as the value property. If no
+ not submitted, the default value will be used as the value property. If no
default value was explicitly defined, it is null and therefore the value
property will be null, if the argument was not submitted.
value
@@ -458,8 +458,8 @@
submitted, all defined arguments will not be allowed.
It is possible, that this behaviour will be enhanced in the future, so that
-options can define a filter rule for arguments instead of a booleon on/off
-switch. But this feature is not in skope of the design given here.
+options can define a filter rule for arguments instead of a boolean on/off
+switch. But this feature is not in scope of the design given here.
Usage example
=============
@@ -552,11 +552,11 @@
above) not reliable, if 2 parameters have the same name. It also makes
implementation more complex (if a parameter is removed, namesake has to come
in place. So, do we want this or not?
-- The property name $argumentsDefinition is ok for the definition part, but
+- The property name $argumentsDefinition is OK for the definition part, but
does actually not make sense, if you access it later to retrieve the value.
Any better naming solution?
- It is sometimes sensible to allow that for 1 argument multiple values are
- sumbitted (e.g. if you expect an undefined number of file names). To resolve
+ submitted (e.g. if you expect an undefined number of file names). To resolve
this, we need to invent a property "multiple" for the ezcConsoleArgument
struct. If multiple is defined for 1 argument, no more arguments must follow,
since the algorithm could not determine easily where the multiple values for
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
