For every table in your Analysis you need 2 classes a record class (a single record) and a Manager class (which manages the actual file access and hold a collection of records). Today we are going to talk about creating the Manager Class, which is relatively painless thanks to a couple of code bricks we have created, which you can download here. You can also follow this guide to install them.
For this example we are going to create a manager for the Company table. The first thing we do is create a new Server Class called CompanyManagerClass (or CompanyManager or whatever naming convention works for you).
Which gives us a blank class that looks like this
Now we simply type FMDin the declaration area and since that is the shortcut to the File Manager Definition Code brick it pops up as a select we can take
When we do it shows us the code and prompts use for the FileName, notice as we type the code reflects the changes
And when we press OK, it inserts the code into our class
Now we move down to the constructor area and type FMC and repeat the process
If you follow our naming convention, Every Table has a primary key named with the TableName followed by ID then you are good, if not you will need to tweak Line 3 as needed or better yet modify your code brick as needed.
That’s all there is to creating the basic manager class, there is a lot of virtual methods that we can override many of which are discussed in other post so be sure to checkout the entire collection of post covering the File Manager classes
3 thoughts on “FileManager Primer – Creating the Manager Class”
Thanks for the primer. It’s good to be reminded of what’s out there.
I’d like to take some time and give your wx file manager a fair try.
You start off by saying “For every table in your Analysis you need 2 classes…” Do you have, or, is there an article that explains why I need to use the wx file manager? What are the benefits to using the wx system?
Maybe this is a better question to post in the Wx group.
Most of my post and videos are more of a how than a why. As you see some of the things you can do the why becomes clearer – other than “If Uncle Pete’s uses them it must be cool” 🙂
In general, you can build a lot of your business logic into the classes instead of your UI. So all your RI code, lookup code, etc. lives in the classes and magically works across Windows, Web and Mobile. Is one good reason. There is lots of Lookup stuff we do with our classes so we aren’t constantly lookup up things like category description for categoryID etc..
In Windows development (and web depending on how you develop) you get the added benefit of your browse and form sharing the same class so your table magically gets updated when you return from a form without any additional database access.
Basically it provides a standard backbone for all your data activity that can be used across all platforms, and lets you encapsulate all the logic in the classes.
What some of Andy’s recent training videos should give you some more ideas. And I have a couple more post planned that will so some additional FileManager magic. And yes definitely ask over on the Facebook group and get some input from some of the other folks using them.
LikeLiked by 1 person
Thanks. I’ll keep that in mind when I read your current installment of extending the class. I think it might shed some light on the mechanics behind/inside the manager.
Having the same code behind the desktop and the web may be reason enough.