myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mmarinsc...@apache.org
Subject svn commit: r547142 - in /myfaces/orchestra/trunk/core/src/site/xdoc: component-bindings.xml faqs.xml
Date Thu, 14 Jun 2007 06:24:50 GMT
Author: mmarinschek
Date: Wed Jun 13 23:24:49 2007
New Revision: 547142

URL: http://svn.apache.org/viewvc?view=rev&rev=547142
Log:
more doc fixes

Modified:
    myfaces/orchestra/trunk/core/src/site/xdoc/component-bindings.xml
    myfaces/orchestra/trunk/core/src/site/xdoc/faqs.xml

Modified: myfaces/orchestra/trunk/core/src/site/xdoc/component-bindings.xml
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/xdoc/component-bindings.xml?view=diff&rev=547142&r1=547141&r2=547142
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/xdoc/component-bindings.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/xdoc/component-bindings.xml Wed Jun 13 23:24:49
2007
@@ -12,30 +12,31 @@
 				<subsubsection name="Basic discrepancy">
 				While the best pratice is to have a single page controller under conversation per page
or 
 				for a full multi page flow, there is a discrepancy between the scope length needed for
the conversation
-				and the scope length for associated component bindings.
-				</subsubsection>
+				and the scope length for associated component bindings. This discrepancy is not related
to Orchestra;
+                it is much more related to the JSF-specification itself.
+                </subsubsection>
 				
 			</subsection>
 			<subsection name="Problem">
-				The main problem is, component bindings in a backend bean require a scope lenth of request.
+				The main problem is that component bindings need to be in a request-scoped backing-bean.
 				The cause is that the component tree is regenerated at every request. Longer component
bindings
 				are a possible cause for internal id clashes etc...
 				<p> </p>
-				The main problems we now face are, we have a single page controller/model object which
is associated
-				to the view. The page controller/model now is stateful, which is exactly as inded, however
we need
+				Now with what we have advocated so far, we have a single page controller/model object
which is associated
+				with the view. The page controller/model now is stateful, which is exactly what we wanted,
however we need
 				component bindings in this bean and those are referenced by the view.
 				The bindings under normal circumstances inherit exactly the scope of the page controller.
 				<p> </p>
-				Therefore following construct automatically is bound to fail:
+				Therefore the following construct is bound to fail:
 				<pre>
 &lt;component binding="#{viewcontrollerbean.bindingattribute}" /&gt;					
 				</pre>
-				The problem here is that the viewcontroller bean has a scope of conversation, the bindingattribute,
however, needs
-				a scope of request.
-				This at the first look is a problem impossible to solve.
-				At the second look, Spring itself provides the solution. Since every bean referenced
by
-				the framework and the view layer is a Spring bean, we get the solution out of the magical
-				Spring box.
+				due to the difference in scopes.
+
+                At the first glance, this problem is impossible to solve.
+				With more thoughts, Spring itself provides the solution. Since every bean referenced
by
+				the framework and the view layer is a Spring bean, we get the solution out of the "magical
+				Spring toolset".
 			</subsection>				
 			<subsection name="Solution">
 				Spring in 2.0 has introduced a construct called aop-proxy. This is a special tag which
can be embedded
@@ -49,10 +50,10 @@
 				<pre>
 &lt;component binding="#{viewcontrollerbean.componentbindingmodel.bindingattribute}"
/&gt;					
 				</pre>
-				The accessor path has slightly changed, we have introduced a second bean a model
-				bean which holds our component bindings.
+				The accessor path has slightly changed, we have introduced a second bean; a model
+				bean which specifically holds our component bindings.
 				<p> </p>
-				What happens on the spring configuration side is simply following:
+				What happens on the spring configuration side is simply the following:
 				
 				<pre>
 &lt;bean id="componentbindingmodel" scope="request" class="path.to.our.model.class"&gt;
@@ -65,16 +66,16 @@
 
 &lt;/bean&gt;
 				</pre>	
-The associated component binding model class is simply a class which holds the components
as attributes and its associated setter
+The associated component binding model class is a class which only holds the components as
attributes and provides associated setter
 and getter methods.						
 		<p> </p>	
 		What happens at call stage: The viewcontrollerbean is instantiated under conversation scope,
the proxy
-		object is generated and assigned dependin on its lazy binding stage. 
+		object is generated and assigned depending on its lazy binding stage.
 		At the request end, the content of the componentbindingmodel bean is dropped and only the
empty proxy
-		shell still is referenced.
-		At the next request which references parts of the componentbindingmodel object the content
again is initialized
-		and can be accessed. This way it is possible to bind the request scoped component bindings
to any long running scope
-		no matter being it our conversation scopes or session scopes!		
+		shell is referenced.
+		At the next request - which references parts of the componentbindingmodel object - the
content is initialized again
+		and can be accessed. With this, it is possible to bind the request scoped component bindings
to any long running scope
+		no matter if they are custom conversation scopes or the session scope!		
 		</subsection>
 		</section>
 	</body>

Modified: myfaces/orchestra/trunk/core/src/site/xdoc/faqs.xml
URL: http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/site/xdoc/faqs.xml?view=diff&rev=547142&r1=547141&r2=547142
==============================================================================
--- myfaces/orchestra/trunk/core/src/site/xdoc/faqs.xml (original)
+++ myfaces/orchestra/trunk/core/src/site/xdoc/faqs.xml Wed Jun 13 23:24:49 2007
@@ -13,17 +13,16 @@
 
 				<p>
 					Depending on your environment and used JPA-implementation you might experience the problem
-					that there are database connections not have been passed back to the connection pool.<br
/>
+					that there are database connections which have not been passed back to the connection
pool.<br />
 					This can happen if you use entities with e.g. OneToMany mappings and lazy init AND accessing
the
 					OneToMany collection from your JSF view the first time.<br />
 					The EntityManager has to re-establish a connection to your database, but now that this
happens
 					outside of your conversation scoped bean, no one ends the transaction and so no one
puts the
 					connection back to the pool.<br />
-					The problem is, that with a growing number of users and a growing number of conversations
-					(especially not ended conversations - waiting for its timeout) your pool might exhaust.<br
/>
-					As I said, I don't know if this is the case with all JPA-implementations. But we had
at least
-					one environment where this happened. We admit, this was a very custom environment using
plain
-					hibernate, though, we thought the workaround might help others too ... sometimes. 
+					The problem is that with a growing number of users and a growing number of conversations
+					(especially not ended conversations - waiting for their timeout) your pool might exhaust.<br
/>
+					As said before, this might not be the case with all JPA-implementations. But we had
at least
+					one environment where this happened, so here the work-around.
 				</p>
 				<p>
 					To activate the workaround simply put the following code to your spring config and adjust
the
@@ -38,7 +37,7 @@
 &lt;/bean>
 					</pre>
 
-					The basic principle is, that we put a virtual DataSource between the JPA-implementation
and
+					The basic principle is to put a virtual DataSource between the JPA-implementation and
 					the read DataSource (which should be a connection pool for performance reasons).<br
/>
 
 					You have to configure
@@ -53,7 +52,7 @@
 
 					<br />
 
-					The property <code>listeners</code> is fully optional. It allows you to
configure a Listener
+					The property <code>listeners</code> is fully optional. It allows you to
configure a listener
 					which will be called on each borrow or release of a connection to do some database stuff,
e.g.
 					login/logout from a legacy database system, or to set the database client info, etc.
<br/>
 					Provide a class implementing the <code>org.apache.myfaces.orchestra.connectionManager.ConnectionManagerListener</code>



Mime
View raw message