You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by bl...@apache.org on 2001/10/30 14:55:00 UTC
cvs commit: jakarta-avalon/src/documentation/xdocs/developing decomposing.xml introduction.xml
bloritsch 01/10/30 05:55:00
Modified: src/documentation/xdocs/developing decomposing.xml
introduction.xml
Log:
make clarifications
Revision Changes Path
1.3 +7 -7 jakarta-avalon/src/documentation/xdocs/developing/decomposing.xml
Index: decomposing.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon/src/documentation/xdocs/developing/decomposing.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- decomposing.xml 2001/10/30 13:49:24 1.2
+++ decomposing.xml 2001/10/30 13:55:00 1.3
@@ -21,7 +21,7 @@
how to identify services and Components. After we define some
services that are used in the system, we will take one of those
services and define the different components needed by the
- service. My goal is to pass on some principles that will help
+ service. My goal is to pass on some concepts that will help
you define your system in manageable pieces.
</para>
<section>
@@ -29,8 +29,8 @@
<para>
While it is beyond the scope of this presentation to provide
a full-blown methodology, I do want to provide some pointers.
- We will start with the implementation oriented of Components
- and Services, and then provide a practical definition.
+ We will start with the implementation oriented definition of
+ Components and Services, and then provide a practical definition.
</para>
<blockquote>
<title>Component</title>
@@ -351,7 +351,7 @@
specific to the Document Repository Service that it could not be used
again for a completely different service. While there are ways of
managing the complexity, and ways of making it flexible-sometimes the
- extra work is not worth it. You have to way your decisions in such
+ extra work is not worth it. You have to weigh your decisions in such
cases carefully. If the logic performed in a potential Component is
going to be applied consistently then it might make sense to keep it a
Component. There is room to have multiple instances of a Component in
@@ -367,7 +367,7 @@
<title>Decomposing the Document Repository Service</title>
<para>
We will list the Components that we are going to implement with a
- description of their roles, the rational, and their origination (if
+ description of their roles, the rationale, and their origination (if
the component already exists).
</para>
<section>
@@ -402,7 +402,7 @@
The Cache is a short-term memory-based storage facility. The
DocumentRepository will use it to store Document objects referenced
by a hash algorithm. In order to promote the reusability of the
- Cache Component, the stored object must only implement a Cacheable
+ Cache Component, the stored object must implement a Cacheable
interface.
</para>
</section>
@@ -423,7 +423,7 @@
The examples describe all the Components that will be in the Document
Repository Service, with a brief summary of what they will do. A quick
glance through the list supports the approach of only implementing
- facilities as Components-not data. At this point, you should be able
+ facilities as Components—not data. At this point, you should be able
to determine what components your services need to operate.
</para>
</section>
1.8 +2 -2 jakarta-avalon/src/documentation/xdocs/developing/introduction.xml
Index: introduction.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon/src/documentation/xdocs/developing/introduction.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- introduction.xml 2001/10/30 13:48:47 1.7
+++ introduction.xml 2001/10/30 13:55:00 1.8
@@ -254,7 +254,7 @@
concern areas resulted in the Separation of Concerns (SOC) pattern
<footnote>
<para>
- <ulink href="http://www.research.ibm.com/hyperspace/MDSOC.htm">
+ <ulink uri="http://www.research.ibm.com/hyperspace/MDSOC.htm">
http://www.research.ibm.com/hyperspace/MDSOC.htm
</ulink>
</para>
@@ -271,7 +271,7 @@
Programming (AOP)
<footnote>
<para>
- <ulink href="http://www.aspectj.org">http://www.aspectj.org</ulink>
+ <ulink uri="http://www.aspectj.org">http://www.aspectj.org</ulink>
</para>
</footnote>. Researchers discovered that many concerns
couldn't be addressed at class or even method granularity. Those
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>