Developer forum

Hi Justin,
I am happy I am not the only one :)
I have had the same thought in this post: https://doc.dynamicweb.com/forum/dynamicweb-10/dynamicweb-10/gridrow-customizations

I have just noticed that we need to either add a custom template if we want anything extra (like border or padding), or use custom ItemTypes, or create new CSS rules for each Row Instance.
We are now trying to use the themes for this purpose, but we'll end up having duplicate themes just for rounded corners.
I totally get the need to move some configurations to custom templates, but I still feel that some configurations should still be available. Maybe hidden for regular admins. Or at least on option for me to decide if I want to extend a standard object (like a row) without customizations in the templates.
Maybe if we there will be more partners feeling the same way, we can find a common ground for these needs.

Adrian

The content area in Swift 2 is made for editors with no coding knowledge. That covers pages, rows and paragraphs so we intentionally keep this part of Swift free from as much coding related things as possible. This is described here: https://doc.dynamicweb.dev/swift/getting-started/s1-vs-s2.html

CSS etc. are all frontend developer related things. It will not be added to the UI for editors.

The correct approach is one of 2.

- Create a specific row deifinition or paragraph layout for your use case
- Create a css class that targets the specicifc setup automatically

There is a number of examples listed on this page: https://doc.dynamicweb.dev/swift/customization/design-css.html#examples-of-using-swift-attributes-for-targeting-css

Swift 2 is also greatly extendable - so if your customer wants a HTML configuration user interface, feel free to extend with item fields so the user can insert paddings, margins, choose css classes and other html related work.

BR Nicolai

Another thing - it would be easier for you if you do no force your design into Swift, but force Swift onto your design.

Swift is not a "design exactly what you want tool". It is a "get a nice website with my branding and good editorial expérience in a short time" tool.

If rounded corner of a row on one page is key to your customers revenue - then customization is the way to go.

Hi Nicolai,

If "force Swift onto my design" would be as easy as it sounds...

I agree that design itself won't do anything for the overall revenue. But customers don't just buy a tool. The things we build for them are also tightly connected to their brand image, and they want to feel attached to it.
We can do a lot of crazy stuff to optimize their online business. But very often, we don't get to talk about it without getting the design part out of the way.
And in an increasingly competitive world like the e-commerce is, functionality alone is not the ace of all trades. We are targeting high-profile customers, asking them to pay top dollar for this solution. If their marketing asks for rounded corners, you can be sure that we will deliver it. The question is not if we will have to support all crazy requests related to design. But how hard should it be to implement and reuse code? If we end up with 40% custom templates in every project, there is no economy of scale.
I still feel that a separation of fields between developer/implementer and Admin would be a good approach. You used to have something similar in Rapido for the color swatch, and probably for the same reason.
I know the above is subjective and based on my experience so far, and most probably won't apply to everybody.

Thank you for listening to my rumbling :)

Adrian
 

Hi Adrian

In our QA we can mimic any brand out there so it is hard to tell the difference. Yes, it might not have the exact round corners here and there - but the brand is distinctly there. It is how one approaches the task and how one allow one self to get as close as possible with the tools at hand - and not think back to the times where everything was handwritten and we spent weeks cutting out PSD files to html.

In an increasingly comptetive world, you will not want to waste customer money and time on rounded corners on one page for one piece of content configured by a developer. You will create a strict repeatable design concept that an editor can use to create nice content fast without help. If they have a very distinc brand feature that is used throughout the site, it is easy to either add the CSS that automatically adds the branding or create a custom row or layout so it can be re-used easily. It is not to have a field where you can choose something that might work if you have chosen a layout that supports it etc etc.  

In our own marketing that uses Swift 1, they have several home brewed word documents and yellow notes on their desk so they can remember what to do just to post a simple piece of content - and after they have created it, they come to the Swift developers and ask for help to do the 'frontend work' of filling out the paddings, margins, handling repsonsiveness etc.

Both Rapido and Swift1 has suffered the death of complexity following all kinds of "Customize anything with checkboxes" and "super smart compentent re-usable templates" feature requests and ideas. It is a dead end. Complex component structures, loads of checkboxes and settings - that all has to work in combination in one template that includes another that includes another that executres a component with another component is not smart - every time we have to spend 5 hours even understanding how a simple piece of content is rendered. The amount of combinations on e.g. "TextImageAdvanced" is in the millions and it is not testable nor usable. And on top of that, all of this complexity cannot perform as well as simple structures.

Adding more settings to rows and paragraphs will not save your customer money. It will be super expensive. A developer do not need new fields - if you need a developer to fill out fields, they might as well do it in css files. If your customer need a developer to configure a piece of content to look correct, we have failed big time.

Row tepmplates and Paragraph layouts in Swift 2 are super simple - you can modify them really fast - you can even do it with copilot/cluade/chatgpt etc. And the content editor will be able to use them without help. These things are structured in a way so you do not need to customize anything. Just add a new layout template - done. Just add a new row definition - done. Just create a new content item type and some layoputs - done These customizations are only adons, not customizations - and will touch nothing in standard Swift and make your solution perfectly upgradable.

Yes, I understand that we might have a piece of markup 5 times in the same folder. But it takes me 30 seconds to understand and copy paste that once in a while compared to spending hours to figure out how things are entangled in a re-usable components and concepts - and if I touch one thing it affects eveything. Impossible to be in. 

Do not make things more complicated than needed. Embrace this appraoch and not the approach of gone concepts. Or use Swift 1 instead. 

I will be more than happy to jump on a work call on solving specific design implementation tasks on Swift 2 and work with you to find common ground.

BR Nicolai

Hi Nicolai, 

I agree with almost everything you said. I am not a big fan of Swift 1. I did like the Block concept of Rapido, but that was also very complicated to understand.
I don't want to go back to Swift 1. I understand all the challenges of having too many options to choose from. We have learned it the hard way long before the release of Swift 1.
I am just not a big fan of all-or-nothing. And I am also trying to save customer's money.
It is true that duplicating a template is easy and will probably (sometimes in the future) be easily automated using AI agents. What I want to avoid is moving the mess from configurations to the list of custom templates.

For now, the only things we are missing (but we have already found solutions for) are the paddings of the rows and the ability to add a custom class.
But I can totally live with our current solutions for these shortcomings. And if I am the only one with this problem, then clearly the issue is with me and not with your solution.
I will check with my colleagues if it makes sense to waste your time in a meeting to discuss further.

Thank you,
Adrian
 

Well, you have not shown me what problem you are trying to solve - only the solution you think we should add. It is not all or nothing. It is Editor vs. Developer - and css and html attribute fields on content sounds like a direction that is not laid out for Swift 2.

I am not saying we have the perfect solution, but just adding settings from Swift 1 to Swift 2 without analyzing the 'problem' is not going to happen.

If you have added fields for padding  and css on rows, my opnion is that is not the optimal solution for a content editor. It is fields for a developer - which you are welcome to do, but I will go extra lengths to avoid that in standard Swift. And the only thing I am saying is that if you insist on adding code to content - it will be custom. If you want to solve a general layouting limitation, I will be happy to look into it.

I agree. I should have provided more context about the use cases.
I went straight to the technical solution because I thought that if the Row functionalities were extensible, there would be no need for you to change the standard approach; it would be up to us to create a new provider or extend the existing one.
And yes, it is a debate about how much can/should the editor do in the interface. Clearly, Swift 1 is not the answer. We all have been there, and we know the result.
In my case, it all started when I tried to define a very simple demo and I have noticed that all rows on all product components don;t have any padding and there is no way of adding it without messing with the css or the template. And I am not talking about the padding level, just plain padding.
Then, we had some situations where we had to add rounded corners to some elements. And those elements were not aleways with rounded corners (I know, it is a consistency issue) and we had to create custom template for with and without rounded corners.
I am not saying we cannot live with how it is right now, it is probably also a matter of how we used to do quick demos with Rapido or Swift1 in the past (without a need for a developer).

I will debate more with my colleagues (we also have different opinions about this), and we'll resume the discussion if needed.
I am sorry for wasting everybody's time with this topic :(

Adrian
 

Hi Guys,

I wasn't aware of the discussion you were already having on this topic. In my case creating a row definition would work fine, just wanted to check if that is the right way and I did not mis something.

Apologies for re-opening the can of worms :-)

Cheers,

Justin

The discussion is valid and very important, so no problems!

@Adrian

The rows, including on the product list, you can control the spacing alos for the product components - see below.

The product list has a class on it called "product-list" that can be used to target styles specifically on that element and its childre. At least as easy as creating a CSS decoration in Swift 1 which would also require you to do CSS.

Hi Nicolai,

I am aware of the vertical margin.
What I am missing is the horizontal padding/margin.
But don't spend too much thought on this matter. For now, we have created our own Row definitions and we have solved it.
If there are other partners/developers missing this feature, of feeling that using a custom row may have a big impact on reusability of the code, then we can resume the discussion.

Thank you,

Adrian
 

Hi,

• My understanding from this thread is that what we might need is a way to identify a Row (eventually a Page as well) so it's easier to create some custom CSS and/or JS for.
   
• There is a geniune need to make customizations simple to do
  • And if we can avoid custom Row definitions, then we stay more in the upgrade path for Swift
     
• Developers would be happy to use data attributes to identify said pages or rows in their CSS and JS
   
• The challenge is identifying them
  • Using IDs seems "simple"
    • But then we get a lot of div[data-page-id="123"] { ... } css that is hard to relate to
      and IDs may change between environments (development, staging, prod)
  • If there is a way to get a reliable/custom identifier the developer could then use it accordingly
    • The analogy that comes to mind is the "NavigationTag"
    • We can set it to whatever we want
    • Imagine the navigation tag were to be rendered as a data attribute - then you could develop css and js for it
    • Using an approach such as this, then we could identify the rows that require customization

I know this introduces a free text field that is meaningless for true content, but could be key to support customizations without a lot of overhead (in terms of creating custom item types).
 

Thoughts?

BR
Nuno Aguiar

Hi Nuno,

As usual, you summed it up perfectly. At least what I had in mind :)
The simplest thing would be an option that is accessible to the developer to add a dedicated identifier. It can be a class, a list of utility classes, whatever.
This way we still give the developer the power, but it can be easily reusable and easier to identify the element you are styling.
While thinking at this subject, another (more complex) way would be to have a generic property on an item, that would read data from a dedicated config file (JSON) with a few properties and store the data as JSON on the item. And we can then access that data to do whatever we want with it in the template. It is, of course, a bit more complex implementation, but it would open up the ability to reuse the standard ItemTypes while still having a layer of minimal customization.
Of course, there could be a lot of good ideas around this, but the simplest thing would be an input field, either visible to all or limited to specific roles (Admin is the first that comes to mind).
Thank you,

Adrian

Hi Adrian,

• The upcoming Categories and Tags on pages could partly solve for this
  • But wouldn't solve for Rows
  • And "forces" you to include/exclude a category by "convention"
• Using data attributes is a more modern way than css classes
• Ideally a dedicated property can also be identifiable in the ViewModels (Page and Row and wherever else)
  • And could be also returned/identified in the webapi making any headless development or AI-driven tool a bit more aware

Let's see if this helps stir some other ideas

// Nuno

You guys are unbelievable. You are trying to change oil and install a turbo on an EV.... In my mind you have lost the fact that a regular person with no coding skills will be doing the content of the page. And you insist on doing things like you did in the past and not diving into the thoughts and concepts in Swift 2.

You use the word "developer" over and over again. Rows and paragraphs UI are for content editors. They will not need weird fields to write weird strings in. Developers can go into a code editor and do whatever they want.

You can go down this path - or you can call me when you have designs to implement where you believe your thoughts are the only way to go and we can have a practical look at how to solve it in this new concept. But only if you open up....

We have QA'ed and implemented a number of brands with just one row - and it is definitely doable. Adding distinct visuals without secret input fields on rows and pragraphs - also defnitely doable.

Adding new visual features to rows (or paragraph layouts for that matter) is super simple without touching a single standard Swift file and have them show up in the UI for the content editor. You simply add your own row definition file and call it whatever you want:

{
  "Id": "myFancyCustomRonderCornerRowWithBellsAndWhistles",
  "Name": "My custom designed row",
  "Description": "1 column destinct designed row with rounded corners",
  "Template": "Swift-v2_Row.cshtml",
  ....
}

Then the content editor can choose this - it even uses the standard row template - I guarentee that you only need this one row template in 99% of all situations and in the last 1% you either spend 2 seconds creating your custom row template or talk to someone to stick with what is possible (not what you believe is possible, but what I believe is possible) using the standard template.

A row definition like this one is a stand-alone file - you simply add it - no touching of existing files. Then add whatever CSS to style that row - or all the content inside that row. That is not more complicated than a weird freetext field on rows and paragraphs... Which would also require CSS.

Adding a CSS related field on content so that your CSS will not look like data-swift-gridrow[myFancyCustomRonderCornerRowWithBellsAndWhistles] but instead .myFancyCustomRonderCornerRowWithBellsAndWhistles is not a very solid argument...

Giving a content editor of list of class names they can add to a field so CSS is appplied is not less custom than adding a row definition file or a paragraph layout file - that again will not touch any Swift files.

You both have yet to show my a layout of something that is not doable in this new concept. Give me examples of what is not possible, and I will bow in the dust if a CSS field on rows and paragaphs are required.

@Adrian - rows also have horistontal control - not padding/margin as that is a 'thing of the past', but X and Y gaps controlled by the container width. This is to have a more modern approach to handling responsiveness using css grids. The product list with components is still a spill-over from Swift 1 and has its caveats - but I will be happy to show how one line of css can control anything on e.g. the product list in this regard - including adding padding and margin if that is really the need - based off the existing UI control for setting container width.

BR Nicolai

Hi Nicolai,

Ah, I think I understand what you mean now about the row definitions. The ID is rendered in the template as a data attribute - that’s the piece I was missing. In one of your earlier posts, you did link to the documentation, but as I read through the thread, I didn’t actually click on it. It wasn’t until you shared the row definition code snippet that it really “clicked” for me. Sorry about that.

With that in mind:

• No need for custom templates - which is a definately a win
• I see Adrian’s point about having two rows that look alike but have different names (and IDs). That said, it also enforces consistency and helps prevent customers from requesting too many variations, so I think it’s a good solution for now

As for the examples you were asking, I'm suffering from "Source amnesia". I know I've had this issue multiple times, just don't remember where right now. In either case, it's not important at this moment, because I see your point now and agree with you (until a customer or partner decides to make it their life’s mission to get me to change it 🤓).

Best Regards,

Nuno Aguiar