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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > >
