Jump to content

Pseudo Object Oriented Designs w/ FileMaker?


spankalee
 Share

This topic is 6520 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Arrg, I just lost a long post because of a browser crash

I've been trying to implement an OO-like product catalog and inventory system with FM7 over the weekend. I've come up with two different methods, which both have their pros and cons. Unfortunately the cons are pretty serious, or at least annoying and inconvenient.

I'm hoping to bounce these ideas off people here to see if a good solution can be created. Maybe some of the FM geniuses here can recommend some tricks to work around the flaws.

Method 1: Model all objects with 2 tables.

This is a technique I've used with a lot of SQL/Java web apps. There's one table called Objects, or in this case Products, that hold the basic data that's common to all objects. For me Products has ProductCode, Type, Description, Price, Selling Unit. Then there's an Attributes table that hold all other information, that would be things specific to each sub-class of Products.

I usually also have a pair of tables called Classes and ClassAttributes. These tables define the classes and their inheritance hierarchy. Classes has a class name and a parent class. ClassAttributes defines the fields for a class and possible the default values.

The method is nice because it's very flexible and the end user can easily define new classes. It can also use one common layout for all classes.

The problems are that all attributes have to be the same type, usually Text. It also seems to be difficult to reference and perform calculations based on specific attributes, though FM7's evaluate function may make this easier.

Also the layouts aren't ideal because all the attributes must be displayed in a portal. There isn't a way to call out attention to the important attributes.

Another issue is that when a new product is created you have to get the type, and then recurse through the class definitions to setup the attributes. Because there's no trigger for field value changes that must be done through a script that the user launches. That always bothers me, since users can and will forget to press a button.

Finding a product based on it's attributes is also a problem.

I've had a lot of success with this method in Java but I think that FM and ScriptMaker aren't well matched for it.

Method 2: One table for each sub-class.

This is the method I've been working with most this weekend and it's almost working well. There's still a base Products table with ProductCode, Type, Description, Price, etc, but additional information is stored in tables that represent the subclasses. FM7's ability to reference fields more than one relationship away mean that you can have sub-sub-classes too.

For instance, I have a TileProducts table that has Style, Material, Grade, color and dimension fields. I can easily use relationships to pull the color and dimensions from separate Style and Material tables. I can also have a layout for each product type that is ideally laid out for viewing and editing that specific product.

One problem I have is that some of the fields in Product should be set based on the values in TileProduct. ProductCode should be calculated as StyleCode & MaterialCode & Grade. Selling unit and description should also be calculated. But the way calculations are set up I would have to do it in the Products table and this rule only applies to TileProducts, not other product types. Right now my only option is to run a script that will set the fields and that script has to be triggered by the user, when I would really like it to be triggered by a change to the StyleCode, etc.

Another major problem is browsing records. Everything is fine if you browse from the general Products layout, but you can't browse through all the records and view each product in it's "native" layout. Well, I could build my own navigation system that switched layouts, but that seems a little complex... maybe it's not that bad.

Both of these methods have problems if you change the product type, and both have problems setting fields in super-classes. The second method seems better for letting the user change key values (like Style) and updating related fields (like dimensions) and it seems more FileMaker-like.

I'm very interested in hearing from people who have an OO background and work with FileMaker. FM7 is a nice step forward, but it still seems like it's a decade behind in features.

Thanks

Version: v7.x

Platform: Mac OS X Panther

Link to comment
Share on other sites

I did something along these lines once. I had a main inventory file that listed the products on hand, and a related attributes file that listed the various attributes of each product. So it was a one to many relationship based on the product ID.

Then there was a product Type file. This would be like your class/class attributes file. This was where the attributes were defined for the different product types. In this file, there was a product type ID field and then sets of repeating fields for the attribute definitions. In its simplest form there could be two repeating fields. The first is attribute name, and the second is attribute value. Fill out one repetition of these fields for each different attribute. The value field can either be left blank or have a default value.

Now when you create a new product, you create a new record in the main inventory file and you will have a script that does this:

-Set a global field to the product type ID for the corresponding product type record in the product type file.

-Do a 'Go to related record[show]' in the product type file. This brings up the single type definition record.

-Execute a subscript in the attributes file that imports that single record from the product type file splitting the repeating fields into separate records. So, now you have automatically created a set of attribute records for the new product.

-Set the key field for these new records in the attributes file to the parent record ID in the main inventory file.

Now, in the main inventory file you can view all the attributes for each product in a portal to the attributes file. You can also search for products with certain attributes by performing a search in the attributes file. For example suppose you want to find all products that have a weight attribute >100 lbs. You would do this search:

Request 1: Attribute Name field = "weight", Attribute value field = ">100"

Clear as mud?

Link to comment
Share on other sites

Thanks for the reply Bob,

The object/attributes method still suffer from two problems in FileMaker. First my client likes their page layout and they've grown used to it. The product layout is like a form and different fields are grouped together. Pricing information is in one area, dimensions and weight are in another. I think it is still possible to have a nice layout with this method, but it would require lots of portals or many relationships.

Searching is still a problem too. I can find an object through the attributes for a simple search. But if I want to find, say, all products of Style ABC in Size 16 it gets complex. I'd have to find all attributes whose name="Style" and value="ABC" or whose name="Size" and value="16". Then I'd have to find which object IDs have a count() of 2.

So far today I've put more work in to the multiple table method and it seems to be going ok, though I feel like I'm going to hit a snag soon. The main pain is that I have to get the user to run a script when they change certain fields. I really wish there were triggers. Even if I could run a script when exiting a record or committing a record (same thing?) that would help.

Link to comment
Share on other sites

I agree that this makes setting up your layout tricky. I had set my solution up with the attribute fields in what I thought was a nice logical arrangement in a portal, and my client asked to move everything around. I was able to work around this by referencing the fields using compound keys ParentID&AttributeGroupID with multiple relationships to pick out attributes in different groups. (I created an attribute location ID repeating field that assigned a code number depending on where it was to appear on the layout.)

Doing an OR search is no problem. For this:

name="Style" and value="ABC" OR whose name="Size" and value="16"

Your find requests are:

Request 1: name = "Style", Value = "ABC"

Request 2: name = "Size", Value = "16"

I think you probably meant doing an AND search. Like:

Find a parent record which has both of the following attribute related records

name="Style" and value="ABC"

name="Size" and value="16"

This is quite tricky, but there is actually a very sneaky (and easy) way to do it described in the Moyer and Bowers book. Coincidentally, it involves repeating fields again. There was a discussion of it in one of the threads here. I will try to find it and post the link.

In the final tally, it's hard to say whether it's really worthwhile to try this type of structure. It depends on a lot of things. Despite all the setbacks that I had trying to implement it, I'm still happy with how my project turned out, and my client should be happy when it comes time to define new product types with new attributes, because he will be able to do the whole thing himself without having to get me (the developer) involved.

Link to comment
Share on other sites

Here are two links to discussions on finding parent records based on child record criteria.

This first one is fairly sophisticated example file posted by Ugo Di Luca:

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/83708/page/3/view/collapsed/sb/5/o/all/fpart/1

And this one is where I gave a quick and dirty explanation of the Moyer and Bowers method:

http://www.fmforums.com/threads/showflat.php?Cat=0&Board=UBB11&Number=87436

Link to comment
Share on other sites

"The object/attributes method still suffer from two problems in FileMaker. First my client likes their page layout and they've grown used to it. The product layout is like a form and different fields are grouped together. Pricing information is in one area, dimensions and weight are in another. I think it is still possible to have a nice layout with this method, but it would require lots of portals or many relationships."

This may or many not solve your problem; but note that FM7 allows you to split up portals. So let's say that your first two rows are always size related; and your second are style related. You merely set the portal in the size area of your layout to display rows 1 and 2; and the portal in the style area displays rows 3 and 4.

Link to comment
Share on other sites

This topic is 6520 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.