[IMPLEMENTED] Custom Content Field View / Dynamic Value / DateTime Format

[nickconfer]

In ecommerce one of the common features you have is a promo system. In our case we have deals we prepare and show to customers on a sales page that the marketing group will create in advance.

To do this we essentially have a schema that would have a start date and end date field. That schema would be a collection of promos that get added over time. Below is an example of our in house editor.

What I’m wondering is, while I can create a schema with start date and end date in Squidex, to the best of my knowledge I have no way to create a dynamic value field (or a field which is not set in the editor but value changes as requested). I also believe that while we do have a editor url extension to a field, there is no way to control its output in a content list. Apologies if I missed a feature here.

This presents a problem for our setup of a CMS. What I’d like to have is a really good way to handle schema collections that would have start and end date time periods similar to my example above. In the example we actually use that start and end date to also display a tag on each promo.

• Waiting (for when a promo is upcoming and published)
• Current (for when a promo is live to our customers)
• Expired (for when a promo is no longer live)

There are other values, but this can give you the idea of how we might present data based on two values.

I was thinking of how this might be implemented in Squidex in a user friendly manner and I came up with a couple features that might be useful for this as well as a variety of different implementations.

1. Dynamic Value Field Type

This would be a non-editable value that would allow us to tie a url to the field similar to the editor url to get the schema data and return a calculated value. This value would get calculated on each view or api call, etc.

If this were available for instance we could return a string value to signify a status to improve the list view shown in the content editor. This really could be its own field type, or tied to various field types like string, boolean, and tags.

2. Custom content field view

Similar to an editor url, if a field could have a content view url that might be very useful. In this case we could use the view to show colored badges similar to the original design we have. Another use case is someone using the json field type could control the output view so the list value would say something other than <json /> when the data was consistently similar.

3. DateTime format option for views

While a custom content field view is fairly complex, one update that might be simpler and very user friendly is the ability to control the format a date time is shown in the content list view to a user. The datetime value could remain the same for an api/graphql return. In this case for instance instead of Squidex showing the start date and end dates in a list like…

“08/03/2021, 10:00:00 AM”

We could control the string.format value and give them a friendly more readable value like…

“Tues, Aug 3rd 10:00AM”

Sorry to bunch a couple features in one post here, but its all related to the same general idea of giving a little flexibility at the view level.

The main idea I’m trying to solve is to be able to have a collection schema that we could show to the editor role and give them some markers on status. The features I’m suggesting would solve this, but I also think they could be very useful for many other things. Having said that I realize the dev time, potential performance issues. I thought I would make the suggestion though to see if it sparked anything.

[Sebastian]

Thanks for your feature request. It is indeed easier with multiple requests. To be honest I still do not understand your use case. You can also publish and unpublish content items. It would make more sense to extend the scheduled publishing so that you can define multiple schedules.

1. It is somehow possible with scripting:

https://docs.squidex.io/02-documentation/developer-guides/scripting

2. I am not sure if this is a good idea. The only option to implement this is via iframes (this is how custom editors work at the moment). And I am not sure if 100 iframes on a single page are the best idea.

3. DateTime format option for views

I am not sure if I should implement thaat.

[nickconfer]

@Sebastian

You can also publish and unpublish content items. It would make more sense to extend the scheduled publishing so that you can define multiple schedules.

Defining multiple schedules would be one way to solve it, I agree. Another cool example that could be achievable with this setup is having multiple schedules to create themed homepages during the holidays and then switch back, etc.

Main concern I’d have with multiple schedules is having a UI that was easy for a user to understand. I agree though this would be fairly flexible.

One other downside I see to a multiple schema approach is the list view doesn’t really show the dates for this well, you have to click in. The start / end dates make it easy to see all promos and their date ranges which is nice from a UI standpoint. This could probably be solved by nesting the list view. So have row 1 (the original item), and then a nested row underneath for next step with clear date switchover, etc…

@Sebastian

1. It is somehow possible with scripting:

https://docs.squidex.io/02-documentation/developer-guides/scripting

2. I am not sure if this is a good idea. The only option to implement this is via iframes (this is how custom editors work at the moment). And I am not sure if 100 iframes on a single page are the best idea.
3. DateTime format option for views

1. I’ll take a look today and follow up.

2. I agree, and its something I considered when making the request. Only route around it I can think of on my end is to just have it be a script that returns a specified value type (like string, tag, etc)

3. This is something I personally think would be pretty useful. Showing day of week is a pretty common helpful UI to avoid clicking into a calendar, and others might want to format date to match their country, military time, etc… Just gives it a little flexibility. This feature really wouldn’t be useful though if #2 ever had some type of implementation as it would already solve it.

Thanks again for feedback. I’ll check out #1 and follow up. I understand if none of these solutions could be implemented, but just wanted to get our use case out there for consideration. Appreciate it.

[nickconfer]

Just starting looking into scripting again this morning. If I understand it right though, I could only impact the output for #1 on the api return, not in the Squidex UI.

Right now without a further solution the best approach I can think of from a UI standpoint is to create a sale schema with a start and end date, and just show the start and end date in the list they view in the UI. We could then use the API to clean up expired sales for them after a period of time, so most sales on display would be either current or upcoming sales they’ve created.

To give an idea of all time related material we use today, here are the examples I can think of…

1. Sales page with current sales (the photo I posted in the original post)
2. Homepage banner that typically shows a default banner but switches to sales banner on a sale, then reverts back to original banner.
3. Top 2 sales that show to a user in a header bar at the top of a page. The key on this one is we could have 4 sales going on, it just pulls the top 2.

I think all of these instances could be handled by the suggestion you made of defining multiple schedules in the publish/draft system, but I think the UI may be a bit confusing from an editor standpoint. What I was considering was the following…

1. Sales page - have a sales schema with start and end date on creation
2. Homepage - have a homepage schema and a separate sales banner schema. If a sales banner exists during date range, replace the homepage banner defined in the homepage schema. Requires two calls but simplifies publish structure.
3. Top 2 Sales. Pull sales schema from 1 and show first 2 active.

We would likely have a queue job that used the api to clean up the sales and sales banner schema for expired items. In some ways I prefer this route over the multiple schedules. Mainly for 3 reasons…

1. Scheduling today is not as clear in the list view. Multiple schedules would need to be more clear.
2. The homepage banner will change frequently but other content on the homepage will change less often. Multiple schedules could handle this but may be easier to separate it so they can easily update other items on the homepage when they need it without having to think too hard about the schedule.
3. Scheduling happens after an initial save. It would be great if multi-scheduling could be enabled and part of the original creation process.

Anyways, I think you have a good idea with multi-scheduling. It would be a pretty powerful tool, just not sure it fully fits my use case (or anything does for that matter). That’s ok though, I can work around it. I would say out of all the feature requests I gave originally, something like a #3 would be most useful just to clean up the visual in the list view for the editor, but I understand if that doesn’t fit the larger model you are working towards.

In the long term I think it would be very useful to have the ability to set time based scheduling to individual components, etc… I think having a part of a page (but not the full page) on a time based schedule is a pretty common feature, but setting scheduling at the highest level could make the editing process more difficult. This for instance could then let a ecommerce site show a sales banner with one component, and a shipping deadline for the holidays with another, all within the same homepage schema.

[Sebastian]

Let me think about #3. You are very dependent on the UI library here and It could change over time. So the feature is a little instable. But I see the requirement.

Contentful has a a new feature called “Launch”: https://www.contentful.com/help/working-with-release-calendar/

Something like that could be useful for scheduling.

[Sebastian]

Number #3 has been implemented, the other feature requests are not concrete yet. Please create single tickets if you still need these features.