[qooxdoo-commit] SF.net SVN: qooxdoo:[22857] trunk/qooxdoo/documentation/manual/source/pages

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Revision: 22857
          http://qooxdoo.svn.sourceforge.net/qooxdoo/?rev=22857&view=rev
Author:   d_wagner
Date:     2010-07-29 13:06:38 +0000 (Thu, 29 Jul 2010)

Log Message:
-----------
RST formatting fixes, mostly heading hierarchy

Modified Paths:
--------------
    trunk/qooxdoo/documentation/manual/source/pages/core/classes.rst
    trunk/qooxdoo/documentation/manual/source/pages/core/interfaces.rst
    trunk/qooxdoo/documentation/manual/source/pages/core/property_features.rst
    trunk/qooxdoo/documentation/manual/source/pages/development/development_tools.rst
    trunk/qooxdoo/documentation/manual/source/pages/gui_toolkit/ui_develop.rst
    trunk/qooxdoo/documentation/manual/source/pages/tool/generator_config_articles.rst

Modified: trunk/qooxdoo/documentation/manual/source/pages/core/classes.rst
===================================================================

--- trunk/qooxdoo/documentation/manual/source/pages/core/classes.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/core/classes.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -210,13 +210,10 @@
 Inheritance
 ===========
 
-XXX
----
-
 .. _pages/classes#single_inheritance:
 
 Single Inheritance
-^^^^^^^^^^^^^^^^^^
+------------------
 
 JavaScript supports the concept of single inheritance. It does not support (true) multiple inheritance like C++. Most people agree on the fact that such a concept tends to be very complex and error-prone. There are other ways to shoot you in the foot. qooxdoo only allows for single inheritance as well:
 
@@ -229,21 +226,21 @@
 .. _pages/classes#multiple_inheritance:
 
 Multiple Inheritance
-^^^^^^^^^^^^^^^^^^^^
+--------------------
 
 Not supported. There are more practical and less error-prone solutions that allow for typical features of multiple inheritance: Interfaces and Mixins (see below).
 
 .. _pages/classes#polymorphism_overriding:
 
 Polymorphism (Overriding)
-^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------
 
 qooxdoo does, of course, allow for polymorphism, that is most easily seen in the ability to override methods in derived classes.
 
 .. _pages/classes#calling_the_superclass_constructor:
 
 Calling the Superclass Constructor
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------------------------------
 
 It is hard to come up with an appealing syntax and efficient implementation for calling the superclass constructor from the constructor of a derived class. You simply cannot top Java's ``super()`` here. At least there is some generic way that does not involve to use the superclass name explicitly:
 
@@ -263,7 +260,7 @@
 .. _pages/classes#calling_an_overridden_method:
 
 Calling an Overridden Method
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------------------------
 
 Calling an overridden superclass method from within the overriding method (i.e. both methods have the same name) is similar to calling the superclass constructor:
 
@@ -281,7 +278,7 @@
 .. _pages/classes#calling_the_superclass_method_or_constructor_with_all_parameters:
 
 Calling the Superclass Method or Constructor with all parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------------------------------------------------------------
 
 This variant allows to pass all the parameters (unmodified):
 
@@ -309,7 +306,7 @@
 .. _pages/classes#calling_another_static_method:
 
 Calling another Static Method
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------
 
 Here is an example for calling a static member without using a fully-qualified class name (compare to ``this.base(arguments)`` above):
 

Modified: trunk/qooxdoo/documentation/manual/source/pages/core/interfaces.rst
===================================================================
--- trunk/qooxdoo/documentation/manual/source/pages/core/interfaces.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/core/interfaces.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -5,12 +5,6 @@
 
 qooxdoo supports Java like interfaces. 
 
-<html>
-<!--
-Interfaces can be used to validate the signatures of objects at runtime.
--->
-</html>
-
 .. _pages/interfaces#defining_interfaces:
 
 Defining Interfaces
@@ -51,34 +45,31 @@
        }
     });
 
-XXX
----
-
 .. _pages/interfaces#definition:
 
 Definition
-^^^^^^^^^^
+----------
 
 Interfaces are declared using ``qx.Interface.define``. Interface names start by convention with an ``I`` (uppercase "i"). They can inherit from other interfaces using the ``extend`` key. Multiple inheritance of interfaces is supported.
 
 .. _pages/interfaces#properties:
 
 Properties
-^^^^^^^^^^
+----------
 
 Properties in interfaces state that each class implementing this interface must have a property of the given name. The :doc:`property definition <defining_properties>` is not evaluated and may be empty.
 
 .. _pages/interfaces#members:
 
 Members
-^^^^^^^
+-------
 
 The member section of the interface lists all member functions which must be implemented. The function body is used as a precondition of the implementation. By implementing an interface the qooxdoo class definition automatically wraps all methods required by the interface. Before the actual implementation is called, the precondition of the interface is called with the same arguments. The precondition should raise an exception if the arguments are don't meet the expectations. Usually the methods defined in `qx.core.MAssert <http://demo.qooxdoo.org:8181/current/apiviewer/#qx.core.MAssert>`_ are used to check the incoming parameters.
 
 .. _pages/interfaces#statics:
 
 Statics
-^^^^^^^
+-------
 
 Statics behave exactly like statics defined in mixins and qooxdoo classes. They are accessible through their fully-qualified name. For example, the static varaiable ``PI`` could be used like this:
 
@@ -89,7 +80,7 @@
 .. _pages/interfaces#events:
 
 Events
-^^^^^^
+------
 
 Each event defined in the interface must be declared in the implementing classes. The syntax matches the ``events`` key of the class declaration.
 

Modified: trunk/qooxdoo/documentation/manual/source/pages/core/property_features.rst
===================================================================
--- trunk/qooxdoo/documentation/manual/source/pages/core/property_features.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/core/property_features.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -75,11 +75,11 @@
 ================
 
 Automatic memory management. This means all so-configured properties which contain complex data objects get automatically disposed with the object disposal. The affected built-in types are already auto-configured this way. Also all properties which need an instance of a class, defined by using a classname as ``check`` are automatically handled. 
+
 .. note::
 
     Note that this does not actually call dispose() on the object but just removes the property value etc i.e. dereferences the object. You still need to call dispose() if necessary.
 
-xxx
 
 For all other properties which contain complex data the developer must add a ``dispose`` key with a value of ``true`` to the property declaration. For example if there is no ``check`` defined or the ``check`` definition points to a function.
 
@@ -87,5 +87,3 @@
 
     This is not needed for primitive types like strings and numbers.
 
-xxx
-

Modified: trunk/qooxdoo/documentation/manual/source/pages/development/development_tools.rst
===================================================================
--- trunk/qooxdoo/documentation/manual/source/pages/development/development_tools.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/development/development_tools.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -5,29 +5,27 @@
 
 Editing or IDE support for JavaScript or qooxdoo is still quite limited. If you happen to know some practical solutions, please feel free to add them below.
 
-XXX
-===
-
 .. _pages/development_tools#eclipse:
 
 Eclipse
--------
+=======
 
-Since Eclipse 3.4 an advanced editing support for regular JavaScript is available (called `JSDT <http://wiki.eclipse.org/JSDT>`_). On top of this *native* JS support, the project ` <http://qooxdoo.org/contrib/project/qxdt>`_ aimed at providing qooxdoo-*specific* support. This project stalled, mostly due to technical difficulties at that early time of JSDT. The extensibility of JSDT is still a very interesting concept, so if you like to review the QXDT source code and start porting it to recent versions of Eclipse, please see the ` <http://qooxdoo.org/contrib/project/qxdt>`_ documentation.
+Since Eclipse 3.4 an advanced editing support for regular JavaScript is available (called `JSDT <http://wiki.eclipse.org/JSDT>`_). On top of this *native* JS support, the `QXDT project <http://qooxdoo.org/contrib/project/qxdt>`_ aims to provide qooxdoo-*specific* support. This project stalled, mostly due to technical difficulties at that early time of JSDT. The extensibility of JSDT is still a very interesting concept, so if you like to review the QXDT source code and start porting it to recent versions of Eclipse, please see the `documentation <http://qooxdoo.org/contrib/project/qxdt>`_.
 
 .. _pages/development_tools#spket_ide:
 
 Spket IDE
----------
+=========
 
 `Spket IDE <http://spket.com>`_ is a powerful toolkit for JavaScript development. Its editor provides features like code completion, syntax highlighting and content outline that helps developers productively create efficient code. It comes with specific `support for qooxdoo <http://www.spket.com/qooxdoo.html>`_.
 
-*Please note: there is a hotfix available for people working with the qooxdoo SVN checkout instead of the qooxdoo SDK. See the* `download link <http://forums.spket.com/viewtopic.php?p=1330#1330>`__ *in the Spket forum. Thanks, Eric!*
+.. note::
+  There is a hotfix available for people working with the qooxdoo SVN checkout instead of the qooxdoo SDK. See the `download link <http://forums.spket.com/viewtopic.php?p=1330#1330>`_ in the Spket forum. Thanks, Eric!
 
 .. _pages/development_tools#aptana_ide:
 
 Aptana IDE
-----------
+==========
 
 The `Aptana IDE <http://www.aptana.com>`_ is a free, open-source, cross-platform, JavaScript-focused development environment for building Ajax applications. It features code assist on JavaScript, HTML, and CSS languages, FTP/SFTP support and a JavaScript debugger to troubleshoot your code. It is available for Windows, Mac OS, Linux and also as an Eclipse plugin.
 
@@ -36,7 +34,7 @@
 .. _pages/development_tools#jseclipse:
 
 JSEclipse
----------
+=========
 
 JSEclipse is a plugin for the Eclipse environment that helps developers code JavaScript faster and with no errors. With JSEclipse, you can complete a variety of tasks, from editing small sections of code to working with the next big AJAX library like qooxdoo ;-) or developing plug-ins for a product that embeds JavaScript snippets.
 
@@ -53,14 +51,14 @@
 .. _pages/development_tools#textmate:
 
 TextMate
---------
+========
 
 There is up-to-date qooxdoo support for TextMate. Please see the `blog post <http://news.qooxdoo.org/textmate-qooxdoo-bundle>`__ and the `project info <http://qooxdoo.org/contrib/project/textmate>`_ for this excellent qooxdoo bundle. 
 
 .. _pages/development_tools#emacs:
 
 Emacs
------
+=====
 
 `js2-mode <http://code.google.com/p/js2-mode/>`_ offers improved JavaScript support in Emacs. While it doesn't include qooxdoo-specific support, it eventually aims to be competitive with other best-of-class JavaScript editors. Also see the original `blog post <http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascript-mode-for-emacs.html>`__.
 

Modified: trunk/qooxdoo/documentation/manual/source/pages/gui_toolkit/ui_develop.rst
===================================================================
--- trunk/qooxdoo/documentation/manual/source/pages/gui_toolkit/ui_develop.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/gui_toolkit/ui_develop.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -123,7 +123,7 @@
 * For the HTML elements use: ``_onContentXXX`` or ``_onContainerXXX``
 * For the child controls use: ``_onIconXXX`` or ``_onFieldXXX`` etc.
 
-While ``XXX`` stands the name of the event or of the change happens. This will result into names like ``_onIframeLoad`` or ``_onContentInput``.
+Where ``XXX`` stands for the name of the event or of the change that happens. This will result in names like ``_onIframeLoad`` or ``_onContentInput``.
 
 .. _pages/gui_toolkit/ui_develop#anonymous_widgets:
 

Modified: trunk/qooxdoo/documentation/manual/source/pages/tool/generator_config_articles.rst
===================================================================
--- trunk/qooxdoo/documentation/manual/source/pages/tool/generator_config_articles.rst	2010-07-29 12:33:17 UTC (rev 22856)
+++ trunk/qooxdoo/documentation/manual/source/pages/tool/generator_config_articles.rst	2010-07-29 13:06:38 UTC (rev 22857)
@@ -31,7 +31,6 @@
 
     Since each config key, particularly action keys, interpret their corresponding config entries, they know which entries represent paths. To handle those paths correctly, the ``Config`` module provides a utility method ``Config.absPath(self, path)`` which will calculate the absolute path from the given path relative to the config file's location.
 
-xxx
 
 .. _pages/tool/generator_config_articles#file_globs:
 
@@ -48,16 +47,10 @@
  []                 matches any of the enclosed characters; character ranges are possible using a hyphen, e.g. [a-z] (regexp: <same>)  
 =================  ==================================================================================================================
 
-XXX
----
-
-XXX
-^^^
-
 .. _pages/tool/generator_config_articles#examples:
 
 Examples
-""""""""
+--------
 
 Given a set of files like ``file9.js,  file10.js,  file11.js``, here are some file globs and their resolution:
 
@@ -149,13 +142,12 @@
 A special situation arises if you are using a **top-level let**, i.e. a *let* section on the highest level in the config file, and not in any job definition. This *let* map will be automatically applied to every job run, without any explicit reference (so be aware of undesired side effects of bindings herein). 
 
 When assembling a job to run, the precedence of all the various *let* maps is 
-.. note::
 
-    local job let < config-level let < 'extend' job let's
+::
 
-xxx
+    local job let < config-level let < 'extend' job lets
 
- With imported jobs top-level definitions will take precedence over any definitions from the external config file (as if they were the 'first' let section in the chain).
+With imported jobs top-level definitions will take precedence over any definitions from the external config file (as if they were the 'first' let section in the chain).
 
 .. _pages/tool/generator_config_articles#log_key:
 
@@ -333,8 +325,6 @@
 
     All URI handling within qooxdoo is related to libraries.
 
-xxx
-
 Within qooxdoo the :ref:`library <pages/tool/generator_config_articles#library_key_and_manifest_files>` is a fundamental concept, and libraries in this sense contain all the things you are able to include in the final Web application, such as
 class files (.js),
 graphics (.gif, .png, ...),


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


