I would have thought that if both pfc & pfe are enterprise-common, there is no 
advantage
to putting bug fixes in the pfc while thereare advantages to putting them in pfe -- 
they
are all in one place, and when the next upgrade comes along, they can more easily be
scotched. If the architecture is pfc -- pfe -- commonPbl then it's even easier; you 
just
throw the old pfe away.

And since there's no question of removing the pfe layer, what's the relevance of how 
full
or empty it is?

(When I find myself in the majority, it is time to pause and think. -- Mark Twain)

Peter

---------------

Sharon Buntz wrote:

> Peter,
>
> I agree that "different folks have different purposes"; yes, everything
> "just depends" ~ That's my motto...  JUST so long as there is a METHod to
> someone's MADness <s>...
>
> Now, having said that, in this case, in my opinion, it would seem more
> appropriate to perphaps put "bug fixes" in say the corporate layer, where
> every application could take advantage of the changes, thereby also
> avoiding duplication of effort (when we know that humans are prone to eroor
> <g>).  So then what would be left to use the PFE layer for?  Seems like
> extra baggage to me.
>
> In addition, for some "bug fixes", say where there is already a newer PFC
> release out that has a particular fix (and your company is not yet ready
> for a full-fledged migration), I even condone making the "fix" straight to
> the PFC layer itself.
>
> Furthermore, far be it from me to eevverrr question the BORG <g>...
> Resistance is futile, Peter, you will be assimilated <bg>
>
> Even so, "To each his own!" <sb>
>
> Cheers,
> ~Sharon
> --
> Sharon Weinstrom Buntz      | mailto:[EMAIL PROTECTED]
> Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
>
> Peter Brawley wrote:
> >
> > Sharon, different folks have different purposes. No "whole purpose" is valid for
> > everyone. On matters like this "good practice" and "bad practice" depend on the
> > approach you've taken. For us pfc/pfe generality, pbl/pbd sharing and inter-version
> > migration simplicity are much more important than the convenience of putting
> > app-specific customisations in the pfe layer. We put _only_ bug fixes in the pfe
> > layer; we like this approach both for the pfc -- corpPbl -- pfe architecture and 
>for
> > the pfc -- pfe -- customPbl architecture.
> >
> > Peter Brawley
> >
> > -----------
> >
> > Sharon Buntz wrote:
> >
> > > Al,
> > >
> > > > our practice is to freeze the PFE among applications
> > >
> > > But that defeats the whole purpose of creating a new, extra, corporate
> > > "PFD" level in the first place!  When you go through the extra effort and
> > > all of adding the extra PFD layer, the PFE level is then intended to be
> > > application-specific as pictured here
> > >
> > > http://www.pfcguide.com/pfcmag/extension_page04.asp#Adding_an_Additional
> > > layer
> > > (See Figure 14 there and the "Limitations" there as well)
> > >
> > > Otherwise, you would simply opt to use the PFE layer directly as your
> > > corporate (framework) level as pictured here
> > >
> > > http://www.pfcguide.com/pfcmag/extension_page03.asp#PFE_as_a_Framework_Layer
> > >
> > > Please realize that all it takes is one, single extra instance variable or
> > > one, single extra function in the PFE (application) level...  And then you
> > > enter into what Steve Benfield calls the "GPF-Tug-Of-War" (for your
> > > corporate 3-layer approach) !
> > >
> > > Don't get me wrong here...  The "GPF-Tug-Of-War" is not the enemy, it is a
> > > fact of a PowerBuilder programmer's regeneration life.  So adding instance
> > > variables or functions in the PFE layer is not considered "bad practice",
> > > but rather it is the normal or expected practice.  The bad practice would
> > > be to not realize the "GPF-Tug-Of-War" possibilities and to not take the
> > > necessary precautions ;-)
> > >
> > > PFCly Yours,
> > > Have fun,
> > > ~Sharon
> > > --
> > > Sharon Weinstrom Buntz      | mailto:[EMAIL PROTECTED]
> > > Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
> > >
> > > Al Malin wrote:
> > > >
> > > > Russ,
> > > >
> > > > What you say is absolutely true and we are in total agreement.  One definately
> > > > needs to understand your point that changing the PFE could indirectly change
> > > > the PFC as well.
> > > >
> > > > But I stand by my statement.  Yes, I can share the PBDs since our practice is
> > > > to freeze the PFE among applications.  We freeze the PFE because when you
> > > > change it for an application then the PFE becomes application-specific and is
> > > > no longer enterprise-general.
> > > >
> > > > (Needles to say, never ever think about changing the PFC without Powersoft's
> > > > blessing and/or you know what you are doing and are prepared for future
> > > > headaches.)
> > > >
> > > > Regards,
> > > > Al Malin
> > > >
> > > > "Hensel, Russ" wrote:
> > > >
> > > > > You can share the pbl as long as you recompile for each individual app.
> > > > > You cannot share the pbd's.
> > > > >
> > > > > Why?
> > > > >
> > > > > Because of the way that the pfc pfe are linked to each other
> > > > > changes in the pfe layer can move up into the pfc layer.
> > > > > ( look at w_pfc_master -> w_master -> w_pfc_sheet -> w_sheet and the
> > > > > like )
> > > > >
> > > > > So if there are no changes that can "climb" back to the pfe and pfc
> > > > > layers it may work, otherwise it will not.
> > > > >
> > > > > We keep one master copy of the pbl's as source, but always regenerate
> > > > > them into the application that they will run with.
> > > > >
> > > > >         russ
> > > > >
> > > > > -----Original Message-----
> > > > > From: Al Malin [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Friday, July 09, 1999 9:53 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: PFCSIG re: PFC6.0/Executable Creation -
> > > > > ApplicationTerminalt ed ... Unresolveable external n_msg when linking
> > > > > reference atline 3 in c reate eventof object a_pts
> > > > >
> > > > > We share PB6.5 PFC/PFE among applications too and we haven't had any
> > > > > problems.  We
> > > > > believe there is nothing in the architecture that prohibits this.
> > > > >
> > > > > Al Malin,
> > > > > Whirlpool Corp
> > > > >
> > > > > "BRIGHT,NIGEL" wrote:
> > > > >
> > > > > > Sharon,
> > > > > >
> > > > > > >.  Seems like you are sharing your PFC/kme objects with another
> > > > > application
> > > > > > >(since you have a corporate level).  If so, do you realize that cannot
> > > > > > >share the PFC/kme/PFE PBDs between the two applications?
> > > > > >
> > > > > > Do you have any more detail on why you can`t do this.
> > > > > > We have a number of apps sharing our PFC/CORP/PFE PBDs which have been
> > > > > > working fine for several months.
> > > > > >
> > > > > > Robert,
> > > > > >
> > > > > > > Hi PBers ....
> > > > > > > I just started getting the following message and am at a loss at what's
> > > > > > the
> > > > > > > cause or how to go about debuggin ?? I created the executable
> > > > > successfully
> > > > > > a
> > > > > > > few times during the past few weeks and the only changes have been to
> > > > > > > application specific (PBLs)functionality...
> > > > > > >
> > > > > > > Any Ideas??
> > > > > > >
> > > > > > > Click on a_pts.exe
> > > > > > > Application Terminated
> > > > > > > Unresolveable external n_msg when linking reference at line 3 in create
> > > > > > > event of object a_pts
> > > > > >
> > > > > > Not knowing the specific dependencies which might be involved; I assume
> > > > > you
> > > > > > tried doing a full rebuild of your app?  And that the PBD libraries you
> > > > > are
> > > > > > running against are up to date?
> > > > > >
> > > > > > Regards,
> > > > > > Nigel
> > > > > >

> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE:   help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]

Reply via email to