Bryan and I met and went over the flex attributes project. He recorded a few different segments. We talked about what we have already got by way of other applications that have similar concepts. We also went over some planning and details. Here are some random notes - no particular order.

- Flex grid tie-ins already have 30 custom fields. They are already built out to play with and handle all 12 main application player groups. Flex grid is pretty cool but it lacks data types and it has grown to be pretty large. All of the custom fields are text or varchar characters vs real data types.

- We are looking for a cross and a hybrid between the power of the flex grid, the dynamics of sub inventory attributes, and make these new real in-line database extensions play throughout the entire application. Cool concept.

- Here are some pages that already have similar type code - places where we could harvest some ideas and code: All of these are in the top_secret/secure folder.
-- sub_inventory_template_home.cfm - Lists out all of the sub inventory attributes per part category. We would want to do something similar but for all 12 main player groups.
-- sub_inventory_templates.cfm - Add/edit page that deals with sub inventory attributes. Our would be for all 12 main player groups.
-- add_edit_flex_titles.cfm - This page lists all 12 main player groups, uses settings and custom naming, and also checks for permissions. We would love to mix this page with the lists from the sub_inventory_template_home.cfm page. Nice hybrid.
-- edit_sub_part.cfm - This page dynamically builds form fields for sub inventory attributes. Eventually, we will need something similar for all 12 main player groups.
-- sub_inventory_view.cfm - This page dynamically shows any extras or sub inventory attributes without the edit capability options.

- Existing tables to look at are: sub_inventory_attributes, app_types, custom_text, custom_numerics, custom_dates, custom_json, parent_attributes.

- As we were talking... we are thinking of a couple new tables... just ideas. One would be called flex_attributes and the other would be called flex_attribute_data - the data table would allow for text, numeric, and date values. Somewhat of a combo table as compared to custom_text, custom_numerics, and custom_dates tables.

- We asked some questions... shared tables or corp-specific tables? Auto populate and build or just in time? New tables vs old tables (add or modify existing)? Think of the number of servers, number of corps per servers, developer instances, etc. All of these deal with scope, maxes, mins, pros, and cons. Design decisions. As a fun side note, I challenged Bryan to spend a couple of hours and plan things out. I also challenged him to use Excel (spreadsheets) and do some mock-up data and get a feel for things that way before any code is written.

- We also talked about the database field settings project vs these real in-line database extensions and flex attributes project. The database fields settings is somewhat similar in the fact that you get to name, sort, add descriptions, create your own aliases, show/hide things, etc. The main difference is, the database field settings are already tied to real live database columns and fields. For example: Say in customer you have a field called terms. You could rename it, require it, and then search it. Even though you did all of that, the database still calls it "terms" as the actual field name. The real in-line database extensions or flex attributes creates a brand new field and gives it an id number. No matter what you call it, all of the new data is tied to that id number with whatever you want to call it. If you want to kill it, you can. It is not really part of the original table. Anyways, we went through some small differences between those projects.

- Lots of drawing and building out samples. One of the topics was special dev flags or special fields just for developers to use - (dev = developer). We talked about how dynamic this table will end up being. We may want to build in some special fields that allow us to flag and tag the data as needed. Basically, thinking beyond our current project to where it will be going.

All in all, a great session. I'm excited to see what Bryan comes up with. As a small side note, we may need to provide an instructions field for flex attributes, we may also need a flag to show/hide on the web. Very similar to the database field settings. I hope we keep building and learning from our current prototypes and experiments. That makes it fun.