gzilla/show_bug.cgi?id=29025
Document/LayoutStrategy consolidation
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
Simon Pepping wrote:
Note in this respect the comment in
LayoutStrategy.java:
/** Useful only for allowing subclasses of AddLMVisitor to be set by those
extending FOP **/
right above
private AddLMVisitor addLMVisitor = null;
I think you should copy that comment to Document.java as well.
On Sun, May 16, 2004 at 07:10:50PM -, [EMAIL PROTECTED] wrote:
> Team,
>
> The following patch incorporates the (rather simple) LayoutStrategy code into
> the apps.Document class, and does away with LayoutStrategy and
> LayoutManagerLS.java. Implementation of multiple la
gzilla/show_bug.cgi?id=29025
Document/LayoutStrategy consolidation
--- Additional Comments From [EMAIL PROTECTED] 2004-05-16 19:12 ---
Created an attachment (id=11572)
patch file
gzilla/show_bug.cgi?id=29025
Document/LayoutStrategy consolidation
Summary: Document/LayoutStrategy consolidation
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority:
Glen Mazza wrote:
> Ideally, that would be mostly it. My current
> design-thinking is that once flow of control leaves
> the apps package, it does not return until has a full
> document finished.
I think we are on the same page here, or at least I see no conflict. I don't
think of the control cl
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> Hmmm. I'm not sure how to interpret the silence. I'm
> going to press on with
> my proposals unless I get some sort of substantive
> reply.
>
> Victor Mote
>
Victor,
I apologize for the silence--I did read your email on
Sunday and more thoroughly
Victor Mote wrote:
> Because we are such a small group, I am hoping to get unanimity on all of
> the points. If I have addressed your concerns with the above
> clarifications,
> please consider changing the -1 votes to a zero (or better). If
> anybody has
> serious reservations, I need to think ab
only pieces that need to be moved are those that
control the flow between the various modules. So, for example, I don't want
the fo module deciding to fire off a layout manager, which is what we have
now. I want the flow of control to return back to Control (for now, this is
Driver), which w
But I *highly* encourage better judgments, i.e. the
other committers, to weigh in on this.
> 3. Create an AbstractLayoutStrategy class which will
> encapsulate the
> interaction between Control and Layout. Make our
> redesign layout subclass
> this. (This may actually get done before ite
On 21.07.2003 16:48:30 Victor Mote wrote:
> Fellow FOP developers:
>
> The thread I have most been wanting to work on (and that which I think is
> most important to this project right now) is that of cleaning up the lines
> between our various modules, and getting LayoutStrategy w
Fellow FOP developers:
The thread I have most been wanting to work on (and that which I think is
most important to this project right now) is that of cleaning up the lines
between our various modules, and getting LayoutStrategy working, so that we
can try to integrate our one working
12 matches
Mail list logo
