I actually have a big problem with this notion of corporate layer.
It seems to assume that all applications in a company are alike in some
functional way.
It does not work that way where I have been. In my current company we have
2 groups
using 2 different class libaries. Madness you may think. But not so.
One application has a complicated security scheme which depends upon the
users data relationship
to a given member. It also does a lot of update, and uses pessimistic
locking.
The other application is a reporting application with a fairly simple
security system and
no locking.
For the reporting application to use all the stuff in the first application
would be madness.
If you sperate out the stuff that they have in common, the corporate layer
is just about 0.
Just another opinion.
Russ
-----Original Message-----
From: Peter Brawley [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 09, 1999 11:07 PM
To: Sharon Buntz
Cc: [EMAIL PROTECTED]
Subject: Re: PFCSIG PFC6.0/Executable Creation - ApplicationTerminalt ed
... Unresolveable external n_msg when linking reference atline 3 in
create eventof object a_pts
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]
> [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]
