Developer forum

+1

I am looking for something like this myself. 

Adrian

Hi Joakim

The 2 groups are not from the item type - but built in Dynamicweb features for all rows.

You can just add fields to the row item types here:

That said - why would you want a class field on your row (I know why, but I am sure there are other ways to solve the problem).?

The rows are already marked up with class names for item types and themes:

So you can do css selectors like 

.theme-gray .item_swift_2columns_8-4{
    fancy-property:fancy-value;
}

We are currently looking at the customisation options and would like to understand what you need to do. Creating a "Bootstrap editor" in the backends feels wrong, so we would like to understand the need.

BR Nicolai

BR Nicolai

The reason being able to more accurately apply custom styling. Now in the css we have to really nest the styling and target different cases to apply it to the specific element. Having the option to just add a custom class to the element makes it so much easier. Yes what you said works fine, its just I would like to enable this on every row without having to edit every single item_type.

I agree with Joakim.

We have been struggling a lot with various customizations (like adding a border bottom to a row) and the suggested scenario is not flexible enough because is too specific. And we have seen a lot of scenarios where I don't want to add that border to all instances of theme-gray .item_swift_2columns_8-4.

Having an input field on every row and column makes our life a lot easier when customizing stuff. It does not have to be anything else than an input field. The developer should know what class needs to be added there. It can be a bootstrap class or something completely custom. It could even be used to identify a specific element without having any styling attached to it.
And customizing every Swift ItemType does not make sense if we want to keep ugradability of Swift.

Ideally, there should be a way to extend the Swift ItemTypes using the Inheritance method but in a way that would not affect upgradability.

In our case, we have to maintain our customized Swift ItemTypes everytime we make an upgrade. And that's far from being efficient.

Thank you,
Adrian 

You seem to have made this baseline for the Text_Advanced item_type. So making a feature like this baseline for every other row/column item_type should be fairly straight forward. Or make it so we can extend this feature ourselves.

Bump