On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Oct 10, 2006, at 7:53 AM, ant elder wrote: > I'd be really happy for all those to become part of the core, but > I'm not > sure I see how all that remains will be a few three-line > statements. How > about I move this to a container-helper as I suggested before, we > pull all > the bits out and do the refactoring and before we cut M2 see whats > left and > if there really is nothing much left just doc it otherwise re- > evaluate then > what to do with what remains? I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one. In the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file. Without this, we can't properly support scopes in side files so I'd like to get this fix in. In addition, I'd like to get duplicate code taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing to take this on and help out since I think this is important we clear up. Also, I still believe once we take care of these issues we probably won't need a separate extension library. One issue is this does affect the SPI and I think we need to assess the risk of these changes on getting the release out. If people are o.k. with me doing these changes, I'll jump in and make them. If it poses too much risk, I suggest we consider branching. Thoughts? Jim
As you don't like the easy SPI extension I've got rid of the easy extension dependency of the script container. I've moved the script container into trunk as it was going stale and i want to start using and improving it. It still uses some of the easy classes which are in a helper package now, i'll get rid of them as we clean things up. I saw you've done some core changes for the componentType problem, thanks, I'll go look at how to use that for this (and the other script containers) and change the code as appropriate. You said you'd take on getting the things like the async code into the spi to avoid all that duplicate code so would you like to go ahead and do that now? (or I can do it if you like). Once the componentType and async changes are done I/we can look at the next things to simplify and once all that refactoring is done I'll look at what remains in the helper package and see if there are still things I think could be simplified. ...ant
