As I am beginning to use templates and attributes for organisation, the templates are organically growing and becoming more useful. Currently, updating a template doesn’t propagate to the existing pages using that template: Templates - how to create, edit, and insert?
However, this functionality would be very useful to buildup and maintain consistency. I realise there are issues with overwriting a local instance when the global template changes, but a smart management of these should be possible ? For example, a waring if an attribute is removed with some options as to what todo with the respective attribute elements (copy to another attribute, leave as it is, etc.).
If updating a template propagates to its instances could also be made optional, e.g. with a prompted question upon finishing the update if the instances should be updated or not.
Just a thought on this - I wonder if it’s actually possible? Once a template has been inserted on a new page, that block can then be edited in any number of ways. If the original template is then changed, how would those changes be merged with a copy of the template that’s been edited independently? I suppose it would work for some sorts of templates, for example, if the template contains a query, or a reference or embed. But if the template purpose is to create a space for text, images, etc., trying to merge the template changes with all the different modified copies of the template would just wreck havoc.
I suppose there are a number of ways to do this, from manual review to semi-automatic merging that asks if say small changes should be made, like ‘Author’ to ‘author’. Or something like that.
Or perhaps another option would be immutable attribute templates, that, once the block with attributes is created, the attributes can be filled but not changed unless it’s done via changing the global template.
The larger point I’m suggesting is simply: a more systematic way of creating consistency via a global structure like a template that can be globally edited without having to edit all of its instances manually.
Understood, re your larger point. I think it would be very helpful to have more structure for the purpose of supporting consistency and ease of global changes. I get that one of the reasons that structure isn’t in place is that the aim of logseq is to keep options wide open so that people can build whatever framework works for them. But I agree that it would be helpful if there were more building blocks in place to offer structure and consistency where it makes sense.
I like your idea of offering “immutable attribute templates”. If I’m understanding you correctly, it sounds like that would be something akin to form fields and a database, that would hold the various instances of info/data added to the form from all the various locations where it’s available.
I imagine it would make sense to have both sorts of templates available, so that people could create whatever freeform things they want, knowing that changes to it won’t affect previous copies of it, while also having a library of forms (or a method of creating forms) that would offer a more structured and data-safe way of creating a template that could easily have its changes replicated to its copies.
You could use it like that via queries, I suppose, but without having to save stuff in an actual database.
I was thinking of template instances having parents and all children being changed when the parent changes. Or even, when changing on the child level, being asked if these changes should apply only locally or also to the parent and all other instances of the template.
Absolutely. Mutable/Immutable could also be a property of the attribute block itself.
The use-case I’m having in mind is: I’m building up a system, and it frequently changes and improves. A template for ‘interviews’ may get a new attribute to be able to later query upon. Currently, one has to manually add this field to all existing instances of the template. But that sounds like the kind of tedious work that computers were invented to do for us.
oh, yes, with your use case I can see how aggravating it would be to go in after the fact and change it, and how important it would be to make sure it got done anyway. I would guess that many people have uses for a template that would make sense if this global change/update option were available, but would not make sense without it.
I’m just wondering - haven’t tried it yet: maybe a workaround would be to create whatever the structure is that will go in the template on a separate page, and then embed the block in the template, instead of putting stuff directly in the template. Then, if changes are made to the page containing the original, any place where the template has been inserted will have a block reference to that original structure, so it will change when the original is changed. Not ideal, and probably has limitations depending on use case, but it might be helpful in some cases.
I’m not entirely sure I understand. Are you suggesting a macro can dynamically update instances of an ‘old’ template ? Like in my use-case, to rename or delete existing attributes and to add new ones.
That would be a good work around !Yet ideally I’d still propose for LogSeq to ask if it should update all instance of a template when a template itself is changed, and/or provide a context menu option to do so.
When you call a macro and see it’s output, if you edit it again, you will see that the code of the call of the macro steel being there, instead of what happens with templates, witch you get a copy of the template, as a substitution of the call of the template it self.
And if you prefer to edit a regular LogSeq page instead of editing the value of the macro key in the config.edn file, you can call a template in the macro value and then define or edit that template, for example. That way, you will have “template” that propagate it’s updates to all it’s existing “copies”, maybe. I have to test it.
…
I wanted to try this, calling a template from the definition of a macro, but I got stuck in the silly step of not knowing or finding out how to call a template not using the comand “/template” utility…
I haven’t found it documented anywhere. It does seem strange to me that there is no way to call a template by writing it directly, such as “;;template x” or just like macros: “{{template_name}}”.
And since it turns out that templates replace the code of the template call with the content of the template itself, there is no easy way to find out if a syntax for calling templates is yet implemented or not.
Perhaps the best thing to do is to use macros instead of templates.
I don’t know the reason why the developers decided to adopt the current solution (replace the invocation of the templates by the content of the templates themselves and limit the definition of the macros to the configuration file config.edn, instead of the templates do the same functions as the macros and that the substitution is one more option of the macros themselves…). In any case, it might be wise to replace templates with macros before your graph grows too large.
Ok got it. That sounds like a workaround worth looking into.
But I’ still want to suggest for the developers to provide functionality like this for templates. With any growing graph, templates will need to be developed. An app for evolving note taking system should support functions for house-keeping and restructuring of the notes as they evolved, I think.
If you take a look at the concept of the brand new “Supertags” in @Tana_inc, it is definitely something to implement into the Logseq Templates (block properties + templates). Tana Fundamentals 05 – Supertags - YouTube
but also the Backward edit to those blocks or pages where you applied such that template. At least, having the option to do it. I can imagine a scenario where someone doesn’t want to change the former instances and apply the new template to the incoming blocks or pages. But in most cases and from a continuous improvement approach, you will want to apply that template change to all previous instances.
For me, solving the issue of templates (that should act by transclusion) is primordial and inescapable.
Not only for this case, but also to be able to make use of concepts (like classes in OOP) in which to define the properties (which in turn could be seted by the result of a dynamic query), as well as assign properties that can be expanded or redefined on the go, or even frame the concept in superstructures of higher levels of abstraction.
In this way, ontological can be built independently of the content.
Just to re-phrase this, because it is such an important issue: One massive downside of Logseq is that tags are tied to content. There is no way to take all #cat pages as a group and place them together in a folder, or to tell Logseq that #cat and #kitty are related concepts.
We normally associate nodes with content and the relationships between them as edges.
It is a representation and as such, it emphasizes an aspect of reality.
Well, when thinking about another layer of abstraction such as dealing with the relationships between the relationships (meta-relationships) between the contents, which in the previous representation would be the edges, now, thouse, the edges, become nodes and the relationships among them are represented as new edges, drawing an independent graph but linked to the other and representative of another dimension of the same aspect of reality.