I prefer and encourage the nested approach for companies that want to do frame and panel elevation sheets where the two are broken apart. This allows the legend tool to be used quite effectively, as well as you can have a single door family that you can switch out any number of panels or frames in, making managing doors and windows more effective in a project environment.

Door-Parent Family (Door category):

Sizes are all instance, Types are mainly used only for Interior or Exterior. Door swing is currently a type parameter, as is "uneven doors (yes or no)," although those are both mistakes. They are meant to be instance parameters and will update as soon as i get a chance.

We have different Door-Parent families for each door action type, since i dont believe in Super Families. Single, Double, Double Egress, Commercial Sliders, etc. Although OH doors are still our Door-Single family, with a P60 panel.

Door-Panel Family (nested, shared, door category):

Has an individual panel modeled, all type related sizes (panel type) are Types, driven from project. All door size parameters are instance, driven by the Parent.


Door-Frame Family (nested, shared, Door category)

Has the frames built as native geometry, NOT as a continuous sweep. That way the head and jamb dimensions can be different.
The Frame is wall hosted, and has the opening the cuts the wall. (In a perfect world i would move these to the parent and have this family unhosted, but reporting parameters wont work from child TO parent, so this is a deal breaker...).

The Frame characteristics (called out as Frame Parameters) are type based, driven by the frame family type in the project. All door related parameters are instance, driven by Parent.

---

Ive done an office where the Frame family IS the Parent family. it works okay, for the most part. Harder for people to edit, since the complexities are all so visible. But its doable.

OOTB versions = barely functional, and the door schedule ends up like garbage.

EDIT: Glazing is currently not modeled in our Doors, nor is hardware, but thats because our next round of door changes is going to incorporate nested shared Hardware and nested shared glazing.

Gordon: Graphical control of Face based doesnt go to pot BECAUSE its nested, you just have to know that some things are quirky with face based families: The ANNOTATIONS refer to the NAME of the view in the project browser (if you want a symbol in plan, you place it in plan (even though thats the elevation). But if its object visibility, its based on what view you see it in FROM the family (Front/Back in family = Plan/RCP in project). Once you get your head around their stupid inconsistancy it works great.

Aaron,
with regards to visibility, I think I stumbled upon something else. The crazy reorienting I am aware of, so my usual approach is to make objects visible from all directions in the nested part, then manage the visibility on the nested instance. The problem crops up if that nested family also happens to be shared.

For example.
Make a door knob as generic model face based. Set it to show in every direction. Make it shared.
Nest it in a door leaf family.
Nest the leaf twice in the final door family. Put the leafs at different angles. Make one leaf visible and Course & Medium LOD. Make the other visible at Fine LOD only.
Place the door.
The leafs work as expected at different LODs, but the hardware for both are shown no matter what. One set of hardware will be floating in space.

Do the same, but the hardware isn't shared, and the hardware inherits the LOD controls set on the instances of the leaf. No doubt this could actually be "as intended", but I think it is also wrong.

Gordon

Ive got them Shared, with LOD control done in the Nested hardware itself, and it works fine.

I *have* noticed this: If you load the shared hardware in to the door, then go BACK to the shared hardware and make changes affecting the visibility controls.... You have to completely delete the family definition from the parent family, and load it back in, to get it to work right. Maybe thats what it is affecting your families?

Bet that's it! I forgot one of my least favorite rules of Revit. Once you have a family working, you better go rebuild it from scratch, or something will sneak up and bite you in the butt.

Thanks!
Gordon

I'm going for nested components for doors and windows. Frame pieces, glazing, hardware, leafs, etc. All are nested. Just because I don't want to be rebuilding a window or door family for every type of frame. Besides that, it's more foolproof. I share my families with newbies and this way they can use the families and make all changes wanted without needing to tamper with the actual families that drive the window/door.

So, just to clarify... People are using nested Doors and nested Frames. But are those frames made up of nested frame segments? So a simple window frame contains four nested items, maybe all the same, maybe two Frame Jambs, a Frame Sill and a Frame Head, maybe something else?
Or is the nested frame made up of a single extrusion? Or perhaps a sweep? But still primitive geometry, rather than a set of nested families?

Thanks,
Gordon

I nest all frame parts into a frame family which I nest into the host family. Same as hardware is nested into the panel family which is nested into the host family.

I create the frame by single extrusions in the frame family, and nest that into the host family.
On a few occasions I´ve done a sweep, but in most cases I need at least the frame sill to be different from the jambs and head.