On 13.01.2003 19:18:18 Victor Mote wrote: > Jeremias Maerki wrote: > > > Can we sketch that on the Wiki in some simple way? Defining some Java > > interfaces and things like that? Anyway, as you mentioned we should sort > > out things like "Session" and "Document" on another page first. > > OK, I just put a proposal out there in the section discussing "Facade". More > on this below.
Mmmmmh, yes, I'm not so happy about it, yet. I'll add my comments as soon as my current task is done. > > It would be great if you would read up on Avalon a bit. > > I assume that we are talking about the Framework stuff here. I still haven't > found the ServiceManager that you mentioned. Yes, we're talking about Framework. Framework defines the contracts in an Avalon system which includes ServiceManager. ServiceManager is the successor to the ComponentManager which was deprecated because every service/component had to implement a Component marker interface with no methods. The ServiceManager now returns simple Objects that need to be casted to their work interface. Here's the link to the API docs of the Service package. http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/service/package-summary.html See here for the "Developing with Avalon" guide: http://jakarta.apache.org/avalon/developing/framework.html (this is a MUST read) > > Do I get you right that you would get something like that? > > > > public interface Font { > > > > String getFontName(); > > int getFontWeight(); > > int getFontSize(); > > > > FontMetrics getFontMetricsForLayout(); > > } > > > > public interface FontMetrics { > > > > //These methods already take font size into account > > int getAscender(); > > int getDescender(); > > int getCapHeight(); > > //more... > > int getWidth(char c); > > boolean hasKerningAvailable(); > > //more... > > } > > > > That looks promising. > > See the wiki where I have added a couple of things to your outline above. > The main difference is that I am not thinking of it as an interface, because > I only ever want one implementation. The concrete class is itself the > interface that the remainder of the system uses. My un-OOP (but not > anti-OOP) background is probably showing through here, so please talk me out > of this if I am out of line. I guess I will. :-) > The reason for my approach is that ideally, > what we might want here is for java.awt.Font to be in implementation of the > interface that we wish to use. That is not an option. So what we are > building is a /virtual/ interface that we can hide java.awt.Font and /all/ > other font concepts behind. We are trying to find commonality between > objects that have similar real-world characteristics, but that have no > compiler-level common heritage. There may be a better way. There, you are on the right track IMO. > > Yes, I share your unease, but I look at it from this side: Multiple area > > trees mean possibly different layout which can be a problem when you're > > working in an environment where you're working with legally relevant > > documents. Two generated documents from the same source must be as equal > > as possible. (funny use of "equal", I know) > > I guess what I am saying is that different fonts used will probably /force/ > different area trees. So, from out standpoint, better to disallow it than to > disappoint. I guess Peter is right that we have to keep it simple for now. Let's stay on the safe side and be ready to adapt to future changes. > Sorry to be so slow in responding. No problem. There's so much to do that I'm not getting stuck. Sorry for not immediately answering in more detail. I've got to get my head clear for that first. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
