You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gr...@yahoo.com> on 2004/11/01 03:02:40 UTC
Re: AreaFactory patch
I'd rather we have pluggable LayoutManagers -- 1.0's
emphasis and I think our previous agreement with
Finn/Simon -- than have pluggable Area objects (where
much of layout used to be in 0.20.5.) I'm not sure if
Fop can realistically handle both at this time.
As for complexity, in our LM's, with Tybor's proposed
change, instead of just:
curBlockArea = new Block();
we would now have:
curBlockArea = (Block) fobj.getUserAgent().
getAreaFactory().create(Block.class, fobj, this);
instead of:
viewportBlockArea = new BlockViewport();
we would now have:
viewportBlockArea = (BlockViewport)
fobj.getUserAgent() .getAreaFactory().create
(BlockViewport.class, fobj, this);
over and over again. The question here seems to be:
should we add this additional complexity to our system
*now* so Tybor doesn't need to rewrite code every week
he does a cvs update? Or have him tolerate it until
1.0 is out (when presumably, he can rely on a
production release and not need to update every week.)
Personally speaking, I am much more amenable to adding
some complexity (LM Makers, for example, or opening up
our validation) if it helps out Finn's work, because
of the sheer weight of contributions he adds to Fop.
(We slow him down, we slow down Fop.) Making these
changes for someone who isn't submitting
contributions, however, is less of a concern for me.
If a user is going to propose a change that would slow
down system development, we should be getting some
work to compensate for it, at least during this time
while we are still building the system.
My inclination is to have him place this patch in
Bugzilla, and let's wait until we have others
requesting it (vs. those who would rather have LM's
pluggable.) In the meantime, I think it would be best
for everyone to keep layout as simple as we can until
it is done. I am open to others' opinions however.
Glen
--- Tibor Vyletel <ti...@centrum.sk> wrote:
> Hello Fopsters,
>
> I have attached first phase (a working example) of
> the refactoring I was
> talking about in my previous mails. Please let me
> know, if this change is
> acceptable for you. If it is, I will finish it
> afterwards.
>
RE: AreaFactory patch
Posted by Victor Mote <vi...@outfitr.com>.
Finn Bock wrote:
> I got some minor suggestions to the patch:
>
> - It should be strict typed: createBlock(..), createInline(..)
> - It should be complete so that all area creation was done through the
> factory, not just the 3 areas that Tibor needs.
Yes.
Victor Mote
Tibor's AreaFactory patch (Re: AreaFactory patch)
Posted by Glen Mazza <gr...@yahoo.com>.
--- Finn Bock <bc...@worldonline.dk> wrote:
>
> I only see a need for plugable LMs, but the
> AreaFactory patch is so
> small that I see no problem with throwing a bone to
> Tibor.
>
> regards,
> finn
>
OK, that opinion was what I was trying to get at.
Someone else to second Andreas' feelings on the issue.
Tibor, you may wish to try again with a Bugzilla patch
but incorporate Finn's two suggestions. Also, you
were completely correct as to the purpose of
FOUserAgent, so if you can have the getAreaFactory()
implemented somewhere else outside of that class (LM
package, perhaps, or other places) that would a good
idea. (FOUserAgent.*set*AreaFactory() is still fine.)
Please place it in Bugzilla, and we can have the rest
of the team comment on it. I see nothing vetoable
myself, so it will be on how others feel. No
guarantees, but hopefully another team member
(Andreas?) will apply it for you. I, however, will be
taking myself out of this issue.
If however, you're really fine with just Pluggable
LM's, another option is to modify Finn's patch on the
issue:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30500
It's a bit out of date due to other changes in the
code (namely, I moved layout code out of the former
AddLMVisitor and into new LM classes after this patch
was done.) But that would also be helpful for others.
Thanks,
Glen
Re: AreaFactory patch
Posted by Finn Bock <bc...@worldonline.dk>.
[Glen]
> Finn, keep in mind--both you and Simon wanted
> pluggable LM's, and you even supplied a patch for it a
> few months ago. But you have been mostly silent on
> the matter ever since (i.e., it looks like you don't
> have a need for it ATM.)
Or perhaps I've been working on other things, like property
optimizations and exceptions. And just maybe I didn't feel that I had to
be the one who implemented plugable LMs since I wasn't the one who
removed the existing plugability.
> So sometimes it is good to
> have things sit in Bugzilla for a couple of months,
> see if others want it, or what modifications they
> want, or see if even the original requestor still
> needs it.
>
> Also, Tybor seemed to be fine with using pluggable
> LM's instead of pluggable Area's--i.e., not even
> needing them *now*--which would make his desires in
> sync with yours and Simon's (and mine), as well as
> keep our layout code in our LM's instead of moving to
> the Area objects. Do you still see a need then for
> *both* pluggable LM's and pluggable Areas in our code
> then? I didn't find that realistic, as I am uncertain
> of the additional power that it offers, but am asking
> your opinion here.
I only see a need for plugable LMs, but the AreaFactory patch is so
small that I see no problem with throwing a bone to Tibor.
regards,
finn
RE: AreaFactory patch
Posted by Victor Mote <vi...@outfitr.com>.
Glen Mazza wrote:
> I've bought it due to my work with the apps package and
> removing AddLMVisitor, and how reducing the complexity
> allowed many other changes in other areas that weren't
> previously apparent to occur. I also think that many of your
> later enhancements in properties wouldn't have become obvious
> if you didn't first get us out of the XSLT-generated
> properties classes. Even I was able to implement some
> (minor) property-related API changes as a result of your work
> in getting rid of the autogenerated code.
I know better than to take this bait, but ...
1. The XSLT-generated stuff is a separate issue. Not relevant here at all.
2. It has already been pointed out that, if the Visitor stuff was so
terribly complex, there were other solutions that could be applied that
didn't sacrifice modularity. Also, it was never intended as a long-term
solution, but rather reflected the current state of the layout design,
which, after modularization, would have (or could have) changed.
3. Things should be made as simple as they can be, and no simpler. More
importantly, there are tradeoffs even within simplicity. Modularization is
one aspect of simplicity. It is true that modularization requires the use of
interfaces, which add some incremental complexity. But the benefits of
having good interfaces and clean separation of concerns reduce complexity
much more on a different axis. I have said before that I am glad that Xalan
is a separate module from FOP -- that was good thinking. I'm glad that FOP
doesn't have to compute disk sectors or lay out pixels on a page -- somebody
was smart enough to abstract out operating systems and printer drivers
instead.
Now, some on this list persist in the "let's finish coding the project and
then we'll stop and design it" line of argument. I have taken it as a
settled issue that this is FOP's policy, hence FOray. I won't work on a
project that takes that attitude. I unwittingly tried that for about 18
months, lost a year of my life and an incalculable amount of money in both
real and opportunity costs. FOP lost a good (IMO) developer and managed to
create for itself unnecessary and wasteful competition where none was really
needed. What a waste.
So here is a promising developer that shows up with an idea. It helps him
get his work done, and seems to make for a cleaner design (I haven't looked
at it closely, but I haven't heard anybody argue with this). You can tell
him (like you did me) "we don't need no steeenking clean design." Or you can
learn a lesson and try to start developing relationships with the kind of
developers that you are going to need to finish this project. Makes no
difference to me. But, please, if you choose the former, send that promising
developer toward FOray -- I'm almost at the stage where I can drop in the
new layout system there. We'll find a place for good design ideas there.
Victor Mote
Re: AreaFactory patch
Posted by Glen Mazza <gr...@yahoo.com>.
--- Finn Bock <bc...@worldonline.dk> wrote:
> [Chris]
>
> >>I'm definitely in agreement with you on this one
> Glen. Lets keep
> >>Layout simple whilst its still unfinished.
> >>Pluggable LMs can be added once we have an
> >>initial release.
>
> [Andreas]
>
> > Well... (sigh)... well ('nutha sigh)
> >
> > What *does* Finn think, in that case? So far, I've
> yet to hear a single
> > *solid* argument pleading against the proposed
> change. Of course, something
> > like LM Makers can be added later on --the
> proposed AreaFactory shouldn't
> > hinder that.
>
> I got some minor suggestions to the patch:
>
> - It should be strict typed: createBlock(..),
> createInline(..)
> - It should be complete so that all area creation
> was done through the
> factory, not just the 3 areas that Tibor needs.
>
Finn, keep in mind--both you and Simon wanted
pluggable LM's, and you even supplied a patch for it a
few months ago. But you have been mostly silent on
the matter ever since (i.e., it looks like you don't
have a need for it ATM.) So sometimes it is good to
have things sit in Bugzilla for a couple of months,
see if others want it, or what modifications they
want, or see if even the original requestor still
needs it.
Also, Tybor seemed to be fine with using pluggable
LM's instead of pluggable Area's--i.e., not even
needing them *now*--which would make his desires in
sync with yours and Simon's (and mine), as well as
keep our layout code in our LM's instead of moving to
the Area objects. Do you still see a need then for
*both* pluggable LM's and pluggable Areas in our code
then? I didn't find that realistic, as I am uncertain
of the additional power that it offers, but am asking
your opinion here.
>
> I've never bought the increased complexity argument.
> Not in this case
> and not in any of the previous cases where it was
> raised.
>
I've bought it due to my work with the apps package
and removing AddLMVisitor, and how reducing the
complexity allowed many other changes in other areas
that weren't previously apparent to occur. I also
think that many of your later enhancements in
properties wouldn't have become obvious if you didn't
first get us out of the XSLT-generated properties
classes. Even I was able to implement some (minor)
property-related API changes as a result of your work
in getting rid of the autogenerated code.
Glen
Re: AreaFactory patch
Posted by Finn Bock <bc...@worldonline.dk>.
[Chris]
>>I'm definitely in agreement with you on this one Glen. Lets keep
>>Layout simple whilst its still unfinished.
>>Pluggable LMs can be added once we have an
>>initial release.
[Andreas]
> Well... (sigh)... well ('nutha sigh)
>
> What *does* Finn think, in that case? So far, I've yet to hear a single
> *solid* argument pleading against the proposed change. Of course, something
> like LM Makers can be added later on --the proposed AreaFactory shouldn't
> hinder that.
I got some minor suggestions to the patch:
- It should be strict typed: createBlock(..), createInline(..)
- It should be complete so that all area creation was done through the
factory, not just the 3 areas that Tibor needs.
> All we heard up to here is a few vague concerns about so-called increased
> complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
> for chrissake! It doesn't bite... or does it? Anyone?
I've never bought the increased complexity argument. Not in this case
and not in any of the previous cases where it was raised.
regards,
finn
Re: AreaFactory patch
Posted by Chris Bowditch <bo...@hotmail.com>.
Andreas L. Delmelle wrote:
<snip/>
> Hi fellas,
>
> Well... (sigh)... well ('nutha sigh)
>
> What *does* Finn think, in that case? So far, I've yet to hear a single
> *solid* argument pleading against the proposed change. Of course, something
> like LM Makers can be added later on --the proposed AreaFactory shouldn't
> hinder that.
>
> All we heard up to here is a few vague concerns about so-called increased
> complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
> for chrissake! It doesn't bite... or does it? Anyone?
Well, Im not trying to start a fire fight here. And its true that the
requested change is a simple Factory pattern. I agree the concept is simple.
But what I object to is people keep adding loads of pluggable this and
pluggable that to a system whose basics arent yet finished.
So all I am trying to say is lets hold off on pluggable interface A, B and C,
until the basics are finished. I dont think this is a vague arguement.
It may also be worthwhile stepping back from implementations here and consider
what are the business reasons for adding the pluggable LMs? Just because a
newbie on the list says he needs them, he doesnt say why, we have just
accepted that maybe he does. I think we should ask what the business usecase
is? Is it related to XSL-FO in anyway, we dont know. If theres a good business
case, then I wont object. But so far, no business requirements have been stated.
<snip/>
Chris
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> Ah, now I'm starting to see where this is going. I think this
> something extremely difficult to do. To a certain degree it
Agreed.
> sounds like my ideas/plans for the XML Graphics project,
> namely to separate certain peripheral components (fonts, PDF
> lib, Graphics2D implementations etc.) from FOP so efforts can
> be pooled between projects where easily possible (i.e.
> without major religious wars). For example, Peter is quite
> interested in the Graphics2D implementations. But going to a
> level of detail you hint at (at least that's my impression)
> will prove really difficult. You know I'm all for
> componentization, but you may have too high hopes here. But I
> could be wrong. Don't spend too much time explaining this to
> me. :-) We'll just see what happens. I will monitor what's
The "standards" themselves do not need to be monolithic. So maybe one
implementation implements only aXSL-Font (I'm making this up as I go), while
another might implement all of them.
The idea is that one more axis of benefit is added into the product mix.
Assume that modularization is even possible, which is yet to be proved, at
least by any of the open-source implementations of which I am aware. Assume
also that, all other things being equal, it is a desirable trait, not just
for the developer, but for the end user. If these are both true (and I think
they are), a product that chooses *not* to implement it would presumably
want to have a really good reason for not doing so. Defoe's reason might be
superior performance (as I understand it), which is quite possible, and
FOP's might be a quicker time-to-market (as I understand it), also quite
possible, at least starting from today.
If *setting* a standard devolves into a religious war, we should probably
abandon the effort. However, I don't know that it needs to. When you think
about it an API for the FOTree, for example, the standard almost writes it
for you.
> going on. So, we're still going in the same general direction
> although I'm still a bit concerned that you based your PDF
> part on the maintenance branch code (that's still the case,
> isn't it?).
FOrayPDF is based on the maintenance branch code, but I am not sure I
understand your point. I assume you are thinking of how to get a PDF-library
created in the new Graphics project? If I understand where you are headed,
you have to either duplicate in HEAD the work that I have done in isolating
it, or you have to duplicate the changes made since FOP forked itself. Since
it is in FOray's interest to have the better PDF library available, I might
do the latter -- it is just a matter of priorities & right now finishing the
modularization is more important (to me). And since PDF is a relatively
discrete part of the system, it may not be too hard to do. If you guys
decide to do the former, having the aXSL APIs in place would be a very
valuable tool in that process. I'll be glad to explain why when you are
ready to look at it, and perhaps I'll have something concrete (about the
abstractions :-) to show you by then as well. I'll be very happy to try to
coordinate this stuff so that we don't duplicate effort -- there has been
and will be too much of that as it is.
Victor Mote
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Posted by Jeremias Maerki <de...@greenmail.ch>.
Ah, now I'm starting to see where this is going. I think this something
extremely difficult to do. To a certain degree it sounds like my
ideas/plans for the XML Graphics project, namely to separate certain
peripheral components (fonts, PDF lib, Graphics2D implementations etc.)
from FOP so efforts can be pooled between projects where easily possible
(i.e. without major religious wars). For example, Peter is quite
interested in the Graphics2D implementations. But going to a level of
detail you hint at (at least that's my impression) will prove really
difficult. You know I'm all for componentization, but you may have too
high hopes here. But I could be wrong. Don't spend too much time
explaining this to me. :-) We'll just see what happens. I will monitor
what's going on. So, we're still going in the same general direction
although I'm still a bit concerned that you based your PDF part on the
maintenance branch code (that's still the case, isn't it?).
Concerning the common end-user API, I'll publish my findings as soon as
they are somewhat "presentable".
Jeremias Maerki
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> from the website I don't quite get the scope of the project.
> That might have to be made clearer. Anyway, I didn't want to
Yes, just as soon as it is totally clear to me :-) Right now, it boils down
to "here are some things that I think could/should be shared, can anybody
think of anything else?"
> talk about it just yet, because it's not ready, but recently
> I started writing a JAXP-like API for XSL-FO processors (I
> called in JAFOP for now). It basically implements the ideas
> we came up with in the API discussion over a year ago. In the
> next few months I will probably need to integrate several
> different FO-processors and want to have a common API for all.
> Especially having a uniform API between FOP maintenance
> branch and HEAD is important to me because I need to get FOP
> 0.20.5 set up for PDF output and I will most probably need
> the RTF output of FOP HEAD quite soon (all in the same VM, of
> course). Also, the fact that we got 4 OS-FO-processors
> screams for a common API so they can be used interchangeably.
I think you are thinking API for the application as a whole. My vision for
aXSL goes quite a bit deeper than that, trying to get a common API for the
modules, IOW breaking the problem down into smaller pieces. My perfect world
right now would have me using FOrayFont with RenderX. (That is not to say
that FOrayFont is as good as RenderX's font handling -- it is not, yet
anyway. But it means that I can get where I need to go more quickly with
FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to
aXSL, making FOray do so would seem to make it more usable to more people.
And it at least gives hope to someone writing a piece that it might be
pluggable with some other pieces.
There was a thread several weeks ago that had to do with how to standardize
extensions between the various applications, and Finn's work on Property
binding was an indirect influence here as well. However, the main thing that
started me down this path was thinking through the possibility of further
modularization within FOray. Right now, for example, FOrayFont is totally
independent of anything that looks like XSL-FO processing. But FOrayPDF is
highly dependent on FOrayFont as are layout, the renderers, etc. It seemed
like a desirable thing to pull out a layer of abstraction that lets FOrayPDF
work, for example, with any other conformant Font system, or vice versa.
Now, fonts and graphics are pretty easy. I can pull out an abstraction for
fonts that has three interfaces, one of which is already written (it may
need to get more complex later), and probably do a similar thing with
graphics. FOTree is much more complex, and AreaTree has complexities for a
different reason.
> Can it be that we had the same idea at the same time again?
> :-) Of course, having standardized validation messages and
> such goes a bit beyond what I imagined, but that's ok.
Actually, I don't envision standardized validation messages, although that
would be OK. (I suppose you could even handle the multi-lingual aspects of
that in a nice way.) I think that the original thread was dealing with how
the exceptions should be thrown, and that *would* be a good thing to
standardize, but different applications might want to handle them
differently.
I would characterize the two ideas as different, but very compatible, and
thinking along the same general lines. What you have done with JAFOP could
easily be a part of aXSL (or vice versa), and I would be glad to have you
participate, when the appropriate time comes.
Victor Mote
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Posted by Jeremias Maerki <de...@greenmail.ch>.
Victor,
from the website I don't quite get the scope of the project. That might
have to be made clearer. Anyway, I didn't want to talk about it just yet,
because it's not ready, but recently I started writing a JAXP-like API
for XSL-FO processors (I called in JAFOP for now). It basically
implements the ideas we came up with in the API discussion over a year
ago. In the next few months I will probably need to integrate several
different FO-processors and want to have a common API for all.
Especially having a uniform API between FOP maintenance branch and HEAD
is important to me because I need to get FOP 0.20.5 set up for PDF
output and I will most probably need the RTF output of FOP HEAD quite
soon (all in the same VM, of course). Also, the fact that we got 4
OS-FO-processors screams for a common API so they can be used
interchangeably.
Can it be that we had the same idea at the same time again? :-) Of
course, having standardized validation messages and such goes a bit
beyond what I imagined, but that's ok.
On 04.11.2004 22:58:39 Victor Mote wrote:
> Finn Bock wrote:
>
> > Do you mean that the 3 different processors should ideally
> > report the same validation errors in the same manner? That
> > can only happen after someone standardize a SAFO API (Simple
> > API for FO parsing). Until then all implementation will throw
> > different exceptions, which is fine by me.
>
> I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
> already taken, but at the time I registered the axsl.org domain, and I
> finally went ahead yesterday and opened up a SourceForge project for it.
> There isn't much content there now, and I doubt that anyone wants to spend
> much time on it ATM, but we have a place to talk about such things for those
> who are interested -- I think Joerg at least will appreciate it being
> somewhere else, and I know there are others who are not interested as well.
> It deals with more than just parsing and exceptions, but those are (or could
> be) parts of it. Here is the website:
> www.aXSL.org
>
> If FOP is interested, you are welcome to send a delegate, who will
> automatically become a committer. Also, Peter West is welcome to be a
> committer -- if we can accommodate his design, we'll sure try. I'll
> eventually invite the commercial developers too, if it looks like there is
> anything here that helps.
Jeremias Maerki
aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Posted by Victor Mote <vi...@outfitr.com>.
Finn Bock wrote:
> Do you mean that the 3 different processors should ideally
> report the same validation errors in the same manner? That
> can only happen after someone standardize a SAFO API (Simple
> API for FO parsing). Until then all implementation will throw
> different exceptions, which is fine by me.
I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
already taken, but at the time I registered the axsl.org domain, and I
finally went ahead yesterday and opened up a SourceForge project for it.
There isn't much content there now, and I doubt that anyone wants to spend
much time on it ATM, but we have a place to talk about such things for those
who are interested -- I think Joerg at least will appreciate it being
somewhere else, and I know there are others who are not interested as well.
It deals with more than just parsing and exceptions, but those are (or could
be) parts of it. Here is the website:
www.aXSL.org
If FOP is interested, you are welcome to send a delegate, who will
automatically become a committer. Also, Peter West is welcome to be a
committer -- if we can accommodate his design, we'll sure try. I'll
eventually invite the commercial developers too, if it looks like there is
anything here that helps.
Victor Mote
Exceptions. (Was: AreaFactory patch)
Posted by Finn Bock <bc...@worldonline.dk>.
[Peter]
> On the topic of exceptions, and now that it's all over...
>
> I was puzzled by this discussion. Would anyone expect that Defoe would
> subclass SAXException for document validation errors?
That is your choice. Surely exceptions that occured during SAX event
handling (eg startElement) should be handled, either by wrapping the
exception in a SAXException, or by passing SAXExeption subclasses along
or by throwing some kind of RuntimeException (did I miss another
option?). I don't think exception handling by
e.printStackTrace();
is a long term solution.
> If not (it doesn't), why not?
AFAIK, there is no well defined API to XSL:FO parsing, so everybody will
do it differently.
> And if someone was inclined to write an FO processor
> using a DOM front-end, would you expect validation errors to throw
> subclasses of SAXException?
Ofcourse not.
> The same fo file, with the same errors,
> could be processed by three different processors, using three different
> parsing methodologies, and the same validation errors would encountered.
Do you mean that the 3 different processors should ideally report the
same validation errors in the same manner? That can only happen after
someone standardize a SAFO API (Simple API for FO parsing). Until then
all implementation will throw different exceptions, which is fine by me.
> (OK, you can classify at least two categories of validation error, but I
> think the argument still applies.)
>
> SAX != XML parsing, let alone document validation.
True, but FOP heavily depends on SAX.
regards,
finn
RE: Exceptions (was: AreaFactory patch)
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Peter B. West [mailto:lists@pbw.id.au]
> Would anyone expect that Defoe would
> subclass SAXException for document validation errors? If not (it
> doesn't), why not?
Yes, if you use a SAX parser, why not? My point is that at the top-level, no
SAXExceptions should be thrown (or a subclass from SAXException) since these
could be caught by a higher-level catch-block for SAXExceptions, leading to
all sorts of unpleasant surprises or incomprehensible error messages. Could
be that the Exception really has its roots in the SAX parser, but FOP/Defoe
isn't purely about SAX --FOP just happens to use SAX to parse the XML.
There's also at least layout and rendering where errors can occur (esp. if
we strive for pluggable layoutmanagers or renderers --could easily lead to
misconfigurations that might surface only when the app actually tries to
layout/render something, so when the XML parsing is already well under
way...)
What FOP or Defoe does within the context of their own packag(es) doesn't
really matter so long as it's properly documented in the JavaDocs, but for
an end-user --whether command-line or embedded-- the error should IMO
definitely indicate that the error comes from within FOP/Defoe, which is not
the case when you just hand off a SAXException or one of its subclasses.
(Same goes for FileNotFoundExceptions... Very tempting to use this for all
cases where 'a file cannot be found', but in case we use it in FOP, it
should come out wrapped in a FOPException --XSL processors would also report
this as i.e. a TransformerException, caused by a lower-level FNFE. Users who
know their way in Java would associate an FNFE with particular types of
classes and operations that clearly indicate that a reference to a File is
created. With FOP or Defoe the creation of these file-references is shielded
from the end-users, so it would turn out to be confusing to throw FNFEs at
them...)
> And if someone was inclined to write an FO processor
> using a DOM front-end, would you expect validation errors to throw
> subclasses of SAXException?
Very, very good point indeed! The answer, of course, is no. Should IMO be at
least a form of DOMException.
Greetz,
Andreas
Re: AreaFactory patch
Posted by "Peter B. West" <li...@pbw.id.au>.
Andreas L. Delmelle wrote:
>
> All right, all right, maybe I'll just 'agree to disagree' in this case ;-)
> --mind you, *not* WRT to Exceptions, though... I declined to further the
> debate, but I'd much rather see GM read Sun's APIDoc for
> java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that
> FOP has no business throwing an 'IllegalArgumentException' or a
> 'FileNotFoundException', no matter how well the name seems to fit the
> error... (esp. the first, since it subclasses RuntimeException = unchecked)
> [*]
On the topic of exceptions, and now that it's all over...
I was puzzled by this discussion. Would anyone expect that Defoe would
subclass SAXException for document validation errors? If not (it
doesn't), why not? And if someone was inclined to write an FO processor
using a DOM front-end, would you expect validation errors to throw
subclasses of SAXException? The same fo file, with the same errors,
could be processed by three different processors, using three different
parsing methodologies, and the same validation errors would encountered.
(OK, you can classify at least two categories of validation error, but I
think the argument still applies.)
SAX != XML parsing, let alone document validation.
Peter
RE: AreaFactory patch
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Chris Bowditch [mailto:bowditch_chris@hotmail.com]
>
> Glen Mazza wrote:
>
> > Personally speaking, I am much more amenable to adding
> > some complexity (LM Makers, for example, or opening up
> > our validation) if it helps out Finn's work, because
> > of the sheer weight of contributions he adds to Fop.
> > (We slow him down, we slow down Fop.)
<snip />
> I'm definitely in agreement with you on this one Glen. Lets keep
> Layout simple whilst its still unfinished.
> Pluggable LMs can be added once we have an
> initial release.
Hi fellas,
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
hinder that.
All we heard up to here is a few vague concerns about so-called increased
complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
for chrissake! It doesn't bite... or does it? Anyone?
All right, all right, maybe I'll just 'agree to disagree' in this case ;-)
--mind you, *not* WRT to Exceptions, though... I declined to further the
debate, but I'd much rather see GM read Sun's APIDoc for
java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that
FOP has no business throwing an 'IllegalArgumentException' or a
'FileNotFoundException', no matter how well the name seems to fit the
error... (esp. the first, since it subclasses RuntimeException = unchecked)
[*]
So, Tibor, can you post your patch on Bugzilla? Fine by me to leave all as
it is now... and maybe when the time is ripe, we'll use it.
Thanks very much for the contribution. I just hope this piece of sound logic
doesn't go to waste.
Greetz,
Andreas
[*] as a slightly more realistic example:
try {
...
someObject.processFile();
...
fop.run();
...
} catch( FNFE e ) {
// this will catch FNFEs regardless of which
// of the two objects it gets thrown by.
// sorting out which one here can prove to be
// quite messy and painful...
// now, if only one of the two was 'behaving'...
}
Re: AreaFactory patch
Posted by Chris Bowditch <bo...@hotmail.com>.
Glen Mazza wrote:
<snip/>
> Personally speaking, I am much more amenable to adding
> some complexity (LM Makers, for example, or opening up
> our validation) if it helps out Finn's work, because
> of the sheer weight of contributions he adds to Fop.
> (We slow him down, we slow down Fop.) Making these
> changes for someone who isn't submitting
> contributions, however, is less of a concern for me.
> If a user is going to propose a change that would slow
> down system development, we should be getting some
> work to compensate for it, at least during this time
> while we are still building the system.
>
> My inclination is to have him place this patch in
> Bugzilla, and let's wait until we have others
> requesting it (vs. those who would rather have LM's
> pluggable.) In the meantime, I think it would be best
> for everyone to keep layout as simple as we can until
> it is done. I am open to others' opinions however.
I'm definitely in agreement with you on this one Glen. Lets keep Layout simple
whilst its still unfinished. Pluggable LMs can be added once we have an
initial release.
Chris
Re: AreaFactory patch
Posted by Tibor Vyletel <ti...@centrum.sk>.
Glen,
pluggable LMs would be great too. My proposal to pluginate areas originates
in the will to solve (my) problem as easy as possible. Might sound selfish,
however it's not so bad coding tactics, is it? Anyway, I am happy that I
have started this discussion. FOP's rendering phase can be implemented
according to developer's request outside the FOP itself. The layout phase is
a black box, at the moment. Pluggable LMs and/or Areas would change the
situation.
As to the requests of external fop-users: I appreciate the possibility to
use someone's else code which does whole XSL-FO layout for me and I am
prepared to develop my requests (and other features, too) and contribute
them in this newsgroup afterwards. I think, that only contributions we can
agree on before I start to implement them will be use of some use for the
FOP itself and for me too.
If we can agree on the interface for pluggable LMs, I can start to implement
this refactoring right away ...
Best regards,
Tibor Vyletel (not Tybor ;-)
ICQ# 79458455
----- Original Message -----
From: "Glen Mazza" <gr...@yahoo.com>
To: <fo...@xml.apache.org>
Sent: Monday, November 01, 2004 3:02 AM
Subject: Re: AreaFactory patch
> I'd rather we have pluggable LayoutManagers -- 1.0's
> emphasis and I think our previous agreement with
> Finn/Simon -- than have pluggable Area objects (where
> much of layout used to be in 0.20.5.) I'm not sure if
> Fop can realistically handle both at this time.
>
> As for complexity, in our LM's, with Tybor's proposed
> change, instead of just:
> curBlockArea = new Block();
>
> we would now have:
> curBlockArea = (Block) fobj.getUserAgent().
> getAreaFactory().create(Block.class, fobj, this);
>
> instead of:
> viewportBlockArea = new BlockViewport();
>
> we would now have:
> viewportBlockArea = (BlockViewport)
> fobj.getUserAgent() .getAreaFactory().create
> (BlockViewport.class, fobj, this);
>
> over and over again. The question here seems to be:
> should we add this additional complexity to our system
> *now* so Tybor doesn't need to rewrite code every week
> he does a cvs update? Or have him tolerate it until
> 1.0 is out (when presumably, he can rely on a
> production release and not need to update every week.)
>
>
> Personally speaking, I am much more amenable to adding
> some complexity (LM Makers, for example, or opening up
> our validation) if it helps out Finn's work, because
> of the sheer weight of contributions he adds to Fop.
> (We slow him down, we slow down Fop.) Making these
> changes for someone who isn't submitting
> contributions, however, is less of a concern for me.
> If a user is going to propose a change that would slow
> down system development, we should be getting some
> work to compensate for it, at least during this time
> while we are still building the system.
>
> My inclination is to have him place this patch in
> Bugzilla, and let's wait until we have others
> requesting it (vs. those who would rather have LM's
> pluggable.) In the meantime, I think it would be best
> for everyone to keep layout as simple as we can until
> it is done. I am open to others' opinions however.
>
> Glen
>
>
> --- Tibor Vyletel <ti...@centrum.sk> wrote:
>
> > Hello Fopsters,
> >
> > I have attached first phase (a working example) of
> > the refactoring I was
> > talking about in my previous mails. Please let me
> > know, if this change is
> > acceptable for you. If it is, I will finish it
> > afterwards.
> >
>
>