Template objects

When I am doing data entry, most often I will be adding a stream of new Events always keyed off that Source and often having common element. (e.g., a series of sibling Births in the same hometown, or a series of Residences as of an obit date)

It would be nice to set up a zeroeth ID for each object & have New objects of that type inherit the data. (A Person template could already have birth Events, Parents, sources, etc. The big hitch would be that, in such cases, it would be more useful to clone the secondary objects rather than Share them. So how would you specify Share vs. clone?)

So, I might create an ID “E0” Event that cites the Obituary, has an Event Type of Residence on 3Mar1980 in Lawrence county, Pennsylvania, USA & description of “per John Smith obit in NY Times”. And while E0 exists, all newly created Events start with a CLONE of that Event data.

In a bit of reverse logic, there should be a way to clone an existing object to a Zeroeth object template. (I started with the idea that you could just change the object ID to a Zeroeth form, create a new object & give new object the original objects ID. But that seemed too likely to break back references & Note links.)

The zeroeth object should always float to the top of the View’s List.

3 Likes

I wholeheartedly support this idea. Having to type the very same stats for hundreds of citations of the same book is something that must be automated. This would also alleviate the need for the Forms addon.

How about keeping template objects (TO) entirely separate from existing database objects (DO)? A TO could lack any vital information and could exist without being attached to any DO. It would NOT appear among DO-s in any list but should be listed in a separate list/window (like in a sandbox). The user coul select them to edit, to attach to a DO, to clone to another TO, to delete, etc. Without missing vital data, a TO should not be converted (and attached to) a DO.

I understand that objects at the moment can not exist without being attached to an existing object in Gramps’ paradigm, while this proposal would explicitly require that. I also understand that this is an old thread. Is this nevertheless doable?

1 Like

I’ve been thinking about this for a long time, but I eventually dropped the whole idea because there was so much negativity around Main/Sub‑Events and hierarchical Events on Places. The thing is, what you’re describing fits directly into the same workflow. It’s essentially the same concept, except your proposal assumes a flat event structure with no hierarchy inside the events themselves.

That’s why I’m starting to wonder whether what you’re describing could actually fit naturally into the new Forms Gramplet that RenTheRoot is working on, instead of introducing a completely new “template object” system.

I believe I understand what you’re trying to achieve. Before I moved to Zotero and Obsidian, I was looking for exactly the same kind of workflow using the old Forms addon. It didn’t quite work the way I needed back then, but the idea was very similar.

What I imagine is a more flexible Forms template where you can define multiple households within the same form. Based on line numbers or post numbers, the form could automatically create separate “apartment‑households” under the same main event. For example, the main event could be tied to the address, while sub‑entries could be grouped by line ranges (line 0–5 as one household, 6–9 as another, and so on).

It would also help to have an option to mark that the following lines belong to the same person, so you could add multiple sub‑events (like several residences or other details) for that person from the same source without having to save and start a new Forms sequence each time.

This kind of structure would also handle sources like crew lists or address directories, where you may need to register multiple entries with individuals who do not necessarily belong to the same top‑level address, and where each entry contains different details. In crew lists, for example, you might want to register nationality as an origin‑type event, or record other attributes as separate events. Address directories often list many individuals under the same street but not the same household, and this kind of flexibility would make it possible to register all of them in one workflow.

This would also make it possible to generate citations at the line/post level. A post number could be automatically assigned for creating a detailed citation, controlled by a simple checkbox such as ‘create a new citation for this line/post’. If the box is not checked, the previous citation would be reused for the following entries. This would allow users to choose between line‑level citations or broader section‑based citations depending on the structure of the source.


This is actually one of the main reasons why I’ve been advocating so strongly for Main/Sub‑Events, and for allowing the same Main/Sub structure on Places as well. Many sources naturally contain hierarchical or grouped information, and having a way to reflect that structure directly in the data entry process would make things much more efficient.

To me, this feels like something that could be implemented as an extension of Forms rather than a new template system, but I may be misunderstanding your intention. If your goal is to clone a complete event with all secondary objects because the source contains repeated patterns of information, then I can see why you’re exploring this direction — but I still think an extension to Forms would be a better solution than introducing an entirely new template system.

I’m also a bit surprised I haven’t seen this idea earlier. I fully support a flexible approach like this, especially if it could be combined with the event‑structure changes I’ve suggested in the past, including hierarchical events on Places. And if this structure could also be reflected in CSV import — perhaps by reusing templates stored as JSON or XML settings files — that would make the workflow close to perfect.


Note: This text was originally written in Norwegian and translated/edited into English with help from Copilot AI. I (the author) have reviewed the final version to ensure it matches the meaning of what I wrote in Norwegian.

1 Like

I’ve considered using the Import Text gramplet with a few XML objects saved as Templates in Notes.

But it turned out to be too much of a hassle to view or export an object in raw XML.

Correct me if I am wrong, but aren’t these separate issues? One is whether to have easily reusable empty templates for Gramps data objects (as per the data model) and the other is whether events should have sub-events (in Gramps objects and in templates). I don’t see any theoretical objection/obstacle to creating templates that only recieve valid IDs (potentially to any sub-objects it has) when attached to an already existing database object. It is a valid question whether templates should allow templates within (as sub-objects), as that could lead to recursions. But this can be checked against. Ad extremum, templates within templates could be prohibited, to simplify the case, and even such flat templates would be useful.

On the other hand, I have no strong opinion about the pros and contras of main/sub-events, as I am not familiar with that dicsussion. I understand a need for it, but I never encountered this need.

I understand that developers first want to make sure that any new model should have the optimal implementation so that it remains extensible to potentially handle hierarchical objects later. But in my opinion, even flat templates (without the possibility to sublink other templates) would be extremely useful and save thousands of clicks for many users. Think of e.g. citations that are pretty flat themselves and one creates thousands of them all the time. I think the very need for automatiing such repetitive tasks is enough to justify the existence of templates.

Checking it out right now, thanks for the pointer.

“Main/Sub‑Events and Events‑on‑Places versus ‘templates’ are obviously different functions.
But if you read what I actually wrote, you’ll see that I’m using them as examples of parallel and interconnected workflows that directly mirror how templates would be used in practice. And Gramps already has a template‑like system in the form of the Forms gramplet.

So the question is whether it’s really necessary to introduce yet another system when roughly 80% of the required functionality already exists in that addon.

And personally, I don’t think any kind of template or system‑level object should be mixed into research‑data objects, regardless of the intention.