On Sun, 8 Dec 2002 09:46 pm, Leo Sutic wrote: > I'd like to offer the following definition of a context: > > The Context is used as a means to provide data and a set of operations to > the component.
This is really just describing where we started. You don't explain what Context *means* to the component, and why that meaning is useful. > > OK, so what data and what operations? > > My thoughts are this: > > Data: The data is not a general Object-passing mechanism. That is, the type > of data being passed is limited. Every container, when it deploys its > components (be they servlets or maillets or whatever), sets up a small > block of data for it. Can you give a tighter definition? What is the data limited to? What distinguishes this data from, say, data provided by other components? What does this data mean to the component? > Operations: The operations provided by the context can and should primarily > be accessed via a ServiceManager, but there are operations that belong in a > context more than other operations. Those operations that should be in a > context are those that require the above mentioned data block to work. Why do some operations belong in Context and the rest in ServiceManager? How is this beneficial enough to the component writer to offset the fact that they are forced to locate some operations from one place, and other operations from an entirely different place? How does this remain beneficial when the split is undefined by framework, and highly container dependent? -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
