I need some suggestion/advice from you guys. I am starting to build a water utility system, One question that sinks in my mind, will it be worth it to use PFC? Thank you in advance!
I need some suggestion/advice from you guys. I am starting to build a water utility system, One question that sinks in my mind, will it be worth it to use PFC? Thank you in advance!
I know I'm late,
but is there any advantage to use powerbuilder if it is new app which can have clients app desktop/web/mobile to Powerbuiilder?
I do not mean this bad, I have to maintain some apps in PB after I used to build C# apps and I try to move from PB as soon as I can.
Now days find someone who wants to use PB is hard and I get that.
So is there any things why to use PB for new projects?
A.
To anyone who is using the PFC classes for pb 2019:
Bruce has updated (today) the downloadable ZIP file with the latest changes.
The changes were in "ws_objects" but not yet in the ZIP.
These changes mean that - if you rely on the PBDOM included in this version of PFC - these classes will work only for PB 2019 R3.
Personally I don't agree/understand why the PBDOM has to be included in the pfcs because any time Appeon does an update, someone has to remember to update the PFCs.
Probably someone made a dependency on them somewhere and therefore included them.
Just remember, if you use any 2019 version prior to R3, you'll have to edit the pbdom objects and change "pbdom.pbx" to "pbdom190.pbx".
regards
Hi Olan;
FWIW: I just got the latest Visual Expert 2021 from Novalys (thank you Christophe) and then ran the new VE2021's Security & Vulnerability Analysis feature on both the STD and PFC frameworks. This is the first time that I have seen what VE flags in this type of analysis however, I have not had the time yet to analyze the what / how / why / etc of what it flags. I thought though that not only was this an interesting new VE feature but a good test for a comparison of this analysis between the two frameworks for (PB2019R2/R3). I have attached the output of both framework's S&V report to this post (in PDF form).
What is first striking though is the overall numbers in key areas, such as:
Audit Area | STD | PFC |
Bugs | 9 | 25 |
Vulnerabilities | 11 | 7 |
Maintainability | 85.2% | 76.9% |
Minor Issues | 10,894 | 5,580 |
Major Issues | 3,130 | 5,728 |
Critical Issues | 634 | 1,389 |
What I am going to do now is look at the latest STD 2021 R1 Framework release and start to address the critical and major issues along with the bugs and vulnerabilities 1st (of course) going forward. The key being the clean-up of the STD frameworks to best optimize the key areas listed above where I can.
I need to redo a lot of the STD framework going forward from PB2019R3 to PB2021 anyway because it currently contains support for the PowerServer 2020 product that includes support for Appeon Web and Appeon Mobile applications. These features will not be present in the PB/PS2021 release. So this Web/Mobile code can now be deprecated and refactored out of the framework (making it even smaller and faster than today). I also plan to do this in successive STD framework releases bit by bit from the PB/PS2021 GA release version of the framework over the next year into 2022 - while adding support for PB2019R3's new PowerClient (already some there) feature and PowerServer 2021's Cloud App feature. So there's my roadmap! ;-) HTH
For those interested in this new S&V VE feature ... check out the latest release here:
Regards ... Chris
My 2¢ worth:
Of all the frameworks I've seen out there, Chris' Pollach STD is the one most suitable for PowerBuilder apps, especially if you are considering web deployment. Every other framework has been adapted to fit the PB/web world.
The dotNet is a good example of that: it's perfect for web deployment but absolutely was not designed to work with PowerBuilder. The dotNet framework is not one with which I am familiar, but as per Armeed it SOUNDS like that would be my #2 choice.
All frameworks take some time to learn - that's the price for having pre-built-in functionality that you don't have to code. Overall, it's faster to learn how to use someone else's correct and working functions than it is to code your own.
Finally, if you decide NOT to use a framework, you can still steal, I mean borrow, code from the existing ones. Chris's STD and the free PFC have lots of great stuff in them.
Later -
Olan
Is your water utility system going to be developed in pure (classic) PowerBuilder, in PowerServer, SnapDevelop, etc.?
In Powerbuilder but planning to have a web based interface (long term goal)
Are you going to separate your business logic from the GUI?
Yes, separate.
Are you going to deploy 32-bit or 64-bit?
It will be deployed in 64 bit environment.
What are the project constraints (number of developers, project duration, RDBMS vendor, etc.)?
Currently, I have to do it alone but we're planning to add one developer. Since Powerbuilder developer is hard to come by.
I am using SQL Server 2016 (stored procedures)
What is your (and/or your team's) familiarity with the PFC?
In a scale of 1 to 10. My familiarity with PFC is at 7.
Hi John, like many others: It depends. PFC is really a UI front-end framework. Architected as you would mid 1990s.
PFC calls itself services based design (EX: dozen different DataWindow services). Today the common term for this is composition - and composition is favored over inheritance. PFC probably has more inheritance in its design that you often see in brand new frameworks for web apps, .NET, etc.
PFC or STD or any other framework for the front-end are excellent choices - when front-end is PowerScript based. But you have to consider how you architect your app's interfaces to other systems. Do you want to call REST/SOAP/gRPC or do you want to import/export data directly from databases? DO you call many IOT-based systems having individual APIs using all sorts of technologies?
In early to mid 1990s I designed several "custom-framework-in-a-week" for grow-as-you-need purposes. Philosophy was to base all code (framework included) on the YAGNI principle. They were excellent - based on PB3 - PB4 without DataStore, PFC, etc.
Uncle Bob published his SOLID principles guidance in 2000. The Gang-of-Four book on design patterns published late 1994 with a 1995 copyright. PFC was released approx. same time as the GoF book so PFC's design was a product of the same time in software industry albeit ahead of what is now considered good design foundation.
Godspeed, /Michael
Using PFCs or not:
- they're great (to learn from)
- they add an extra learning curve to your project and there's not really updated documentation on how to use them. (though I did find a old PDF which I'll attach here and which might be very useful).
- if not used correctly, they might cause more problems than benefits (harder to debug etc.)
- using them does not mean that you have to put your business logic in certain places, that's entirely up to you (as whether to use API and restful services or not).
Chris' framework is great, but personally I found it "hard" to start with:
- a lot of things have to be configured by assigning objects to variables, but where ...
- the best help you get on learning how to use them, is by checking out the example applications Chris provides (or by asking Chris directly on this forum)
- I can't remember having seen clear "how to use instructions" or a nice manual (hopefully things have improved maybe by now. I checked them out some years ago). I found there was some information, but it didn't convince me.
I've used PFC's in many projects and found them causing lots of problems, most of the time because people didn't use them correctly.
I've been in a other projects where people had made their "own" base class objects and those were a lot easier to use, faster in execution and easier to maintain. Of course, this would also have the price tag of having to write them first (or write them "on the go", while developing). Then also, you need some "expert" developers to maintain them.
Whichever decision you might make, at least make sure you inherit all of your objects from some base class ancestor. (like for example w_master and u_dw in the PFC classes).
See the attachment for the pdf on PFC (a some things might have changed, but it'll still be useful).
regards.
Hi John,
I think the question to ask is what architecture you should go with, and then that will dictate what is appropriate framework to use.
My advice is that you do an API-enabled architecture where the UI is strictly decoupled from the business logic. This allows you to achieve Internet/cloud deployment and share your business logic across various UI technologies.
If you do decide to go this direction, we provide the .NET DataStore framework in C# for developing the business logic that you would expose as REST APIs. On the client side you would develop with PowerBuilder in PowerScript and deploy with PowerClient. We don't provide any framework for PowerScript (PFC was open-sourced long ago by Sybase and currently on GitHub).
However, if the client side is truly just UI you probably don't need something as heavy and complex as PFC. Maybe borrowing a few useful "visual" features of PFC, Chris framework, etc. and add to your app.
Best regards,
Armeen
Hi John;
FWIW: As an alternative suggestion ... http://chrispollach.blogspot.com/2021/01/2020r2.html
Regards ... Chris
That's a great question, John!
My advice to you is... it depends. It depends on several factors, such as:
Is your water utility system going to be developed in pure (classic) PowerBuilder, in PowerServer, SnapDevelop, etc.?
Are you going to separate your business logic from the GUI?
Are you going to deploy 32-bit or 64-bit?
What are the project constraints (number of developers, project duration, RDBMS vendor, etc.)?
What is your (and/or your team's) familiarity with the PFC?
Disclaimer: I've used the PFC for almost 25 years on many projects in a variety of industries. I know it well and I like it.
The PFC was initially released in PB version 5, I believe, It was designed for Client-Server application development, and software development design patterns and practices have evolved considerably since the mid-to-late 1990's.
Although there have been some minor changes, bug fixes and small improvements in the PFC over the years, by and large it has not changed substantially since it was initially released. Some of that can be attributed to how well it was designed and written, while some of it is because there has been no core team of developers dedicated to driving it forward.
Bruce Armstrong has done a terrific job of keeping the PFC alive and overseeing the PFC project on GitHub (many thanks, Bruce, for having done this!)
Therefore... answer my questions above to give the Community a clearer picture, and I'm sure you'll get feedback.
Best wishes and good luck!