Developer forum

Hi Adrian

Swift is taking another approach to doing these things - so we are using the columns as components in Swift - and we are looking into making the components much smaller than they are currently for i.e. product detail page, product list pages etc. We have some interesting things in the lab that will make things like this easier.

We will not introduce the blocks from Rapido - they caused a lot of confusion for developers that is not working with them all the time - steep learning curve.

Also I am pretty sure a lot of customisations can be done easily without touching existing features.

The idea and concept of Swift is that each item and template are so small, that if you need changes, it is easy.

We can arrange a session when you have your first project lined up on the things you need to customize and then we can discuss how. Just to learn both ways.

BR Nicolai

Hi Nicolai,

Sounds good. So far, I like the new approach.  My team also had a lot of issues working with Blocks.

Right now, I am trying to figure out how should we define our internal process of customization without losing the benefit of future updates.

One option would be to control the default template that will be applied for an Item. Instead of using the SystemName convention, we can use the setup from the Website settings. Another approach would be to create a Folder called "Swift_Page" and place the custom templates there.

I am already working on convincing a prospect to start a new project with us but we already have a Swift project for Degree.

We can already discuss the potential customizations that we need to make and how it would be best to handle them.

Just let me know how/when you want to have this meeting.

Thank you,
Adrian 

It would be a really interesting session to attend if possible :)
Both to share experiences about the issues you have encountered during the development of a new solution, and to hear how others have solved them, as inspiration for how to solve challenges you have not encountered yet, as well as opportunities you may not have thought about yourself.

Hi Tina

We will reach out to you and we can book a sessions with other partners to talk about customisations.

We also have a couple of things in the 'baking' on customizing Swift templates etc. 

Consider this structure

• ./Designs/Swift (This is standard Swift)
  • Paragraph
    • Swift_Poster.cshtml (This is the default Swift template made by Dynamicweb)
• ./Designs/Swift_Custom (This is custom Swift and overrides)
  • Paragraph
    • Swift_Poster.cshtml (This is your custom version of the same template)

With the concept above - because the template exists in the same path, but in the Swift_Custom context, this custom version will take over the rendering.

If it is not there default template will be used. If you rename it, the site will shift back to standard template automatically.

The idea is to isolate all customisations in the Swift_Custom folder - making it very clear and seperated what is custom and what is standard. Also making updates easier.

 That would be a nice and clean structure i think. 

That sounds great Nicolai :) 

Hi Nicolai,

The suggested approach is very close to what I had in mind. 

Would this scenario be supported if you have multiple websites on the same solution with multiple Design folders?

What I mean is, will the *_Custom convention apply to any Design folder?

Thank you,
Adrian

@Adrian

Yes - it would become a new template context that goes for all designs - a Dynamicweb feature.

One thing we did discus is the situation if you have i.e. 2 websites, both Swift, but with different customisations. If that is even a thing. If we need to support that, we would need to make it possible to override this shadow design from website settings - which might pose some other issues.

Hi Nicolai,

That's very good to know.

Duplication of template folders is usually caused by the need for specific customizations for each website (area).

One possible approach would be to include the area ID in the name of the folder. Like Swift_21_custom instead of Swift_custom.

I am not sure if this means a performance hit.

Thank you,

Adrian

Hi Nicolai,

Another challenge when having multiple websites using the same folder is the customization for CSS and Javascript.

Maybe you should also consider this scenario.

I have seen in other solutions the concept of "Child themes" that are based on a standard theme but would handle the customizations.

Maybe the approach should be similar to the original DW templates logic where you had the default templates in the Templates folder and each Design folder overwrites the default templates if necessary. The only downside of the original approach was that once you create a folder (for example Paragraph) in the Design folder (all templates will be searched for in the new folder. Not just the changed ones.

I hope this helps.

Thank you,
Adrian

Hi,

Since I deal with this day-in, day-out, I am liking this thread :)

I wear a few "hats", so it's normal to be planning projects (including custom work), debugging active projects, anddoing support (from projects built years ago). One difficult thing to do is to assess what's custom on that particular project. It's simple enough with assemblies (we use a prefix for naming convention), but when it comes down to determine frontend work, it's a pain.

Rapido has/had 1 nice thing about it, which were the Custom__Blocks.csthml files (and we named all custom templates with Custom__) + ignite folder + custom.js, so I could more easilly get to customizations. That said, I'd get a bunch of Custom__Blocks.cshtml files that I'd need to visually check that were empty, but it was a great improvement from the past anyways.

Obviously I don't want to jeopardize performance over this, but if we could find a way to make it easy to find out what's custom vs what's standard, it would save people a ton of time.

Best Regards,

Nuno Aguiar

Hi Nicolai,

Any news about the customization process in Swift?

I have realized that "customization" can have various implications, sometimes also in the data structure.

Do you think that it would make sense to have all Itemtypes connected with a Custom Itemtype that would handle additional properties? Or any other inheritance method that could allow ItemType extension?

Thank you,
Adrian

Hi Nicolai,

Is there any official news about this type of "custom theme"?

I have read various posts about related topics but I can't find an official documentation of the feature and the limitations?

Thank you,
Adrian