> I still
> cannot see the "sense" with cross-inheriting between layers - pfc:
> pfc_w_master -> pfe: w_master -> pfc: pfc_w_sheet -> pfe: w_sheet.
Here's an example. Let's say I want all my windows to be purple. A good
place to set this is in w_master. I don't need to modify the base pfc layer
and all my other windows become purple. (or maybe I want to track when a
window is opened so I can see usage patterns within my app, I do this in the
PFC_OPEN event of W_MASTER and all the rest have it).
Let's say I want to add a new datawindow service function, a new of_saveAS()
that will export column header names, computed columns and only visible
columns (something that 5.0's .saveAs doesn't handle well). I have this:
pfc_n_dw_srv --> n_dw_srv --> pfc_n_dw_srv_sort --> n_dw_srv_sort
pfc_n_dw_srv --> n_dw_srv --> pfc_n_dw_srv_filter --> n_dw_srv_filter
pfc_n_dw_srv --> n_dw_srv --> pfc_n_dw_srv_linkage --> n_dw_srv_linkage
(and so on)
I think everyone has no argument with the rule "Never modify base PFC code
or else you'll have trouble upgrading".
The perfect place for my new function is in n_dw_srv, then all the DW
services can see it. So if I am using the sort service, I do not need to
instantiate another service just to get the new of_saveAS(), I can ask the
sort service to do it, likewise, if I am using filter but not sort, I can
ask dw.inv_filter...
If I did not have that PFE layer, I would need to have this function
everywhere, or create a new service.
Here's another example. Let's say you only want SORT capability if there
are less than 10,000 rows (for performance reasons) unless the user class is
"developer". Likewise, you want to allow look ahead typing on datawindows
with less than 10,000 rows unless the user class is "developer". I can put
a function on u_dw called of_tooLargeForNonDevelopers() that checks the row
count and user class. Then, in the n_dw_srt_sort object, I can intercept
the of_sort call and check adw_requestor.of_tooLargeForNonDevelopers() and
act accordingly and in the lookahead typing service, I can intercept the
call and also check adw_requestor.of_tooLargeForNonDevelopers(). It's a
silly example but it shows why having the services refer to u_dw (as opposed
to pfc_u_dw) is beneficial. I wrote my function in one place (u_dw) and it
is now available to anyone who needs it.
I could probably come up with more examples, but hopefully that illustrates
my point good enough. I am not sure how you could achieve any of the above
solutions with as little code as the PFE layer and the "cross-inherting"
allows you.
D
----- Original Message -----
From: Bruce Nordstrand <[EMAIL PROTECTED]>
To: 'Gordon A. Dickens, Jr.' <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 20, 1999 7:44 AM
Subject: RE: PFCSIG PFC Architecture
> Gordon
>
> Firstly, the source code is available for all of the "utilities" shipped
> with PB 6.0 - go to the Sybase SBN site and register for it, it's called
> Enterprise Application Studio 3.0 sample codes.
>
> Secondly, I wasn't suggesting that the foundation layer be modified, but
> only the pieces actually used are inherited from and modified. I still
> cannot see the "sense" with cross-inheriting between layers - pfc:
> pfc_w_master -> pfe: w_master -> pfc: pfc_w_sheet -> pfe: w_sheet. To
> me an "extension" layer extends a base layer, not cross in and out of
> both layers. PFC architecture basically spreads _1_ layer between 10
> libraries. Other frameworks I have seen have specific division between
> layers and do not do what PFC does in the example above. I mean, doesn't
> anybody mind shipping 10+ libraries minimum for a PFC based app? I have
> also seen a couple of apps where the originator has modified the PFC
> layer to remove these cross-dependencies.
>
> Regards
>
> +-----------------------------------------------------------------------
> ----------------------------------+
> Bruce Nordstrand
>
> KSL Consulting Pty Ltd
> P.O. Box 4852, North Rocks, NSW 2151, Australia
>
> Phone: +61 2 9873-6256 Fax: +61 2 9873-6216
> Email: [EMAIL PROTECTED] Web: http://www.ksl.com.au
> +-----------------------------------------------------------------------
> ----------------------------------+
> PCDocs/Fulcrum <http://www.pcdocs.com/> Alliance Network
> Member
>
>
>
> > -----Original Message-----
> > From: Gordon A. Dickens, Jr. [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, 20 August 1999 10:28 pm
> > To: Bruce Nordstrand; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: PFCSIG PFC Architecture
> >
> > In reference to APU I don't understand what you are referring to.
> > Since the
> > source code is unavailable for the APU, how do we know? Also, it is a
> > utility app, and I would not necessarily write a utility app using
> > PFC.
> >
> > The way the PFC/PFE layers are defined makes sense because it provides
> > customization layers for all classes. The problems would be magnified
> > exponentially if there were no PFE customization layers. Could you
> > imagine
> > the support calls after someone modified the PFC classes? Also,
> > people
> > would complain "they don't even use their own pfc classes in the pfc".
> >
> > In reference to independent components, this is true about class
> > libraries
> > but not necessarily about frameworks. One does not need to use any
> > extender
> > utilities, just add the PFC and PFE layers to your application and
> > provide
> > any customization at the PFE layer.
> >
> > HTH,
> > Gordon Dickens
> > SCPPD, SCPPI
> > Technical Director
> > Touchstone Systems, Inc.
> > www.touchstone-systems.com
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> > Of
> > Bruce Nordstrand
> > Sent: Friday, August 20, 1999 3:40 AM
> > To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> > Subject: PFCSIG PFC Architecture
> >
> >
> > Hi All
> >
> > This is dangerous as George Haines' mail will send out a zillion
> > messages (PBPFC) but here goes....
> >
> > Does anyone have any comments/can throw any light on the reasoning
> > behind the PFC architecture. I find it strange (and annoying) that
> > the
> > main pfc libraries refer to objects in the pfe libraries, thereby
> > forcing the use to the extension layer. What really irks me is that
> > PS/Sybase themselves don't use this architecture! - just look at some
> > of
> > the utilities they supply (APU etc). They have a pfc layer equivilent
> > to the pfe layer and an app layer.
> >
> > I thought class librarie/frameworks were supposed to be layered in
> > such
> > a way that you could stick bits inbetween or leave out all together if
> > you wanted too without having to resort to Extender Utilities.
> >
> > I'll be interested in any comments you have
> >
> > Regards
> > +---------------------------------------------------------------------
> > --
> > ----------------------------------+
> > Bruce Nordstrand
> >
> > KSL Consulting Pty Ltd
> > P.O. Box 4852, North Rocks, NSW 2151, Australia
> >
> > Phone: +61 2 9873-6256 Fax: +61 2 9873-6216
> > Email: [EMAIL PROTECTED] Web: http://www.ksl.com.au
> > +---------------------------------------------------------------------
> > --
> > ----------------------------------+
> > PCDocs/Fulcrum <http://www.pcdocs.com/> Alliance Network
> > Member
> >
> >
> >
> > > [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]
>
> [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]
