cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <timlarsonw...@yahoo.com>
Subject Re: [cforms] Forwarding: Explanation of "dynamic stuff in form model"
Date Tue, 06 Jan 2004 20:47:42 GMT
--- Marc Portier <mpo@outerthought.org> wrote:
> Tim,
> 
> your postings on the list urged me to get some deeper into this
> specially on the 'cyclic' stress on the building process brought
> in by the class/new stuff and specially how that clashes with the
> 'private final' mantra I've been chanting :-)
> 
> obvious observation is that the cyclic stuff will prevent us from doing 
> any 'final' declaration on the pointer from 'new' to it's 'class'...

I found a solution that allows a true 'final' declaration!

Problem:
  If we create an instance of A before B exists, then when B is created
  it is too late to set the reference to B in the 'final' member of A.
  Of course there is no problem setting the reference to A in the 'final'
  member variable of B, because A already exists.  The cyclic problem is
  that there is no order in which to create A and B such that each can
  hold a 'final' reference to the other.
Solution:
  If we could split the timing of the creation of the object A or B from
  the initialization of the 'final' member variables the cyclic problem
  would vanish.  This can be done by initializing the 'final' member
  variable in a constructor.  Some sample code may make this clearer:

  class Sample {
      private final Sample child;
      public Sample(Builder builder, Sample child, String otherConfigData) {
          if (child != null) {
              this.child = child;
          } else {
              this.child = builder.getChild(this, "someChildId");
          }
          // Use otherConfigData to finish setting up object
      }
  }

  class Builder {
      public Sample build() {
          // Because the value 'null' is passed in place of an
          // actual child reference, we know that the constructor
          // for this object will call this builder's getChild
          // method.  We will continue building from there.
          Sample sample = new Sample(this, null, "Some config data");
      }
      public Sample getChild(Sample parent, String childId) {
          // The parent object (think object A in the example)
          // has been created by this point, but its constructor
          // will not finish processing until this method returns
          // the requested child reference.
          // If we now happen to build object B, from the example,
          // we have a reference to object A ready to pass as the
          // child object parameter to the constructor that builds
          // object B.  After object B is built, this method can
          // use a return statement to pass the reference to object
          // B back to the constructor of the parent that requested
          // it (object A).  Problem solved, compiler happy :)
      }
  }
        
Application of this solution to the building of cyclic bindings and
definitions is trivial and is left as an exercise for the reader ;)

WDYT?
--Tim Larson

<PS> Marc, I'm still mentally working through your responses and will
eventually give a point-by-point reply.  I'm not sure what my
timetable looks like right now, though.  As a quick note, neither
"class" nor "new" currently wrap any namespacing around the widget
definitions that are retrieved from the class via "new".  That is:
  <wd:class id="asdf">
    <wd:widget id="qwerty"/>
  </wd:class>
  <wd:new id="asdf">
is functionally equivalent to:
  <wd:widget id="qwerty"/>
and *not* to:
  <wd:some-wrapper-widget-or-element id="asdf">
    <wd:widget id="qwerty"/>
  </wd:some-wrapper-widget-or-element>

(How) does this affect your proposals?
</PS>

--Tim Larson


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Mime
View raw message