On 14.03.2002 16:51:55 Joerg Pietschmann wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > But I think you have some fears because you know too little of Avalon. > > Well, thats nearly the core of the problem. Actually, in my case > JAXP is the ultimate cause. > > We started using XSLT in a servlet using JAXP, which defines > its own facilities for dealing with problem reports (ErrorListener > and such), configuration data and various customizations. After > some struggling we successfully plumbed it into the environment. > > Then there was the task to integrate FOP, which comes with yet > another set of interfaces and other stuff to deal with problem > reports and configuration data. It was to be expected that it > wouldn't be the same as JAXP, but the relevant FOP/Avalon APIs > are simply much too different from JAXP and noticable more complex. > They may be superior to JAXP, but JAXP came first.
That's a good point. Since I have a day off tomorrow and Michael is doing the logging stuff, I might look into the issue if FOP and JAXP might be able to get a bit closer together. > If i learned something during some 5+ years of interface design, > it is that users get very upset if they think something should > follow a common pattern but it doesn't. If they have to do similar > things they expect to be able to do it in a similar way. Having > to learn new ways is nearly as repugnant to them as paying taxes, > even if its obvious there will be a benefit somewhere down the road. > > It gets worse when developers have to tell their project managers > they'll miss a deadline because they have to figure out another > way of doing things they've already done in another context. > Managers have a tendency to miss or ignore the "another context" > part. This adds to the pressure. Can't deny that. > > We just > > want to use a tiny part from Avalon where logging is concerned and an > > embedder will not have to learn the Avalon way if he doesn't want to. > > Note that configuration is also an issue. Note further that files > are also parts of an interface, however well hidden. Agreed. I forgot that point in the last few days. It's something I also had in the back of my mind. FOP has its own configuration code at the moment. This could be replaced by using Avalon's Configuration stuff (maybe including that new CascadingConfiguration that I still have to check out). I will need some configuration stuff when I'll have time to bring the PostScript renderer up to production level and as soon as we're going to use Avalon components there will be a need for ComponentManager (or equivalent) and therefore for Avalon's configuration mechanism. > I met a Batik developer at the xml/webservices conference this > week, and discussed this problem shortly as it applies to Batik > too. I hope some ideas will emerge for converging to a consistent > and easy to use interface for various kinds of processors. That could be helpful. Maybe we already have something like that: Cocoon has interfaces like that (Serializer? Just a thought!). Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - 6002 Luzern Fon +41 (0)41 317 2020 - Fax +41 (0)41 317 2029 Internet http://www.outline.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
