Calculated Field

[ns8482e]

There are places where property is auto calculated. Like Path property in AutoroutePart or Title in TitlePart but all these example I could find in source code are for ContentPart.

Is there a way to have calculated Field for metadata content type? For example, In Admin UI, creating Person content type with Name, BirthDate and Age, where Age could be calculated field based on BirthDate entered?

[deanmarcussen]

Generally you have to make a field / content part that takes a liquid pattern to do this.

Then you can call await _liquidTemplateManager.RenderAsync(pattern, NullEncoder.Default, templateContext); in the driver.

But you could also do this on say a TextField or DateField by implementing an editor option, where you could render the pattern, and make the pattern based on other content. So calculated with liquid.

I think it might be useful to have an editor option for at least the TextField, and probably the DateField as well to do this oob.

[ns8482e]

Liquid templates are great, but then I need to create custom part. Just wondering is there any other ootb option available ?

Can the field be calculated using workflow?

[Skrypt]

You can also use a ContentFieldHandler, a ContentPartHandler, a ContentHandler to alterate the data on UpdatingAsync.

if(context.ContentItem.ContentType == "something")
{
    //do your thing
}

[ns8482e]

ContentFieldHandler

Is there Handler for Field? I could not find any code with "ContentFieldHandler"

[Skrypt]

Maybe not. I was probably wrong.

[hishamco]

Generally you have to make a field / content part that takes a liquid pattern to do this.

What about those they are like Razor?

[hishamco]

I'm not sure if we can have a notion of CalculatedField that allow us enter expression that will be calculated each time the content item is retrieved

[Skrypt]

You can also look at Aspects as this is probably another alternative. Search for BodyAspect for example.

[hishamco]

I saw it when I created the CultureAspect but how this related?

[Skrypt]

Well the BodyAspect is coming from a Field normally that should be the HtmlBodyPart or the MarkdownBodyPart but the BodyAspect can be a combination of both. So it is a "calculated" Aspect. In this case we have a AgeAspect calculated on BirthDate entered. So he could have let's say a BirthDatePart which would return a AgeAspect ...

[hishamco]

Got it, thanks for the clarification

[sebastienros]

I like the idea of a "templated field". Note you could already do it with a custom workflow and existing fields. Having a field instead of an Aspect allows for querying and filtering for instance, so that's a valid request.

We could do it as an editor on the TextField, but then other fields might also want it. So I assume a compromise is to create a custom "Templated Text Field".

We could also add options to most fields like the Default value, that would be a liquid template, and this way we could create these values for any kind of physical type (date, numeric, text, ...). Also an option to not render the editor, or to render it in read-only. But that's a lot of options on many fields.

Maybe start with TextField ? And use a custom editor that would have the "hide/readonly" options, and the template. Also a custom handler to only assign the value based on this editor when the item is updated (such that other fields are updated before). The driver might provide access to "Updated" though.

[ns8482e]

How about having a feature like event trigger that allows user to define custom script to execute and in that script user can use any field/part that can be updated or even other content item?

Similar to Login Script feature

[sebastienros]

That's the Workflow feature, literally

[ns8482e]

That's the Workflow feature, literally

@sebastienros may be its related to workflow

However this could be used without workflow module and not use workflow UI to configure. Analogous to database triggers - e.g. events./triggers for Content Type that runs under same db transaction for the content type being updated?

[Skrypt]

That's a ContentHandler I think. Though there is some good ideas in there that might be worth some second thoughts.

[sebastienros]

I concede that many feature could be done in Workflows, but we need to provide other ways to configure them. I think @MichaelPetrinolis had come with a feature to provide special webhooks natively for instance. Or scheduled publish/archive that could be integrated directly in the editor.

Reflecting on that I think I am pushing too much into not doing more "dedicated" things by fear of having the maintains too many things, or seeing people having too many options to do the same things and getting lost. Also having "predefined" knobs when you create a custom feature to do things that can be done in a workflow means that a user might get blocked eventually, and have to switch completely to Workflow, or even worse: code.

You might remember these discussions about Tags, and whether they should be their own concepts of be based on Taxonomies.

Maybe a good compromise in this case would be to provide a feature that would act as a Wizard to generate a workflow type. This workflow would be "hidden" in the default UI, as managed by another feature. And some user could decide to just "clone" this definition in case they need more customization. Maybe not even hide it, and just have this wizard explicitly generate a workflow definition. That is a concept that sounds really nice actually. We could also thing that this wizard could keep some state with the parameters that were used, and store these parameters in the workflow type, such that one could change the parameters after the fact, without having to edit the workflow directly. Or even if the workflow was edited, these parameters would still be changeable.
That would also work with the Webhooks module that I mentioned earlier.

[sebastienros]

For instance, we could then create a Wizard to generate Content Validation workflows with specific users/roles and email templates to generate a workflow automatically. The idea being that lots of types of workflows are very common and we could "industrialize" them, exposing specific parameters to vary them.

[Skrypt]

You mean Content Approbation / Approval?

[sebastienros]

@Skrypt yes, as an example of some common things people might want to do, and that can be done with WF

[Skrypt]

But for the current request "Calculated Field" could it be a simple example of how to simply apply a calculation on a ContentItem Field? A Wizard that allows you to pick X Fields of the same type and apply some "calculation" on them ; stored in a Y Field (which would be indexed in Lucene too).

[sebastienros]

For a calculated field, you could select a type, a field name, and what liquid or javascript expression you want. And also a step, like published, updated, ... This would create a workflow for you. And you could change the parameters in the wizard which would then update the workflow (at least some constants in the workflow)

[Skrypt]

From the Content Type/Part editor page!

[sebastienros]

No from the "newly created" Wizard page, selecting "Calculated Field" would give you a custom UI to select an existing content type and a field. Like the content type picker.

[MichaelPetrinolis]

@sebastienros I think you are referring to the #2323 by @jrestall regarding the web hooks module :)

[deanmarcussen]

Wizards are sound great.
Workflows can be a bit hard to get into so it’s a good way to make them more accessible.

Sounding a lot like a nice ui interface that takes some parameters and applies them to a small recipe step that would creat the workflow.

Should be easy to maintain if it is just wrapping a lot of what OC already has.

Would also give us a good place / way to supply sample / wizard recipes that help setup common things not just workflows