Update of /cvsroot/xdoclet/xdoclet/xdocs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25616

Modified Files:
        valueobjects.xml 
Log Message:
More typos (XDT-1267).




Index: valueobjects.xml
===================================================================
RCS file: /cvsroot/xdoclet/xdoclet/xdocs/valueobjects.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -r1.12 -r1.13
*** valueobjects.xml    7 Oct 2004 23:49:46 -0000       1.12
--- valueobjects.xml    7 Feb 2005 23:33:23 -0000       1.13
***************
*** 70,74 ****
                  can see a XDoclet-tagged Entity Bean source code, with @tags 
related to
                  Value Object generation. Let's take a look at a bean marked 
up to
!                 generate Value Objects. <b>Please note that this is note a 
complete
                  example:</b> there are many tags missing, only the ones 
related to Value
                  Objects are presented here.
--- 70,74 ----
                  can see a XDoclet-tagged Entity Bean source code, with @tags 
related to
                  Value Object generation. Let's take a look at a bean marked 
up to
!                 generate Value Objects. <b>Please note that this is not a 
complete
                  example:</b> there are many tags missing, only the ones 
related to Value
                  Objects are presented here.
***************
*** 127,132 ****
       *   role-name="customer-prefers-products"
       */
!     public abstract Collection getPreferredProduts();
!     public abstract void setPreferredProducs(Collection products);
  
      /**
--- 127,132 ----
       *   role-name="customer-prefers-products"
       */
!     public abstract Collection getPreferredProducts();
!     public abstract void setPreferredProducts(Collection products);
  
      /**
***************
*** 189,193 ****
                  <p>
                      The first thing to do is to inform XDoclet which value 
objects it
!                     will generated for your bean. At class level, introduce 
the
                      <code>@ejb.value-object</code> tag and supply at least the
                      <code>name</code> and <code>match</code> parameter. The 
name
--- 189,193 ----
                  <p>
                      The first thing to do is to inform XDoclet which value 
objects it
!                     will generate for your bean. At class level, introduce the
                      <code>@ejb.value-object</code> tag and supply at least the
                      <code>name</code> and <code>match</code> parameter. The 
name
***************
*** 216,220 ****
                  <p>
                      Internally to XDoclet, a relation is tracked separately 
of either side of the
!                     relation using the name attribute of ejb.relation. If 
both sides of a
                      relation have an @ejb.relation tag with a matching name 
attribute (the &quot;name&quot;
                      attribute is the key that is used to uniquely identify 
the relationship),
--- 216,220 ----
                  <p>
                      Internally to XDoclet, a relation is tracked separately 
of either side of the
!                     relation using the name attribute of @ejb.relation. If 
both sides of a
                      relation have an @ejb.relation tag with a matching name 
attribute (the &quot;name&quot;
                      attribute is the key that is used to uniquely identify 
the relationship),
***************
*** 249,253 ****
                      the foreign key of the related entity. Whether or not 
there is reverse
                      visibility is irrelevant to XDoclet since it has all the 
information it needs
!                     about the relation in the ejb.relation tag.
                  </p>
              </subsection>
--- 249,253 ----
                      the foreign key of the related entity. Whether or not 
there is reverse
                      visibility is irrelevant to XDoclet since it has all the 
information it needs
!                     about the relation in the @ejb.relation tag.
                  </p>
              </subsection>
***************
*** 257,266 ****
                      properties. These are multi valued properties that map an 
EJB relationship.
                      In this example we've got both aggregate and compose 
properties,
!                     those being <code>preferredProduts</code> and 
<code>addresses</code>,
                      respectively.
                  </p>
                  <p>
                      Aggregation should be used when the related object is not 
directly
!                     dependant on the one we're declaring the value object.
                      <code>Product</code> has no direct dependency to 
<code>Customer</code>,
                      so the <code>preferredProducts</code> relationship is 
just an
--- 257,266 ----
                      properties. These are multi valued properties that map an 
EJB relationship.
                      In this example we've got both aggregate and compose 
properties,
!                     those being <code>preferredProducts</code> and 
<code>addresses</code>,
                      respectively.
                  </p>
                  <p>
                      Aggregation should be used when the related object is not 
directly
!                     dependent on the one we're declaring the value object.
                      <code>Product</code> has no direct dependency to 
<code>Customer</code>,
                      so the <code>preferredProducts</code> relationship is 
just an
***************
*** 272,276 ****
                      Composition should be used when the related object is 
directly
                      dependent on the one we're declaring the value object, 
and cannot
!                     exist without it. The creation of the related object is
                      responsibility of the entity we're coding. 
<code>Address</code> is
                      dependent on <code>Customer</code>, so the addresses 
relationship is
--- 272,276 ----
                      Composition should be used when the related object is 
directly
                      dependent on the one we're declaring the value object, 
and cannot
!                     exist without it. The creation of the related object is 
the
                      responsibility of the entity we're coding. 
<code>Address</code> is
                      dependent on <code>Customer</code>, so the addresses 
relationship is
***************
*** 282,286 ****
                  <p>
                      Aggregation and composition may be confusing at first. As 
a rule of
!                     thumb, considers object creation responsibility: if the 
entity we're
                      coding isn't responsible for creating the related entity, 
then it's
                      aggregation. If it is responsible for this, then it's 
composition. We
--- 282,286 ----
                  <p>
                      Aggregation and composition may be confusing at first. As 
a rule of
!                     thumb, consider object creation responsibility: if the 
entity we're
                      coding isn't responsible for creating the related entity, 
then it's
                      aggregation. If it is responsible for this, then it's 
composition. We
***************
*** 295,299 ****
                      parameter are <code>Collection</code> and 
<code>Set</code>, in
                      accordance with the EJB specification. In this example, 
both our
!                     multi valued properties uses <code>Collection</code> as 
type.
                  </p>
                  <p>
--- 295,299 ----
                      parameter are <code>Collection</code> and 
<code>Set</code>, in
                      accordance with the EJB specification. In this example, 
both our
!                     multi valued properties use <code>Collection</code> as 
type.
                  </p>
                  <p>
***************
*** 312,316 ****
                      In this example, the <code>getAddresses()</code> method 
of the value
                      object will return a <code>Collection</code> of
!                     <code>example.vo.AddressValue</code> objects. Thing 
should be
                      starting to make sense, no?
                  </p>
--- 312,316 ----
                      In this example, the <code>getAddresses()</code> method 
of the value
                      object will return a <code>Collection</code> of
!                     <code>example.vo.AddressValue</code> objects. Things 
should be
                      starting to make sense, no?
                  </p>
***************
*** 349,360 ****
                  <p>
                      Please notice the last three methods in this example. The 
Bean
!                     implementation class generated by XDoclet will contains 
them, but by
                      default they won't be included in the remote or local 
interface for the
                      bean. If you need to change that, you should declare them 
as abstract
!                     in your beans an tag them as you wish. In this example, 
we want the
                      methods exposed in the remote interface, so we tag them 
with
                      @ejb.interface-method. We don't want the
                      <code>setCustomerLightValue()</code> method exposed, so 
we don't
!                     declare them here -- it will be in the generated 
implementation,
                      however.
                  </p>
--- 349,362 ----
                  <p>
                      Please notice the last three methods in this example. The 
Bean
!                     implementation class generated by XDoclet will contain 
them, but by
                      default they won't be included in the remote or local 
interface for the
                      bean. If you need to change that, you should declare them 
as abstract
!                     in your beans and tag them as you wish. In this example, 
we want the
!                     <code>getCustomerValue()</code>, 
<code>getCustomerLightValue()</code>
!                     and <code>setCustomerValue(CustomerValue)</code>
                      methods exposed in the remote interface, so we tag them 
with
                      @ejb.interface-method. We don't want the
                      <code>setCustomerLightValue()</code> method exposed, so 
we don't
!                     declare it here -- it will be in the generated 
implementation,
                      however.
                  </p>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to