Portal in a Portal?

[mbath]

I am trying to implement a task tracker which is basically hierarchal in nature with three files: Projects, Milestones, Tasks.

I need a Project report which will display the associated Milestones and tasks for the found set. The concept of a portal within a portal discribes it nicely, but seems to be impossible.

I thought it might be possible to display from the middle level. Using a portal will show the child-tasks. But not sure how I can group all related Milestones together that are under a singe project.

My boss sends me deep into FMP about once a year, so I never really get as good as I might. appreciate any help you might offer

[LiveOak]

You are correct. A portal within a portal is not allowed. I've implemented several WBS systems (Work Breakdown Structure) using a single file with three types of records. You can display these in a portal and have the display show projects until you click on a row, then it expands to show indented Milestones which when you click on a milestone expands to show tasks. Its all done with a global to real field relationship. What rows are displayed is controlled by the contents of the global field. -bd

[Keith Silva]

Very interesting. Feel free to describe this operation of a portal in more detail. Do you think its better to have projects, tasks, and milestones in seperate, individual database files, or set them up to be different kinds of records in one database file? They do share a number of common fields.

Thanks, Keith Silva

[mbath]

I went with different files so I could take advantage of relationals lack of duplication i.e. 10 projects with 10 milestones with 10 tasks each. would mean 10 records in Projects, 100 in Miestones, and 1000 in Tasks.

Might not be the right method.

Since multiple kind of records has come up twice in two replies, I may be way off track. I'm guessing that it becomes a huge flatfile with some sort of match field to link the parents and children and a flag of some sort to say what type it is.

I'm grasping here, can you discuss the use of "different kinds of records" in the same file. Maybe I'm making tough on myself. (pre-coffee comprehension)

[Keith Silva]

My files are setup the same as yours -- different files for projects, tasks, and milestones. LiveOak seemed to be describing one big flat file which I'm guessing has a field named something like "Type" which is used to classify a record as either a project, task or milestone. I also assume that there are self-joins in this file that allow matching and linking of these different kinds of records. What I thought was very interesting was LiveOaks description of an outline or "tree" type structure that displayed projects until you click on a portal row, then it expands to show indented Milestones which when you click on a milestone expands to show tasks. I'd like to hear more about how this is done with a global to real field relationship.

Thanks, Keith Silva

[LiveOak]

I usually don't like mixing record types in one file. We used it to store activity codes which were standard classifications which did not change often, not to store hours, budgets or some sort of dynamic data. The whole idea in using one file was to allow the unique display by hierarchy. The principle is simple, but the implementation got a little complex as we displayed different levels with different color backgrounds and indents. We had project Phases, then Categories, and finally Activities in descending order (a project had phases, which were made up of categories, which were divided into activities. The basic idea was to give each item an "ParentIndex as follows:

Phases - ParentIndex = "1"

Category - ParentIndex = "1" & "." & Phase

Activity - ParentIndex = "1" & "." & Phase & "." & Category

A global in the master file called gDisplay is set to "1" to display all Phases and nothing else. When a Phase 2 is clicked on, gDisplay is set to:

1<cr>

1.2

now all Phases AND the Category elements of Phase 2 are displayed. If the third Category of Phase 2 is clicked on in the portal, gDisplay becomes:

1<cr>

1.2<cr>

1.2.3

Collapsing the list is just a matter or removing the element clicked on from gDisplay.

There is also some fooling around to keep the list centered in the portal by controlling the current portal row.

A hope the general idea is clear. A complete explaination with the indented, colored background management would be a little bit lengthly.

-bd

[Keith Silva]

Yikes! Looks complicated. Thanks for the explanation. Its nice to know that such sophisticated things are possible with FileMaker. A pro such as yourself can really add a lot of value to a solution using such sophisticated techniques. I bet the final product looked great. I'm going to study your response for awhile, but it will probably be some time before I try something this involved.

Thanks, Keith Silva