On 26.06.2003 20:13:06 Victor Mote wrote: > Well, its a whole lot more than an API and there are some implementing > classes in your spec. However, thanks for clarifying.
Only two classes (DefaultFOProcessorFactory and AvalonFOProcessorFactory) to show how the two world can be made more or less compatible. > OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor > is roughly equivalent to Document (I don't care about the terminology, I'm > just trying to find where we thinking the same and where we are not). I guess so. > > Of course, it can be reused. Nothing prevents you from passing in the > > same DocumentMetadata into the FOPResult. But nobody will want to do > > that anyway because metadata like "title" will probably change with each > > document being processed. I think we don't talk about the same thing. > > That is not reuse. The metadata example is a trivial one. A Collection of > Fonts used and Fonts to be embedded would be a more important one. However, > I don't care. You are correct that we aren't talking about the same thing. Then you mean reuse in the context of producing multiple output formats in one renderung run? > > Right. but I think RenderType is not the right name for this because it > > only suggests to be information about which renderer is to be used. It > > omits all the nice parameters you want to pass over. > > I don't understand your last statement, but I agree that FOPResult is a > better name than RenderType. Let's try different wording: The name "RenderType" suggests that it is a enumeration or a parameter, but it's more than that. > Hmmm. The whole thing seems pretty heavyweight to me (at least compared to > my proposal). Since my real interest is Control and not API, I think the > most productive thing for me to do is to simply defer on the API issues to > those of you who care more about them. As long as we can build whatever > Control infrastructure under that API that we want to (and it looks like we > can), and if you guys are happy with the API, we can defer that part of the > discussion until another day. It may very well be that when I see how your > vision is implemented, I will find the Control structures that (I think) I > need and that we are done anyway. I think we're getting in the right direction. I think, my API proposal would enable a stable API and you can concentrate on what's necessary to do inside FOP to handle the whole processing. You can even experiment over time, changing the inner glue without changing the API. And a stable and flexible API is one of the most important things to me. We changed the Driver class too many times. Hopefully, my proposal could improve this. Just trying to decouple... But I disagree with the heavyweight thing. It's only the most necessary things well separated by topic. Expand on your proposal to enable all the functionality my proposal covers. I wonder how lightweight yours stays. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
