beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Page Flow Runtime Control Container Design
Date Thu, 19 Jan 2006 22:14:22 GMT
There isn't really any Controls related API exposed, only an ensure method
that takes no parameters.  A page flow does act as a Control container so it
don't see any difference from providing automatic container support in the
presence of the @control annotation and an ensure call for programmatic
control access.  I think I would not like to expose any of the low level API
that is the page flow runtime control container.

On 1/19/06, Eddie O'Neil <ekoneil@gmail.com> wrote:
>
>   Hm...this is a tricky issue.  I'd actually go a different route and
> do two things:
>
> 1) only create the CCC for each page flow in the presence of @Control
> annotations
> 2) explain how to write code to create a CCC and drive it through its
> lifecycle
>
> This is how the JUnit test container works for Controls -- you can use
> the ControlsTestCase base class or write code that calls utilities
> that provide the CCC and drive it through its lifecycle.
>
>   Seems like this provides the best of both worlds -- uses metadata to
> decide when controls are used but gives application developers a way
> to use controls programmatically without having a Controls-related API
> exposed on the Page Flow base class.
>
>   Yes, there's a compatibility issue *if* you used JPF from 1.0 and
> declared controls programmatically, but that's probably not very
> common.
>
> Eddie
>
>
>
>
> On 1/19/06, Daryl Olander <dolander@gmail.com> wrote:
> > So it turns out, there is indeed a test that creates a control
> > programmatically in a page flow.  This seems to leave us with two
> > alternatives
> > 1) we always create the CCC for every page flow
> > 2) we add an ensureControlContainerContextExists() API (to the base
> > PageFlowController) to make sure that it is created and initialized.
> >
> > I lean toward 2 because I think this use case is rare.  It is a backward
> > compatibility issue with our 1.0 release.
> >
> > Thoughts?
> >
> > On 1/18/06, Daryl Olander <dolander@gmail.com> wrote:
> > >
> > > This mail summarizes the proposed design for the Control container
> > > implementation inside of the page flow runtime.  It is a summary of
> the
> > > previous threads on this subject.  I'm currently in the process of
> > > implementing this solution and believe it solves the sets of issues
> brought
> > > up in those emails.  I would really like review of this solution and
> > > comments/questions so we can be sure this works.
> > >
> > > There are two basic requirements of the Control container
> > > 1) All controls have only a single thread in them at a time (Single
> > > Threaded)
> > > 2) The resources a control may acquire are only used for a single
> > > request.  It is ok if the resources are acquired more than once for a
> single
> > > request.
> > >
> > > In today's implementation, both of these requirements are violated by
> > > standard page flows and shared flows (and global app).  These issues
> are
> > > summarized in the previous threads on this subject.
> > >
> > > The proposed solution is this,
> > >
> > > For a standard page flow (normal page flow, singleton page flow and
> nested
> > > page flow), they have a ControlContainerContext (CCC) for the controls
> that
> > > they contain.  The CCC is only allocated if the page flow contains a
> > > control.  We will have to probably add an API someplace to create this
> if a
> > > user wants to create a control programmatically.
> > >
> > > For all Shared flows and global app, they will share a single CCC.
> > >
> > > During a request, there are three possible synchronization points
> where
> > > user code can run and call methods on controls
> > > 1) during onCreate when a page flow is created
> > > 2) during the beforeAction/Action/afterAction cycle
> > > 3) during JSP rendering
> > >
> > > During any of these, code may access a shared flow and interact with
> > > controls. For most page flow requests only 2 and 3 are run.
> > >
> > > For a the standard page flows, these synchronization points create a
> > > single threaded model.  For the standard page flow CCC, we will run
> the
> > > beginContext, endContext events which activate the resource
> lifecycle.  This
> > > is sufficient to guarantee 1 and 2.
> > >
> > > For shared flows, we still have issues if multiple threads are running
> > > through the session.  To solve this we will do this,
> > > 1)  We will create a single Lock object that must be obtained in the
> > > synchronization points before we can proceed.
> > > 2) Once the lock is obtained, we will run beginContext on the shared
> flows
> > > CCC.
> > > 3) We will run the normal user code
> > > 4) We will then run the endContext on the shared flows CCC
> > > 5) We will release the lock
> > >
> > > Rich, please verify this will work...
> > >
> > > The result of this, is that we will serialize threads within a session
> > > through these synchronization points.  The result is that shared flows
> will
> > > become single threaded (requirement 1 above) and because we run the
> > > beginContext/endContext that satisfies 2 above.
> > >
> > > There is a bit more overhead to this solution because there will
> typically
> > > be two CCC objects active at one time.  Deep nesting and singletons
> will add
> > > more.  The CCC is only created for page flows that have controls.  The
> > > benefits is that the CCC objects match the lifetime of the controls
> that
> > > they contain.
> > >
> > > Please review this and send comments.
> > >
> > > Thanks
> > >
> > > Daryl
> > >
> > >
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message