adding support for optional keys in templates

[nebukadhezer]

Hello Martin,

this pullrequest is to support optional keys
'{pro}/[{episode}/]{seq}/{shot}'
like this in square brackets.
I dont know whether you favour this at all, but I like the them a lot.
As one can reduce the amount of templates a lot.

let me know what you think.

Cheers
johannes

[martinpengellyphillips]

Thanks for this - will take a look over the weekend.

[nebukadhezer]

Hi Martin,
if you dislike the idea or the way I implemented it. Please let me know.
I first thought of writing one regex that builds the optional structure.
To be honest after testing it I was a bit afraid and thought the list approach is, well not sexy, but a bit more easier to read and easier for me to implement.
I guess that is a design issue. If you dislike the lists of regexes then I can give it a shot of putting it into a single regex... though I am not sure if that is doable at all...
cheers
johannes

[martinpengellyphillips]

Hey,

Didn't get as much chance to play with this as I wanted over the weekend. However, here are my current thoughts:

As stated in #29, I still feel that putting this behaviour in the template then conflicts with the idea of having multiple templates and that it also makes the logic more complicated (not only in implementation, but also usage). It also leads to the question of when to use multiple templates vs optional keys.

I think what might be better is to add this behaviour as a helper / preprocessor instead for those that want it. So given some strings in this format the helper generates the relevant template instances and returns them as a collection, from which best match can then be used. Of course this line of thinking does mean that #18 needs doing!

Maybe I am missing something though - what is the driving force behind wanting to reduce the amount of templates considering they can be generated programmatically?

[nebukadhezer]

Hi Martin,

one point is I am used of having optional keys in templates :-)
For me personally it is easier to be honest.
In our past feature production we had well over 120 ish templates (with optional keys).
Though the system we used was limited. With proper optional keys we now could reduve the amount drastically.
for example
we have templates for image sequences, that can be used for quicktimes, one has to lose the frame token and even sometimes the stereo token.
For me it is easier to write one template with the stereo key and frame key optional instead of having four... then if sth beforehand is optional it gets another multiplier...
so we already 8 templates that could be written with one...

Maybe the best match approach is sth I have not givin much thought yet....

What I tend todo with our old system and lucidity already is usually this:
-get a template from a path (in the pipeline this tends to be an opened workfile)
-retreive the tokens modify/add/delete them and format them again with the same template or another one I happen to know by name.

If I am having optional keys in there I can use the same template for stereo image sequences, image sequences, movies and stereo movies in projects with an episode or without.

So i can leave out an entire naming based matching logic or hardcoding of template names.

Or how would you approach sth like this ?
getting a template only by tokens/placeholders frightens me as we would have to guarantee that there is no template that consists of the exact same set of tokens...

Cheers and thanks for looking into this.

[martinpengellyphillips]

Sorry for the delay - I totally missed that you had replied!

I understand where you are coming from - I'm just not sure it fits into Lucidity at the Template level. One of the reasons that I avoided supporting reading from config natively in Lucidity is that I felt it more powerful and flexible to be able to manipulate them programatically. I also like how this means that the rest of the logic is very clear and it is simple to work out (and prioritise) which Template is used for which situation later.

However, as mentioned, I'm open to adding some helper / preprocessor stuff to Lucidity which would give what you want I think, but just at a higher level than the templates - perhaps linked to reading from config files.

Can you send through some concrete examples of your template combinations so I can get more of a feel for what is involved and perhaps give an example of how I might handle it now?

[nebukadhezer]

Hey Martin,

sorry for my delay now and thanks for the answer, maybe it would be good to have some other connection to talk about this...
I guess your approach regarding the design of a pipeline and its origins around filenames is different to my understanding.
I dont quite understand (designwise) how I should create the templates programatically.
Probably this is the root we should clarify before going further :-)

Cheers
Johannes

[martinpengellyphillips]

Sure! - I've pinged you via email.

[tokejepsen]

Any news on getting this merged?

[nebukadhezer]

Hey,
we agreed to better move this into a sort of preprocessor/generator.
So it is more flexible.
The only thing I have not thought about yet is how to propagate the differentiation between optional missing keys and normal missing keys then...

So basically I would want to rework this a bit... though I dont know when ....

[tokejepsen]

Cool 😄 Look forward to this!