From: Marc P. <ma...@an...> - 2003-07-26 11:03:19
|
Guys, Just to make sure we are all reading from the same sheet now - I'm going to give some quick pseudo code for all the files involved. This is no doubt CONTENTIOUS! This is because the impl I am showing allows ContextAware detection for all variables placed into the context as well as "tools" loaded by the new factory/provider - something that has not yet been decided. Don't dismiss these changes just on that basis - this is to illustrate/confirm the general plan outlined by Lane (and earlier by myself). We can easily not do the instanceof ContextAware stuff in Context.put, but in that case we should definitely NOT do the same for tools returned from the provider. See comments inline. However all these changes really are relatively trivial - moving loadTools from Broker is the "biggest" job. I'm happy to do all this if you guys agree on the plan, if Lane isn't fussed about doing it. It would seem fitting that I have to do is, since I was the main protagonist in all this rucus. --- New file: ContextAware.java public interface ContextAware { void init( Context c); } --- ContextTool.java public interface ContextTool extends ContextAware { } --- New file: LazyVariableProvider.java I think this is the name that fits the functionality best, getting away from the ContextTool terminology, using WM provider terminology public interface LazyVariableProvider extends Provider { Object getVariable( String name, Context context); } --- New file: DefaultContextToolProvider.java The default impl providing existing CT functionality by excised from core of WM public class DefaultContextToolProvider implements LazyVariableProvider { //... impl Provider methods of course, including loading //existing CT definitions ... public Object getVariable( String name, Context context) { if (toolNamesMap.contains( name)) { return newToolInstance(name); // Note that without Context doing instance of in put for vars, we should then // have the instanceof ContextTool code in here somewhere and init tools ourselves. // instead of having Context do it. } else { return null; } } } --- Context.java Modifications.... public class Context implements Map, Cloneable { //...existing context stuff skipped... /** * Get the named object/property from the Context. If the Object * does not exist and there is a tool of the same name then the * Object will be instantiated and managed by the tool. * If there's no such variable, it throws. */ protected Object internalGet (Object name) throws PropertyException { Object ret = _variables.get(name); if (ret == null && !_variables.containsKey(name)) { // **** some modifications to remove CT dependency here Object tool = null; if (lazyVariableProvider != null) tool = lazyVariableProvider.getVariable( name, this); if (tool != null) { // Remove this code if we decide Context will not handle this kind of thing if (tool instanceof ContextAware) ((ContextAware)tool).init(this); } else if (name instanceof FunctionCall) { FunctionCall fc = (FunctionCall) name; String fname = fc.getName(); MethodWrapper func = null; if (_funcs != null) { func = (MethodWrapper) _funcs.get(fname); } if (func == null) { func = _broker.getFunction(fname); } if (func != null) { Object[] args = fc.getArguments(this); ret = func.invoke(args); } else { _log.error("Function " + fname + " was not loaded!"); } } else { // changed by Keats 30-Nov-01 return UNDEF; } //throw new // PropertyException.NoSuchVariableException(name.toString()); } return ret; } /** * Add an object to the context returning the object that was * there previously under the same name, if any. */ public final Object put (Object name, Object value) { // Remove this code if we decide Context will not handle this kind of thing if (value instanceof ContextAware) ((ContextAware)value).init( this); return _variables.put(name, value); } } -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
From: Brian G. <br...@qu...> - 2003-07-26 19:55:12
|
> However all these changes really are relatively trivial - moving loadTools > from Broker is the "biggest" job. I'm happy to do all this if you guys > agree on the plan, if Lane isn't fussed about doing it. It would seem > fitting that I have to do is, since I was the main protagonist in all this > rucus. This seems mostly reasonable, see comments inline. However, this seems nothing like your original proposal. What you've done is renamed ContextTool, not gotten rid of it. Now, perhaps that's what you meant all along, but that's certainly not what it sounded like you were proposing. > --- New file: ContextAware.java What does "context aware" mean? Can any provide three examples of something that is context aware that is not context tools? I still don't get the need for this concept beyond the existing tool mechanism. > --- New file: LazyVariableProvider.java I think this is the name that fits > the functionality best, getting away from the ContextTool terminology, > using WM provider terminology > > public interface LazyVariableProvider extends Provider > { > Object getVariable( String name, Context context); > } Good concept, but took a wrong turn somewhere. If you are going to be a Provider, be a Provider. Implement the Provider interface and that's it. Me, I personally think that the Provider framework is a terrible abstraction (I think you think this too) because it forces everyone who uses it to make all sort of hidden casting assumptions. This one is even worse -- its not really even a provider, since the meat of it is in an extra method that is outside Provider. In other words, either use Provider the way the rest of WM does (personally, I'd like to see the rest of WM use it less, until it gets to the point where it withers and dies on its own) or just define the factory you need. In any case, I don't think Context belongs in this interface. > --- New file: DefaultContextToolProvider.java The default impl providing > existing CT functionality by excised from core of WM Why? Why can't you just LEAVE IT THERE? If its so worthless, it will die of its own. > --- Context.java Modifications.... > Object tool = null; > if (lazyVariableProvider != null) > tool = lazyVariableProvider.getVariable( name, this); > > if (tool != null) { > // Remove this code if we decide Context will not handle this kind of thing > if (tool instanceof ContextAware) > ((ContextAware)tool).init(this); > } I think this is OK here, but not in the put() call. Putting it in the put() call is totally magic! (If the object implements this interface, then this magic thing happens.) > /** > * Add an object to the context returning the object that was > * there previously under the same name, if any. > */ > public final Object put (Object name, Object value) > { > // Remove this code if we decide Context will not handle this kind of thing > if (value instanceof ContextAware) > ((ContextAware)value).init( this); > return _variables.put(name, value); You can't put this here. However, you could add this: public Object put(Object name, ContextAware value) { } like the auto-wrapping we have for int and other primitives. |
From: Lane S. <la...@op...> - 2003-07-26 20:28:33
|
my comments... First: We WILL have Context Tools operational in Release 2. Period. Second: I will only defer to Marc's implementation if he keeps to the originally laid out spec. For example, I want an explicit boolean property as well as the class name because this makes things more clear to the property editor and allows for some optimizations. Third, Marc is seeking to slip a new feature into the put operation which is a replacement for Keats function proposal of MethodObject(Context, PrimaryObject). We need to keep things separate. I know that Keats proposal has merit: it allows static, stateless use of the context. I am not sure we are ready to bail on this proposal without some further debate. So, do not add Context.put(Object, ContextAware) quite yet unless Keats is ready to accept the possibility for both stateless and statul use of the Context. Brian is right-on about the put operation. Do NOT change the signature Context.put(Object, Object). Rather, add Context.put(Object, ContextAware) allowing method dispatching to eliminate unneeded conditional processing. This provides a nice wrapper around objects which need the context as a part of their state. Lastly, this item is not about some general LazyVariableProvider. It is about AutoContextLoading or AutoContextHandling. So, use a name like that. Why use a name that harkens to some other Provider abstraction in WM? With this implementation, meet the requirements, no more, no less. Are we there yet??? -Lane Brian Goetz wrote: >>However all these changes really are relatively trivial - moving loadTools >>from Broker is the "biggest" job. I'm happy to do all this if you guys >>agree on the plan, if Lane isn't fussed about doing it. It would seem >>fitting that I have to do is, since I was the main protagonist in all this >>rucus. >> >> > >This seems mostly reasonable, see comments inline. However, this >seems nothing like your original proposal. What you've done is >renamed ContextTool, not gotten rid of it. Now, perhaps that's what >you meant all along, but that's certainly not what it sounded like you >were proposing. > > > >>--- New file: ContextAware.java >> >> > >What does "context aware" mean? Can any provide three examples of >something that is context aware that is not context tools? I still >don't get the need for this concept beyond the existing tool >mechanism. > Marc is seeking a generalization so that any object in the context will be > > > >>--- New file: LazyVariableProvider.java I think this is the name that fits >>the functionality best, getting away from the ContextTool terminology, >>using WM provider terminology >> >>public interface LazyVariableProvider extends Provider >>{ >> Object getVariable( String name, Context context); >>} >> >> > >Good concept, but took a wrong turn somewhere. If you are going to be >a Provider, be a Provider. Implement the Provider interface and >that's it. Me, I personally think that the Provider framework is a >terrible abstraction (I think you think this too) because it forces >everyone who uses it to make all sort of hidden casting assumptions. >This one is even worse -- its not really even a provider, since the >meat of it is in an extra method that is outside Provider. > >In other words, either use Provider the way the rest of WM does >(personally, I'd like to see the rest of WM use it less, until it gets >to the point where it withers and dies on its own) or just define >the factory you need. > >In any case, I don't think Context belongs in this interface. > > > >>--- New file: DefaultContextToolProvider.java The default impl providing >>existing CT functionality by excised from core of WM >> >> > >Why? Why can't you just LEAVE IT THERE? If its so worthless, it will >die of its own. > > > >>--- Context.java Modifications.... >> >> > > > >> Object tool = null; >> if (lazyVariableProvider != null) >> tool = lazyVariableProvider.getVariable( name, this); >> >> if (tool != null) { >>// Remove this code if we decide Context will not handle this kind of thing >> if (tool instanceof ContextAware) >> ((ContextAware)tool).init(this); >> } >> >> > >I think this is OK here, but not in the put() call. Putting it in the >put() call is totally magic! (If the object implements this >interface, then this magic thing happens.) > > > >> /** >> * Add an object to the context returning the object that was >> * there previously under the same name, if any. >> */ >> public final Object put (Object name, Object value) >> { >>// Remove this code if we decide Context will not handle this kind of thing >> if (value instanceof ContextAware) >> ((ContextAware)value).init( this); >> return _variables.put(name, value); >> >> > >You can't put this here. > >However, you could add this: > public Object put(Object name, ContextAware value) { > } > >like the auto-wrapping we have for int and other primitives. > > > > -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga |
From: Marc P. <ma...@an...> - 2003-07-26 22:32:11
|
On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> wrote: > First: We WILL have Context Tools operational in Release 2. Period. I never said we shouldn't. My whole proposal was to keep all you CT advocates happy and keep it in 2.0! I can't believe I am still failing to get this across, despite source code examples showing this. Context doesn't need to know about ContextTools however. > Second: I will only defer to Marc's implementation if he keeps to the > originally laid out spec. For example, I want an explicit boolean > property as well as the class name because this makes things more clear > to the property editor and allows for some optimizations. I'm not asking anyone to defer anything. I'm just trying to see that we've all got the same thing in mind, and strangely it looks like we hadn't. I just don't see the need for this extra property. I currently fail to see how having an "enabled" property offers us any optimizations over "factory == null". Maybe I'm missing something? If factory name is blank in the config, we can set a boolean internally to true to indicate disabled, if you are concerned about avoiding a thread sync. Please, if there is a genuine need for this property please show me! > Third, Marc is seeking to slip a new feature into the put operation which > is a replacement for Keats function proposal of MethodObject(Context, > PrimaryObject). We need to keep things separate. I know that Keats > proposal has merit: it allows static, stateless use of the context. I am > not sure we are ready to bail on this proposal without some further > debate. So, do not add Context.put(Object, ContextAware) quite yet unless > Keats is ready to accept the possibility for both stateless and statul > use of the Context. I'm not seeking to slip anything new in! That was part of my original proposal and I put it in the example source to show you what I mean - and I clearly showed that it could be removed with the caveat, that makes sense to me, that Context does not do any init() calls either, that the tool loader implementation does this. > Brian is right-on about the put operation. Do NOT change the signature > Context.put(Object, Object). Rather, add Context.put(Object, > ContextAware) allowing method dispatching to eliminate unneeded > conditional processing. This provides a nice wrapper around objects which > need the context as a part of their state. Absolutely. That approach hadn't occurred to me and I completely agree with it, it makes perfect sense. > Lastly, this item is not about some general LazyVariableProvider. It is > about AutoContextLoading or AutoContextHandling. So, use a name like > that. Why use a name that harkens to some other Provider abstraction in > WM? With this implementation, meet the requirements, no more, no less. > > Are we there yet??? I'm really not sure. I was using Provider terminology because I thought you guys would prefer that - in keeping with existing WM paradigms. Will this, in your mind, be a 100% replaceable mechanism for returning new instances of objects only when required, with only one instance of this "factory" per Broker? If so, then we are definitely there! I don't really care what it's called. Marc -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
From: Lane S. <la...@op...> - 2003-07-27 02:06:16
|
Marc Palmer wrote: > On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> > wrote: > > I'm really not sure. I was using Provider terminology because I > thought you guys would prefer that - in keeping with existing WM > paradigms. > > Will this, in your mind, be a 100% replaceable mechanism for returning > new instances of objects only when required, with only one instance of > this "factory" per Broker? Yes. There will be one instance per broker. This is in my original proposal. -Lane |
From: Lane S. <la...@op...> - 2003-07-27 02:11:56
|
Marc Palmer wrote: > On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> > wrote: > > > Context doesn't need to know about ContextTools however. This above statement is so confusing as to border on the curious. Context.get(Object, Object) directly checks for a tool not in the context and, if one is specified by the key, the tool value is placed in the context. That is the way it works and this cannot be changed unless you want to break backward compatibility. Could some other use for context loading on a "fault" be dreamed up. Cannot think of one off hand. -Lane |
From: Keats <ke...@su...> - 2003-07-27 02:29:01
|
I think you are zeroing in on a critical distinction here. The context tool "load on fault" mechanism allows you to avoid the overhead of creating new instances of context-aware objects. Putting context aware factories into each request would accomplish the same thing, but with higher overhead. (Actually this is virtually equivalent to the way it worked prior to Brian's latest changes, since the factories, CTs, were kept in a map within each context.) It's really a "pull" verses "push" provisioning model. Keats Lane Sharman wrote: > > > Marc Palmer wrote: > >> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> >> wrote: >> >> >> Context doesn't need to know about ContextTools however. > > > This above statement is so confusing as to border on the curious. > Context.get(Object, Object) directly checks for a tool not in the > context and, if one is specified by the key, the tool value is placed in > the context. That is the way it works and this cannot be changed unless > you want to break backward compatibility. Could some other use for > context loading on a "fault" be dreamed up. Cannot think of one off hand. > > -Lane > > |
From: Marc P. <ma...@an...> - 2003-07-27 16:27:14
|
On Sat, 26 Jul 2003 19:29:35 -0700, Lane Sharman <la...@op...> wrote: >> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> >> wrote: >> >> >> Context doesn't need to know about ContextTools however. > > This above statement is so confusing as to border on the curious. > Context.get(Object, Object) directly checks for a tool not in the context > and, if one is specified by the key, the tool value is placed in the > context. That is the way it works and this cannot be changed unless you > want to break backward compatibility. Could some other use for context > loading on a "fault" be dreamed up. Cannot think of one off hand. Yes - any kind of application-supplied object that needs to be created, without following the ContextTool model - for example. And moving it all out of Context means you can completely avoid it all too. i.e. Context.internalGet would, if no var is found, see if it has a LazyVariableFactory, and if so ask that for an new instance for that variable name (AKA tool). Nothing else is required in my mind. That's why I say that Context doesn't need to know about ContextTool at all, only about LazyVariableFactory. Marc -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
From: Marc P. <ma...@an...> - 2003-07-26 22:53:02
|
On Sat, 26 Jul 2003 12:54:57 -0700, Brian Goetz <br...@qu...> wrote: >> However all these changes really are relatively trivial - moving >> loadTools from Broker is the "biggest" job. I'm happy to do all this if >> you guys agree on the plan, if Lane isn't fussed about doing it. It >> would seem fitting that I have to do is, since I was the main >> protagonist in all this rucus. > > This seems mostly reasonable, see comments inline. However, this > seems nothing like your original proposal. What you've done is > renamed ContextTool, not gotten rid of it. Now, perhaps that's what > you meant all along, but that's certainly not what it sounded like you > were proposing. Well this is certainly what I had in mind all along, and believe I put it into words in that mail of Thursday which I quoted earlier today. >> --- New file: ContextAware.java > > What does "context aware" mean? Can any provide three examples of > something that is context aware that is not context tools? I still > don't get the need for this concept beyond the existing tool > mechanism. As Lane is now saying, along with your suggestion, Context.put( String name, ContextAware obj) is a nice thing to have. It's less work for the caller - they can take off the shelf objects that impl ContextAware and put them into the context without having to init them themselves. >> --- New file: LazyVariableProvider.java I think this is the name that >> fits the functionality best, getting away from the ContextTool >> terminology, using WM provider terminology >> >> public interface LazyVariableProvider extends Provider >> { >> Object getVariable( String name, Context context); >> } > > Good concept, but took a wrong turn somewhere. If you are going to be > a Provider, be a Provider. Implement the Provider interface and > that's it. Me, I personally think that the Provider framework is a > terrible abstraction (I think you think this too) because it forces > everyone who uses it to make all sort of hidden casting assumptions. > This one is even worse -- its not really even a provider, since the meat > of it is in an extra method that is outside Provider. Agreed. As stated elsewhere, I just did this to try to keep inline with existing WM design. Everything I says pisses everyone off, so I thought I'd try to throw myself a bone! > In other words, either use Provider the way the rest of WM does > (personally, I'd like to see the rest of WM use it less, until it gets > to the point where it withers and dies on its own) or just define > the factory you need. OK, factory we need. Same as above then, but without "extends Provider". > In any case, I don't think Context belongs in this interface. Why? My whole idea is that this loader can act on information in the context to create new instances of objects (for instance access the Locale via a WebContext perhaps), and can automatically init any objects they create so they know about the context. Through this mechanism Context.java no longer needs to know about ContextTool, only LazyVariableProvider (sic). >> --- New file: DefaultContextToolProvider.java The default impl providing >> existing CT functionality by excised from core of WM > > Why? Why can't you just LEAVE IT THERE? If its so worthless, it will > die of its own. I have said this so many times now. By moving it out into an impl of LazyVariableProvider (sic) we give the application complete control over this mechanism. For example my web framework my have some special lazy tool mechanism that creates tools with a reference to a framework object, PLUS the Context instance. I may never want users to be able to specify ContextTools in the config due to an alternative mechanism in my framework, and as such would want to suppress completely the LazyVariableProvider (sic) mechanism by wiping the property. This is the most flexible way to achieve this, I think. >> --- Context.java Modifications.... > >> Object tool = null; >> if (lazyVariableProvider != null) >> tool = lazyVariableProvider.getVariable( name, this); >> >> if (tool != null) { >> // Remove this code if we decide Context will not handle this kind of >> thing >> if (tool instanceof ContextAware) >> ((ContextAware)tool).init(this); >> } > > I think this is OK here, but not in the put() call. Putting it in the > put() call is totally magic! (If the object implements this > interface, then this magic thing happens.) Yes, agreed about put() - but I think the above code shold be in the "existing ContextTool emulation" impl of LazyVariableProvider. But hey, you knew that already. >> public final Object put (Object name, Object value) >> { >> // Remove this code if we decide Context will not handle this kind of >> thing >> if (value instanceof ContextAware) >> ((ContextAware)value).init( this); >> return _variables.put(name, value); > > You can't put this here. > > However, you could add this: > public Object put(Object name, ContextAware value) { } > > like the auto-wrapping we have for int and other primitives. 100% Agreed. -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
From: Lane S. <la...@op...> - 2003-07-27 02:21:11
|
Marc Palmer wrote: > On Sat, 26 Jul 2003 12:54:57 -0700, Brian Goetz <br...@qu...> > wrote: > > Agreed. As stated elsewhere, I just did this to try to keep inline > with existing WM design. Everything I says pisses everyone off, so I > thought I'd try to throw myself a bone! Nobody is pissed off, Marc. We are just all trying to get to some closure. Sometimes you get some English wind in your posts and they take us where we have a hard time following. You may be a bit sleep deprived :). -Lane |
From: Marc P. <ma...@an...> - 2003-07-27 16:31:25
|
On Sat, 26 Jul 2003 19:38:53 -0700, Lane Sharman <la...@op...> wrote: >> Agreed. As stated elsewhere, I just did this to try to keep inline with >> existing WM design. Everything I says pisses everyone off, so I thought >> I'd try to throw myself a bone! > > Nobody is pissed off, Marc. We are just all trying to get to some > closure. Sometimes you get some English wind in your posts and they take > us where we have a hard time following. You may be a bit sleep deprived > :). :) Nah I'm not thanks. My mails perhaps seem overly serious, but it's just because you don't know me in person. I'm very light-hearted and I meant the above in a lightheared way :) -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |