sws 0.4

data/doc/DOC.otl

@@ -0,0 +1,34 @@
+Introduction
+	What is SWS
+		Short desciption
+		General concepts & advantages
+	License
+Installation
+	Where to get
+	Installation instructions
+	Upgrading from earlier versions
+		What's new
+Concepts
+	Architecture
+		Picture?
+	Application
+		Configuration file
+	Adaptors
+	Request handlers
+	Session
+	Resources
+	Frameworks
+		Configuration file
+	Components
+		Basics
+		Files
+		Slots
+		Content
+		Functionality
+Tutorial
+	: Need a simple example application (without db)
+	Creating application
+	Creating first component
+	Navigation
+Bugs & limitations
+Future versions

data/doc/Makefile

@@ -0,0 +1,13 @@
+all: rdoc docbook-html docbook-txt docbook-pdf
+
+rdoc: ../lib/sws/*rb
+	rdoc18 -o rdoc -T kilmer ../lib/sws.rb ../lib/sws/*rb ../lib/sws/Core/components/*/*rb
+
+docbook-html: docbook/*docbook
+	docbook2html -o html docbook/sws_manual.docbook
+
+docbook-txt: docbook/*docbook
+	docbook2txt -o txt docbook/sws_manual.docbook
+
+docbook-pdf: docbook/*docbook
+	docbook2pdf -o pdf docbook/sws_manual.docbook

data/doc/docbook/concepts.docbook

@@ -0,0 +1,474 @@
+<chapter id="concepts">
+	<title>Concepts</title>
+
+	<sect1 id="concepts-architecture">
+		<title>SWS Application architecture</title>
+
+		<para>SWS Application architecture is presented on the figure 3-1. 
+			Application receives HTTP request from client (usually a WWW browser).
+			The part of the program responsible for reading the HTTP request and transforming it into <ulink url="../rdoc/classes/SWS/Request.html">SWS::Request</ulink> objects is called the <link linkend="concepts-adaptor">adaptor</link>. 
+			The request is then passed by application to proper <link linkend="concepts-handlers">request handler</link>, which either creates a <link linkend="concepts-component">Component</link> instance used to generate <ulink url="../rdoc/classes/SWS/Response.html">SWS::Response</ulink> object or generates the Response object itself. 
+			Component collaborates with <ulink url="../rdoc/classes/SWS/TemplateParser.html">TemplateParser</ulink> and <ulink url="../rdoc/classes/SWS/DefinitionParser.html">DefinitionParser</ulink> objects, which retrieve component information from .html, .sws and .api files. 
+			Generated SWS::Response object is returned back to adaptor, which in turn sends HTTP response to the client.
+			
+		<figure><title>SWS Application architecture</title>
+			<graphic fileref="architecture.png" format="PNG">
+		</figure>
+		
+		</para>
+	</sect1>
+
+	<sect1 id="concepts-application">
+		<title>Application object</title>
+
+		<sect2 id="concepts-application-overview">
+			<title>Application overview</title>
+			<para>Each SWS application is build around an <ulink url="../rdoc/classes/SWS/Application.html">Application</ulink> object, which can be retrieved using <ulink url="../rdoc/classes/SWS/Application.html#M000083.html">SWS::Application.instance()</ulink> method. The Application object provides a WWW server and fundamental <link linkend="concepts-handlers">request handling</link> functionality. It can also contain some global (independent of particular request) variables. You should create your subclass of SWS::Application, create an instance of it and use <ulink url="../rdoc/classes/SWS/Application.html#M000084.html">run</ulink> method to start the application.</para>
+		</sect2>
+
+		<sect2 id="concepts-application-config">
+			<title>Application config file</title>
+
+			<para>Each SWS application must contain a config file named <replaceable>application.yaml</replaceable>. The file is a regular <ulink url="http://yaml4r.sourceforge.net/">YAML</ulink> file containing a single Hash with following elements:
+			</para>
+
+			<variablelist>
+				<title>Application config file elements</title>
+				
+				<varlistentry><term>components</term>
+					<listitem><para>
+							A Hash of <wordasword>component name</wordasword> => <wordasword>component directory</wordasword> (relative to application directory) pairs.
+					</para></listitem>
+				</varlistentry>
+				
+				<varlistentry><term>frameworks</term>
+					<listitem><para>
+							A Hash of <wordasword>framework name</wordasword> => <wordasword>framework directory</wordasword> (relative to application directory) pairs. Note the <wordasword>SYSTEM</wordasword> word is replaced with default (system) locations - currently the same as the <wordasword>$LOAD_PATH</wordasword> value.
+					</para></listitem>
+				</varlistentry>
+				
+				<varlistentry><term>resources</term>
+					<listitem><para>
+							A Hash of <wordasword>resources name</wordasword> => Hash containing resource parameters (currently containing resource filename - relative to framework directory - and mime type) pairs.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>adaptor_class</term>
+					<listitem><para>
+							The name of <link linkend="concepts-adaptor">adaptor</link> class to use. Defaults to <ulink url="../rdoc/classes/SWS/Adaptor/Standalone.html">SWS::Adaptor::Standalone</ulink>.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>session_class</term>
+					<listitem><para>
+							The name of <link linkend="concepts-session">session</link> class to use. Defaults to <ulink url="../rdoc/classes/SWS/Session.html">SWS::Session</ulink>.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>default_direct_action_class</term>
+					<listitem><para>
+							The name of default DirectAction class. Defaults to <ulink url="../rdoc/classes/SWS/DirectAction.html">SWS::DirectAction</ulink>.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>default_component_class</term>
+					<listitem><para>
+							The name of the component class used for new sessions (and invalid request URLs). Defaults to <replaceable>Main</replaceable>.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>default_encoding</term>
+					<listitem><para>
+							Default encoding for components. Defaults to <replaceable>"iso-8859-1"</replaceable>.
+					</para></listitem>
+				</varlistentry>
+				
+				<varlistentry><term>exception_component_class</term>
+					<listitem><para>
+							Component class to be used to create exception pages. Defaults to <ulink url="../rdoc/classes/SWS/ExceptionPage.html">SWS::ExceptionPage</ulink>.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>max_sessions</term>
+					<listitem><para>
+							Maximum number of sessions to be tracked. When this number is exceeded, the following sessions will be refused or the Last Recently Used session will be deleted (depending on the <wordasword>refuse_sessions</wordasword> parameter). Defaults to 100.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>refuse_sessions</term>
+					<listitem><para>
+							Policy for handling incoming sessions when the limit has been reached. If <token>true</token>, new session will be refused; if <token>false</token>, Last Recently Used session will be deleted and new session will be handled regularly. Defaults to <token>false</token>.
+					</para></listitem>
+				</varlistentry>
+
+			</variablelist>
+
+			<para>
+				All elements of the config file are optional (as they all have default values), but the config file must exist and be a valid YAML file. Besides, there is not much sense in creating an application with empty config file - usually you may at least want to define components and load Core frameowork.
+			</para>
+
+			<example>
+				<title>Application config file example</title>
+				<programlisting>
+<![CDATA[components:
+  UserBrowse: UserBrowse
+  MovieBrowse: MovieBrowse
+  Menu: Menu
+frameworks:
+  Core: SYSTEM/sws/Core
+	TestFramework: frameworks/TestFramework
+resources:
+	first_image:
+		filename: images/image1.jpg
+		mime-type: image/jpg
+	css_file:
+		filename: style.css
+		mime-type: text/css
+adaptor_class: SWS::Adaptor::Standalone
+session_class: Session
+default_direct_action_class: MyDirectAction
+default_component_class: MovieBrowse
+default_encoding: iso-8859-2
+exception_component_class: MyExceptionPage
+max_sessions: 50
+refuse_sessions: true
+					]]>
+				</programlisting>
+			</example>
+		</sect2>
+		
+	</sect1>
+
+	<sect1 id="concepts-adaptor">
+		<title>Adaptor</title>
+
+		<para>The <ulink url="../rdoc/classes/SWS/Adaptor.html">adaptor</ulink> is a part of the application collaborating directly with the client. Currently there are 3 adaptor classes, allowing application to run in 3 different modes: <ulink url="../rdoc/classes/SWS/Adaptor/FastCGI.html">as FastCGI script</ulink>, <ulink url="../rdoc/classes/SWS/Adaptor/CGI.html">as CGI script</ulink> and <ulink url="../rdoc/classes/SWS/Adaptor/Standalone.html">standalone</ulink>. More adaptors are likely to be implemented, but the whole adaptor logic may be the subject to change in future releases.</para>
+
+		<para>The purpose of the adaptor is to abstract a concept of request and response. 
+			Adaptor object reads the HTTP response from the source (eg. directly from the socket - Standalone adaptor, from FastCGI request - FastCGI adaptor) and creates <ulink url="../rdoc/classes/SWS/Request.html">SWS::Request</ulink> object, which is than processes by proper <link linkend="concepts-handlers">request handler</link>. 
+			At the end of the request-response loop, a <ulink url="../rdoc/classes/SWS/Response.html">SWS::Response</ulink> object is transformed by the adaptor into a HTTP response, which is sent to the client. 
+			This way the rest of the application does not even know how the application was accessed - in fact you can for example change the adaptor (in <replaceable>application.yaml</replaceable> file) from Standalone to FastCGI and the application will still run without any problems (provided you set the WWW server up correctly, of course :)).
+		</para>
+
+		<para>To change the port of Standalone adaptor, use <wordasword>application.adaptor.port = new_port</wordasword> just before <wordasword>application.run()</wordasword>.
+		</para>
+	</sect1>
+	
+	<sect1 id="concepts-loop">
+		<title>Request-response loop</title>
+
+		<para>SWS application is a standalone WWW server. When a HTTP request is received, it is parsed and a <ulink url="../rdoc/classes/SWS/Request.html">SWS::Request</ulink> object is created. Also the <ulink url="../rdoc/classes/SWS/Session.html">Session</ulink> object is retrieved (using session id - currently stored in cookie) - if cannot be retrieved, new Session object will be created.</para>
+
+		<para>Then the URL is parsed - it should consist of application base path, request handler key and some parameter(s) for the handler. The request handler is then called - it should return response object and <link linkend="concepts-component">component</link> that will handle next request in this session.</para>
+
+	</sect1>
+
+
+	<sect1 id="concepts-handlers">
+		<title>Request handlers</title>
+
+		<para>When the application receives a request, proper request handler is chosen according to the key present in request URL (first element after application base path). Each request handler key has a handler method associated in @request_handlers Hash within the application object. Such an architecture allows developer to define his own request handlers and their keys. Following request handlers has been predefined:</para>
+		
+		<itemizedlist>
+			<listitem><para>Component request handler - handler key is "cp", example URL: <replaceable>http://domain.com/application/cp/24324343/2423433</replaceable>. Represents request for a particular component (first numeric part of an URL is a hash value for requested component object). This component will call selected method (last part of an URL represents the hash value of the Method object) and create response for request.</para></listitem>
+			<listitem><para>PageName request handler - handler key is "pn", example URL: <replaceable>http://domain.com/application/pn/343243433/pageName</replaceable>. Represents request for a particular component class. The middle part of an URL (a numeric one) represents the hash value of the component that served last request - it is necessary to avoid crafting an URL to retrieve page by name from outside the application. New instance of the requested component class will be created and this instance will create a response for the request.</para></listitem>
+			<listitem><para>DirectAction request handler - handler key is "da", example URL: <replaceable>http://domain.com/application/da/login</replaceable>. This kind of request handler is used to call arbitrary methods from special DirectAction class - the example above would call <replaceable>login_action</replaceable> method from defined DirectAction class. Can be used to define additional access points to the application.</para></listitem>
+			<listitem><para>Resource request handler - handler key "res", example URL: <replaceable>http://domain.com/application/res/app/image.jpg</replaceable> (the "app" element defines a <link linkend="concepts-framework">framework</link> to find the given resource in). This request handler is used to retrieve a <wordasword>resource</wordasword>, such as an image or css file.</para></listitem>
+		</itemizedlist>	
+			
+		<para>Note that you don't have to create any request handler keys or URLs or anything like this by hand - it is all handled by SWS. This section was only meant to give overall view of the request handlers concepts.</para>
+	</sect1>
+
+
+	<sect1 id="concepts-session">
+		<title>Session support</title>
+
+		<para>Session handling in SWS is much more powerful than in most web development libraries. Instead of a key, which has to be retrieved from cookie and can be used to get a hash of session attributes a regular object is created - its class can be set in <replaceable>application.yaml</replaceable> file (it defaults to <ulink url="../rdoc/classes/SWS/Session.html">SWS::Session</ulink>). This mechanism allows you to easily add custom methods and attributes (such as authetication information) to the Session object.</para>
+
+		<para>Currently session is passed in a cookie, but there are plans to allow keeping it in the URL.</para>
+
+	</sect1>
+
+	<sect1 id="concepts-resources">
+		<title>Resources</title>
+
+		<para>Besides the components and other "dynamic content generators" the application can contain also static content, like image files, CSS stylesheets, HTML files etc. These files are defined in config file and can be served to the client by <wordasword>resource request handler</wordasword>.</para>
+	</sect1>
+	
+	<sect1 id="concepts-framework">
+		<title>Frameworks</title>
+
+		<sect2 id="concepts-framework-overview">
+			<title>Framework overview</title>
+			<para>Framework is a kind of library, but besides .rb files it may contain components and resources. Thus frameworks are reusable parts used in multiple applications. Default SWS components are also kept in a <token>Core</token> framework, which you should include in all applications.</para>
+		</sect2>
+
+		<sect2 id="concepts-framework-config">
+			<title>Framework config file</title>
+
+			<para>As an application, a framework must contain a config file (this time named <replaceable>framework.yaml</replaceable>. The file is of course in <ulink url="http://yaml4r.sourceforge.net/">YAML</ulink>format and contains a Hash with following keys:</para>
+						
+			<variablelist>
+				<title>Framework config file elements</title>
+				
+				<varlistentry><term>components</term>
+					<listitem><para>
+							A Hash of <wordasword>component name</wordasword> => <wordasword>component directory</wordasword> (relative to framework directory) pairs.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>resources</term>
+					<listitem><para>
+							A Hash of <wordasword>resources name</wordasword> => Hash containing resource parameters (currently containing resource filename - relative to framework directory - and mime type) pairs.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>load_paths</term>
+					<listitem><para>
+							An Array of paths to be added to the application <symbol>$LOAD_PATH</symbol>. Note the files in these additional paths are not loaded automatically.
+					</para></listitem>
+				</varlistentry>
+
+			</variablelist>
+
+			<para>
+				All elements of the framework config file are optional, but the file must exist (and be a valid YAML file!). However, there is no point in creating such an empty framework.
+			</para>
+			
+			<example>
+				<title>Framework config file example</title>
+				<programlisting>
+<![CDATA[components:
+  UserBrowse: UserBrowse
+  MovieBrowse: MovieBrowse
+  Menu: Menu
+resources:
+  first_image:
+    filename: images/image1.jpg
+    mime-type: image/jpg
+  css_file:
+    filename: style.css
+    mime-type: text/css
+load_paths:
+  some/relative/path
+  /another/absolute/path
+					]]>
+				</programlisting>
+			</example>
+		</sect2>
+		
+	</sect1>
+			
+	<sect1 id="concepts-component">
+		<title>Components</title>
+
+		<sect2 id="concepts-component-basics">
+			<title>Component basics</title>
+			
+			<para>A Component is a building block of each SWS application. The simplest definition of component would be "the element of the page responsible for rendering a part of its content". Each page as a whole is a component too. The components are reusable, so if you create one you can use it in other applications. Reusable components are usually bundled in <link linkend="concepts-framework">frameworks</link>.</para>
+
+			<para>
+				A component is basically a Ruby class (derived from <ulink url="../rdoc/classes/SWS/Component.html">SWS::Component</ulink>), containing initialization and logic for the component. It may also contain additional files, like HTML template or slot definitions (explained in later sections).
+			</para>
+			
+		</sect2>
+
+		
+		<sect2 id="concepts-component-slots">
+			<title>Slots</title>
+
+			<para>Each component can be made configurable by defining a number of <wordasword>slots</wordasword>. A slot is simply a component parameter, that can have the value assigned by its parent component (that is, the component that contains the component in question) by binding an attribute of parent components' Ruby class to it. The type of the value bound to slot depends on the slot itself - eg. to a <replaceable>value</replaceable> slot of <ulink url="../rdoc/classes/SWS/TextField.html">SWS::TextField</ulink> component you should bind a String, but to a <replaceable>action</replaceable> slot of <ulink url="../rdoc/classes/SWS/SubmitButton.html">SubmitButton</ulink> component you should bind a Method (which will be called when the page is submitted).
+			</para>
+
+			<para>As of SWS 0.3, also class (and module) methods can be used for slot bindings.</para>
+
+			<para>As of SWS 0.4, you can bind parent bindings to a slot by preceding parent binding name with <replaceable>^</replaceable>. This construction causes the value of the parent slot of given name to be bound to the slot in current component.</para>
+			
+			<para>
+				A slot definition (defined in .api file of the component) may contain following attributes:
+			</para>
+
+			<variablelist>
+				<title>Slot definition parameters</title>
+
+				<varlistentry><term>required</term>
+					<listitem><para>
+							If set to <token>true</token>, the application will raise an exception if the instance of the component is created with empty value for this slot.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>settable</term>
+					<listitem><para>
+							If set to <token>true</token>, the value from the slot will be propagated to the parent when the page is submitted. For example - if you bind <replaceable>username</replaceable> instance variable of the page Ruby class to a <ulink url="../rdoc/classes/SWS/TextField.html">textfield component</ulink>, the instance variable will be set to the text the user entered into the textfield. Yes, I mean that - you do not need to parse ANY HTML parameters - they will automatically be assigned to Ruby variables of your choice!.
+					</para></listitem>
+				</varlistentry>
+
+				<varlistentry><term>default</term>
+					<listitem><para>
+							If set and the slot is not bound, the slot value will be set to this default value.
+					</para></listitem>
+				</varlistentry>
+				
+			</variablelist>
+		</sect2>
+
+		<sect2 id="concepts-component-content">
+			<title>Containers and content</title>
+
+			<para>
+				As you can see at the example HTML template file, a component may enclose some HTML (some of which may be components themselves) - in the example the <replaceable>some_form</replaceable> component encloses <replaceable>text_field</replaceable> and <replaceable>submit_button</replaceable> components. 
+				For the content to be included in response, the component class must be declared as container (the <ulink url="../rdoc/classes/SWS/Component.html#M000133">container?</ulink> method must return <token>true</token>, which is the default). 
+				The content will be inserted in place where its container HTML template has a <ulink url="../rdoc/classes/SWS/Content.html">SWS::Content</ulink> component. 
+				This is a special component class meant only for to mark a place where the content should be inserted. In fact, you can mark the place with any component with <ulink url="../rdoc/classes/SWS/Component.html#M000134">content?</ulink> method returning <token>true</token>, but SWS::Content is the only standard component fulfilling this condition.
+			</para>
+
+			<para>
+				For non-container components (such as <ulink url="../rdoc/classes/SWS/String.html">SWS::String</ulink>) the content will be completely ignored. Also note the content can be only inserted once - if you use multiple SWS::Content components in a HTML template, this may lead to unexpected behavior! 
+			</para>
+		</sect2>
+		
+		<sect2 id="concepts-component-files">
+			<title>Component files</title>
+			<para>Each component may consist of up to 4 files, out of which only the Ruby code file is required:</para>
+
+			<itemizedlist>
+				<listitem>
+					<para>
+						A .html	file contains a HTML template of the component. It may contains embedded components, represented by a HTML tag with "sws" attribute (the value of the attribute being a name of the embedded component used in .sws file). You may use virtually any HTML tag for any embedded component, as the component ignores the tag name completely. However, a common practice is to represent "visual" components (eg. <ulink url="../rdoc/classes/SWS/TextField.html">SWS::TextField</ulink>) by the same tag the component renders and "nonvisual" or complex components by a <token>span</token> or <token>div</token> tag. 
+					</para>
+					<para>
+						As of version 0.2 of SWS you no longer need to close standalone tags with ugly <![CDATA[/>]]>. However, the file should be a valid HTML markup, otherwise the <ulink url="../rdoc/classes/SWS/TemplateParser.html">template parser</ulink> may not be able to parse it.
+					</para>
+					<para>
+						Example below represents a page with 4 embedded components.
+					</para>
+					<example>
+						<title>Sample HTML template</title>
+						<programlisting>
+<![CDATA[<html>
+	<body>
+		<span sws="some_string"></span>
+		<form sws="some_form">
+			<input type="text" sws="text_field"><br>
+			<input type="submit" sws="submit_button">
+		</form>
+	</body>
+</html>]]>
+						</programlisting>
+					</example>
+
+					<para>As of SWS 0.3, all custom HTML tag attributes will be added (of course only for components representing HTML tags).
+					</para>
+
+				</listitem>
+
+				<listitem>
+					<para>
+						A .rb file is a most obvious one from all component files. It contains a Ruby class defining the component - the class derives from <ulink url="../rdoc/classes/SWS/Component.html">SWS::Component</ulink> and may contain methods and attributes to be bound in .sws file.
+					</para>
+					
+					<example>
+						<title>Ruby class file for an example component</title>
+						<programlisting>
+<![CDATA[class SampleComponent < SWS::Component
+
+	attr_accessor :some_attribute
+	attr_reader :string_to_display
+		
+	def form_submitted
+		puts "Value in the textfield: #{@some_attribute}"
+		@some_attribute = "Enter something"
+		@string_to_display = "Form submitted!"
+		return self
+	end
+
+end]]>
+						</programlisting>
+					</example>					
+				</listitem>
+
+				<listitem>
+					<para>
+						A .api file contains slot definitions for the component. The file uses YAML format and defines component slots as described <link linkend="concepts-component-slots">above</link>.
+					</para>
+
+					<para>
+						Please note that defining slots does not make sense for top-level (page) components. So the example slots below are only... examples :)
+					</para>
+
+					<example>
+						<title>Sample slot definition file for the component</title>
+
+						<programlisting>
+<![CDATA[
+slot1:
+  required: true
+  settable: true
+ 
+slot2:
+  default: "'Some value'"
+
+slot3:
+]]>
+						</programlisting>
+					</example>			
+				</listitem>
+
+				<listitem>
+					<para>
+						A .sws file contains bindings for the children components - the components placed on the HTML template of the component in question. It uses YAML format and contains children components names and their slots with values bound to them (if any). The values bound to the slots must be accessible from within component instance, so they are usually instance_variables or methods of this instance.
+						Note the special <symbol>_class</symbol> "slot" - this is not a slot, but a special internal key defining the class of the child component. 
+						Also note that while the <replaceable>text_field</replaceable> and <replaceable>some_string</replaceable> components have String variables bound to their slots, <replaceable>submit_button</replaceable> component has a Method bound to its <token>action</token> slot - this method will be called when the page is submitted. The method returns <token>self</token>, so the same component will handle next request in this session - it could return another component, which would take over the next request.
+					</para>
+					
+					<example>
+						<title>Sample slot binding file for the component</title>
+
+						<programlisting>
+<![CDATA[
+some_form:
+  _class: SWS::Form
+
+some_string:
+  _class: SWS::String
+  value: string_to_display
+
+text_field:
+  _class: SWS::TextField
+  value: some_attribute
+ 
+submit_button:
+  _class: SWS::SubmitButton
+  value: "'Click here'"
+  action: form_submitted
+]]>
+						</programlisting>
+					</example>			
+							
+				</listitem>
+
+			</itemizedlist>
+			
+		</sect2>
+
+		<sect2 id="concepts-component-works">
+			<title>How does it work?</title>
+
+			<para>
+				The common question that appears at this point is: "How do all these files work together?". Here's a simple explanation: When this component will be used as a page, it creates a simple HTML document - <replaceable>some_form</replaceable> will be rendered as HTML form, <replaceable>some_string</replaceable> will be replaced with value of <replaceable>string_to_display</replaceable> instace variabl, <replaceable>text_button</replaceable> will be rendered as HTML form textfield (with value set to the value of <replaceable>some_attribute</replaceable>) and <replaceable>submit_button</replaceable> will become HTML submit button - if it will be clicked, the <function>form_submitted</function> method of the component will be called. 
+				But before calling the method the value of the <replaceable>some_attribute</replaceable> will be set to the value of the HTML field. So basically all the work developer usually had to do himself is now done by the library. You don't have to parse submitted HTML form values - instead just bind them to some attributes of the component and they'll be set! You don't have to check which button was clicked either - just bind some method to each button and SWS will call proper one.
+			</para>
+		</sect2>
+
+		<sect2 id="concepts-component-final">
+			<title>Final word</title>
+			
+			<para>
+				Although the whole component concept may seem unnecessary complicated at a first glance, it proves to be very useful and powerful. It breaks the traditional "HTML rendering" thinking of WWW apps, separates business logic from the presentation and allows for construction of WWW applications in object-oriented manner.
+			</para>
+		</sect2>
+			
+	</sect1>
+
+</chapter>
+