Glen Mazza wrote:
> --- Victor Mote <[EMAIL PROTECTED]> wrote:
> >
> > If I'm going to give up encapsulation or Separation
> > of Concerns, or whatever
> > you want to call it, what do I get in return?
> >
>
> IMO you're not "giving up" SoC, you're gaining it:
>
> The
> "manager<-->A<-->B<-->C<-->
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> If I'm going to give up encapsulation or Separation
> of Concerns, or whatever
> you want to call it, what do I get in return?
>
IMO you're not "giving up" SoC, you're gaining it:
The
"manager<-->A<-->B<-->C<-->D<-->customer model"
keeps the busin
Glen Mazza wrote:
> Not to belabor the point, but all of the above is
> business logic, which can be supported by either
> model. A computer program is deterministic--that
> coded decision to send half to P and half to Q
> (instead of B) based on various coded circumstances
> can be placed within
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> >
> > Relations in controller-class approach:
> > manager<-->A, manager<-->B, manager<-->C,
> > manager<-->D,
> > manager<-->customer
> >
> > In pipeline approach (theoretical, may not work in
> > FOP's case):
> > manager<-->A<-->B<-->C<-->D<-->customer
Glen Mazza wrote:
> --- Victor Mote <[EMAIL PROTECTED]> wrote:
> > Before starting down this path, I tried pretty hard
> > to think of a use case
> > where it is beneficial *not* to have the FO Tree
> > isolated, and could not
> > think of one.
>
> Well, when taken to 100%, the duplication of clas
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> Conclusion: We have three active committers right
> now, one positive, one
> negative, one lukewarm, so I will abandon the
> enforcement idea.
>
> Victor Mote
>
I don't see anyone modifying the new Apps/FO code
anyway--for backwards compatibility,
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Before starting down this path, I tried pretty hard
> to think of a use case
> where it is beneficial *not* to have the FO Tree
> isolated, and could not
> think of one.
Well, when taken to 100%, the duplication of classes
(FOPException) and functional
J.Pietschmann wrote:
> Victor Mote wrote:
> [interesting stuff]
> > Package1 2 3a 3b 4
> > tools| | | x | | |
> Should be 4 (apps) module, I think.
>
> > util | x | | | | |
> Uh, I never liked that.
>
> > Here is my +1.
> +0
>
> > Now in the table above, the "comm
Glen Mazza wrote:
> --- Victor Mote <[EMAIL PROTECTED]> wrote:
> > So I propose first that
> > keeping these five modules separate is a desirable
> > thing, and should be
> > enforced by our build process (I'll write the code).
> >
> > Here is my +1.
> >
>
> I'm -1. The decision for changing FOP
Victor Mote wrote:
[interesting stuff]
Package1 2 3a 3b 4
tools| | | x | | |
Should be 4 (apps) module, I think.
util | x | | | | |
Uh, I never liked that.
Here is my +1.
+0
Now in the table above, the "common" package does not exist, but represents
five classes
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> So I propose first that
> keeping these five modules separate is a desirable
> thing, and should be
> enforced by our build process (I'll write the code).
>
> Here is my +1.
>
I'm -1. The decision for changing FOP architecture is
based on votes--not
Victor Mote wrote:
> If we come to general agreement that subdiving FOP this way is good, I'll
^
Sorry, this word should be "subdividing".
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROT
FOP Developers:
The FO Tree isolation work is complete, with the exception of a few classes
that I would like to move around, and for which I would welcome input. I
started this for the purpose of making sure that layout and FO Tree were
isolated, but I actually ended up isolating FO Tree from eve
13 matches
Mail list logo
