On 1/15/02 6:20 AM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl <[EMAIL PROTECTED]> writes: > >> On 1/11/02 6:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >> >>> dlr 02/01/11 15:37:56 >>> >>> Modified: src/java/org/apache/stratum/xo Mapper.java >>> Log: >>> o Removed use of basePackage -- it made too many assumptions about how >>> the class hierarchy is structured. With it, child elements had to be >>> in the same package as their parent. >> >> Why did you do that? That's one of the whole tenets of this class is that >> the simple case works. For a small object model the classes will be in the >> same package. I certainly don't mind the addition of logic to handle what >> you wanted for the pipeline, but you i) didn't discuss anything ii) you >> broke the testbed. What you removed I think is a real convenience, you could >> have added your more sophisticated behavior overtop of what was there. > > I agree with that last statement -- I said approximately the same on > IRC before reading this mail: > > [01:42:00] <dlr_h> jason: WRT Mapper, you can now either pass in a > class name to map(), or null to have the Mapper examine the descriptor > for a className element or attribute > [01:43:16] <dlr_h> Using the package of the enclosing class is an > unreasonable assumption for the default behavior -- Scarab SourceCast > integration broke it immediately. It might be okay as a tertiary > behavior, for use if the first two checks fail. The tool was originally made a simple case tool, primarily to unify configuration patterns and simple object mapping. Scarab and SourceCast are using XML to serialize an object model? > So having now gone over this evening's changes, I think that the > className attribute should be looked for first, then if that doesn't > exist, the simple case where nested elements are in the same package > as the parent should be tried. That's what's happening now, but I think you will discover that this pattern will primarily happen in configuration patterns. If an apps model was serialized this pattern wouldn't apply and the nested elements would more accurately represent the model of an application. If this tool gets used for simple app model serialization (serialization isn't done yet, looking at the bean writer in the commons as a base and some code that Claude Duguay sent me) than the search for nested elements first would probably make more sense because parsing configurations isn't all that performance critical. > I need to take another look, but I > think this is the reverse of the order specified in your changes > tonight. I think the check for the className should come first, > because if users go to the trouble to specify the className attribute, > that's probably the value that they want for className. As you say > above, the simple case where no className is specified will still work > like a charm. For a noun singular occurrence the className is being looked for first. >>> o Added elementClassName() method for use in discovering the class >>> name of a nested element (and allowing the removal the the "same >>> package" assumption). >> >> A big fat -1, the torque object model can be rather complicated and it fits >> perfectly fine in a single package. > > But it doesn't work well when integrating full Turbine components into > a larger system where some percentage of their pipeline need to be > replaced. I think we're on the same page (as in the previous > comment), so figure you're just objecting to having the simple > behavior removed (please speak up if otherwise). I object to having the simple behaviour removed. I am fully cognizant that it is simple, I like that it's simple. More complicated behaviour can be added but I'm trying to replicate the digester. If you need some serious convoluted mapping than the digester should be used. I think a few simple patterns will work though with the addition of the className search I think configuration files will be much easier to deal with. >>> o Renamed elementToClassName() to makeMethodName(). As its >>> assumptions about package structure didn't hold, it's now used only to >>> generate the name of the method used to add objects to a parent bean. >> >> The assumption definitely holds as one simple, one moderately complicated >> model (Torque), and one pretty complicated model (Maven) all worked under >> this assumption and as the tests showed the assumption works fine. Like I >> said additional complexity is fine, but there's no reason to remove handling >> for simple and commons cases. > > The assumption failed when used with the kind of model used in > component integration (Scarab) into a large system (SourceCast). So? How does that negate the fact that it works for many cases? I think both will work, the simple doesn't need to be removed. >> I will put the behaviour back as I've already made changes to make the class >> work with InputStreams so it can deal with resources in the filesystem and >> the classpath. > > You regressed the classpath loading I'd already added. As I mentioned in the meeting we had the other day I want to use the resources package to handle this. The application has to deal with how it wants to search for resources and once the application determines where its resources are the mapper can be used. The classpath loading works, but it doesn't work well when both file systems and classpaths are used. I think the better approach is letting the application determine where its resources are and give the mapper an inputstream. I think having the logic in the mapper is wrong as when we add new places to store the configuration the logic will have to be added to this class. I would like all the I/O strategies to be localized in the resources package. I realize the file approach on it's own is deficient. I probably should have started with an inputstream and only used an inputstream but I made the mistake of only using files. I poked in the resources package and will get Turbine working from a WAR file and the filesystem today. > Dan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
