Naming Document Tabs

[bgregs514]

This really sucks: https://github.com/microsoft/vscode/issues/41909

Right now it's still pending on the VS Code side, but we don't have the ability to rename unsaved document tabs. A feature was added to use the first line of text as a title (which can be toggled off), but the only way to force a name is to save the file to disk - the attribute is readonly on the vscode api side unless the file is named.

I'm open to ideas, but this one probably needs to have a decent work around. Right now we can either save everything that is open to disk, or put a "temporary" line at the top of every opened document that includes the name of the object. The auto-line at the top kind of sucks though, since that will need to be removed upon saving, the user could accidentally delete it or change it, etc.

[ykud]

Hi @bgregs514 ,

I spent a bit pondering this and it might be a blessing in disguise ;)

Here's an off kilter idea: If we were to save the rule files on disk on edit in the format of how TM1 Git integration saves it, it would enable a much better Git workflow in future. I.e. if you click edit on a rule, we should save a file in the format like this https://github.com/Hubert-Heijkers/tm1-model-pony-music/blob/master/cubes/Record%20Sales.rules in a folder that we define as a server config. We don't need any git integration at this point, just a file folder with everything stored in that format. This would enable you to pass on the saves correctly as you'd have the file names?

And later on if somebody's configure git to export the model to the same folder, we'd be getting the functionality like GitLens / git blame straight off the bat. Things like this:

[bgregs514]

That's a really good idea! I was wondering initially if it made sense to save to disk so it could have some sort of rolling "auto-save" to prevent losing data, but your idea takes it a step further with saving it in the integrated git format, which is definitely the best approach.

Since this is a more critical piece of the core tool functionality let's give it a few days to see if anyone else chimes in, but this proposal has my vote! Being able to layer this with other extensions adds an incredible amount of flexibility to it too. Nice job on this!

[scrumthing]

I could add something I learned yesterday from a trustworthy source but unfortunately had no time to double check. You can request a hidden property for a turbo integrator process. If you $select('code') (sorry if the syntax is wrong) the rest api v1 will give you the TI code in the format of the git integration (one block of code separated by region-end region). Had no time to try that but it is supposed to work on 2.0.9.5 (not sure about earlier versions). That way it would a) be easier to edit ti code in one window and b) already be compliant with the git integration.

Hope my point is clear and it helps.

[ykud]

@bgregs514 , thank you!

I agree that it is a core design decision, so let's let it brew for a bit.

Another reason I'd love to have a file representation is that when we implement a 'save all the rules / process code locally' button it would give us the Notepad++'s killer feature : search in all the files :) And having all source in files would also allow you to run global code linters. Go files in git format! Anyhow, I'm obviously biased, I'll shut up for a bit :)

@scrumthing -- that's amazing, I'll try and see if we can guess the api syntax. It does make sense for it to be there.

My ideal state would be to really just present the git-format of the all the objects as it's readable and writeable enough from my point of view, so if there would be a get-git-format and post--from-git-format API calls we'd minimise the transformations required and keep everything quite neat.

[scrumthing]

+1 for 'search all files' +1 for global linters

The git stuff gives you a couple of interesting possibilities. It could be a nice way for a git workflow by 'downloading' the model, changing processes, pushing it to a git repo, pulling it to another tm1 server. (Actually not sure if that makes sense but sounds kind of cool in my head).

@ykud will check for the syntax as well on Monday.

[ykud]

You can request a hidden property for a turbo integrator process. If you $select('code') (sorry if the syntax is wrong) the rest api v1 will give you the TI code in the format of the git integration (one block of code separated by region-end region). Had no time to try that but it is supposed to work on 2.0.9.5 (not sure about earlier versions). That way it would a) be easier to edit ti code in one window and b) already be compliant with the git integration.

Just checked and it is Code with capital C, very nice: https://{{tm1server_ip}}:{{tm1server_port}}/api/v1/Processes('mover')?$select=Code works for both get & patch, so you can edit code like this.

[bgregs514]

@scrumthing @ykud This is fantastic news! My vote is to make this the preferred method of "get"ing and "patch"ing TIs.

I haven't checked, but is there any benefit to pulling rules in a similar way (if it is even a possibility)? Based on the way rules are pulled and posted to the server, it appears to me that the json conversion is already happening behind the scenes. I guess what I'm really getting at is even if this were an option ("this" being the $select=Code query), would there be any benefit for rules? The only plus I can think of off the top of my head is a standardized "GET" method between rules and TIs, but that is a minor benefit at best.

Unless we hear otherwise, I think we should progress with this method for TIs. Let's take a few more days to play around with it, and by mid-late week we'll come to decision.

[ykud]

I haven't checked, but is there any benefit to pulling rules in a similar way (if it is even a possibility)? Based on the way rules are pulled and posted to the server, it appears to me that the json conversion is already happening behind the scenes. I guess what I'm really getting at is even if this were an option ("this" being the $select=Code query), would there be any benefit for rules? The only plus I can think of off the top of my head is a standardized "GET" method between rules and TIs, but that is a minor benefit at best.

I think this would be only for Tis, you can do the $select=Rules for Rules already, there's no need for making it more complicated than that. I'm actually thinking whether Code is that much better than $select=PrologProcedure,MetadataProcedure,DataProcedure,EpilogProcedure and a bit of wrapping it around with #Begin / #End region and being in 'totally supported' land :)

[scrumthing]

Code is supported. It is there for forward-compatibility. To ensure the same format as in v2 (aka git format). Makes it easier to switch to v2 in tm1 12.x

[ykud]

@bgregs514 thought I'd mention that files are used in sql query extension, so I think that's an accepted approach.

I was also looking at how connection list and manager works in this extension today, I'd be keen to see if I can replicate something like that, it would be exactly what i have in mind :)

[rclapp]

Late to the party, but I agree with this. Playing with git functions quite a bit lately, and I think this makes sense. Local copies will make things much easier to manage, additional capabilities include auto save versioning, forward/reverse sync from local copies, and the ability to work offline if needed.

[bgregs514]

Closed - local copies are implemented and this is no longer an issue.