Changing the method signature to the following, since it's the minimum
needed if we did want to create a DefaultDataContextFactory or do a
trivial subclass of DataContext.
public interface DataContextFactory {
DataContext createDataContext(QueryEngine parent, ObjectStore objectStore);
}
On 9/15/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > and Andrus wanted to hold off at the time because he was in the middle
> > of refactoring ObjectContext.
>
> Sorry for being a bottleneck :-) Lets go ahead with it. I'd still
> vote for a factory interface. How about API like that:
>
> public interface DataContextFactory {
> DataContext createDataContext();
> }
>
>
> > Or is it better to have a setDataContextFactory() method? Seems like
> > that might be better considering that we might want to pass some
> > arguments to the DC constructor.
>
> This is what I was thinking too.
>
> Andrus
>
>
>
> On Sep 15, 2005, at 4:15 PM, Mike Kienenberger wrote:
>
> > Ok. We've talked about this before,
> >
> > http://www.objectstyle.org/cayenne/lists/cayenne-user/
> > 2005/07/0016.html
> >
> > and Andrus wanted to hold off at the time because he was in the middle
> > of refactoring ObjectContext.
> >
> > There's a few of us out here who'd like the convenience of subclassing
> > DataContext.
> >
> > http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-376
> >
> > I'm no expert on writing Factories, but it seems like it'd be easy
> > enough to provide java support just by adding a setDataContextClass()
> > method on DataDomain.
> >
> > Or is it better to have a setDataContextFactory() method? Seems like
> > that might be better considering that we might want to pass some
> > arguments to the DC constructor.
> >
> > I know there's eventually going to need to be some support in the
> > modeler, but I think providing programmic access is a step in the
> > right direction.
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 15 2005 - 17:25:55 EDT