What would a universal navigation part look like?

Lounge (Discussions)
1

One of the pipe dreams for developers is the ability to re-use a navigation bar. I've been thinking about this recently, and I'm thinking about the way in which Menu Sets are implemented as a model.

  1. You define a layout as a "Component Part" This is a layout which will not be used directly. It will be used by being assigned to the parts of other layouts.
  2. You create as many component part layouts as you need.
  3. When creating a layout which requires a component part, you simply go to the part definition and select the component part that you want to utilise.
  4. The component part layout is displayed within that part.
  5. You may be able to position the component part, or tell the current part to use the same dimensions as the component part.

What other features are desirable?

Concept
Concept1920×1358 163 KB

4 Likes
2

I would add…

  1. A separate catalogue of layouts and layout parts. This would allow layout parts to have their own attributes and user interface.

  2. You would no longer drag a layout part as we do today. You would instead draw the part's rectangle. This would allow vertical as well as horizontal parts.

There are issues that would need resolving for this to work.

Object name collisions are bound to happen so some form of name spacing would be required. While I see no issue for new solutions, I see some for solutions converted from versions of FileMaker prior to the existence of this new feature.

Layout parts can show records and this must not change. Problem is, different layout parts can show records from different tables. Perhaps table usage would be limited to layout parts. Layouts would then only be able to use layout parts that display records from the same table, first come, first serve… or none at all.

Perhaps a layout part can display no record. This would satisfy the use case of defining tools, such as a navigation bar, that don't depend on specific table data. These would essentially be wildcard layout parts that could be used on all layouts, regardless of table used to display layouts as defined by other layout parts. Existing functions, such as Get (LayouTableName) and the like, would grab the layout's table be based on the table defined in the layout parts used.

I hope all this makes sense. I am fairly certain this could be fleshed out much better. All the same, hope this helps push the discussion along.

2 Likes
3

@Malcolm , in which version is the Layout Component Part available ?

Strangely Layout Component Part does not use the same font as other types to the left... Is this screen capture from your imagination :confused: ?

4

Layout component parts don't exist. It is a suggestion.

5

And a very good suggestion. I wonder if it's possible to implement it, since all these years Claris never did it.

6

In a version far, far away.

Yes. I'm trying to imagine how this works so that Claris engineers can come up with a brilliant idea that we've all wanted for a long time.

7

Thanks for the comprehensive response @bdbd

In a world where design decisions don't cost time or money, yes! However, I don't want to create hurdles to implementation. The user interface for creating layouts already exists.

Different problem to the one I'm dealing with. You'll have to start your own topic if you want to discuss it further :face_with_monocle:

Portals already display records from different tables. If a Claris "problem solver" is able to place a portal correctly they already have the skill set needed to select the appropriate

Interesting idea. I wouldn't support it in the long run because the inherent context of a layout brings so much power.