5

The project site will have multiple Image Callouts that will be used in various sections of the site. These Image callouts have multiple forms. Something like below:

enter image description here Questions:

With above representation should I put the Basic one (which has Title and Background Image) in the Foundation Layer?

Create Feature specific to all the individual images and then inherit both Feature and Foundation Interface templates in Data/Content templates - like say one is offer image, another is deals image?

Or nothing will be part of Foundation layer and I have to create Feature templates for all individual images with repeated fields (Title and Background Image)?

Please let me understand how we can represent this is template structure.

EDIT:

If I need to display images something like below, in a single page in multiple sections of the page, will different renderings with common template still look fine with respect to the Presentation details? Also is it possible to make a Image Listing Component (like Deals, Featured Products) having collection of these images? I might be having 10 small images in one component, and 1 large and 4 medium size images in another component.

enter image description here

  • 1
    I don't see any reason in your question to break the code up out of a single feature. All the callouts have a similar purpose. If you take this further and need different CTA structures for different sites in a multisite setup, then you could start breaking it up. – Chris Auer Dec 2 '17 at 0:58
4

Without SXA I would build this as a single feature with 4 components, all based off the same data template.

  1. Create a template that contains all the fields you require. Lets call it ImageCallout
  2. Create 4 renderings that have the razor setup to the 4 different styles that you have specified. They should all use your ImageCallout template as the datasource for the rendering. So you can set the Datasource Location and Datasource Template for a good Experience Editor experience ;)
  3. Make sure these renderings are set as compatible renderings for each other.

Now your content editor can pick one of the 4 styles of the Image Callout rendering and start editing the content. They will only see the fields that are on that rendering, so its not a problem that some of the fields will not be filled in.

But... because they all use the same datasource template and are set as compatible renderings, you can now swap the styles, without having to create new datasources for each one.

As far as Helix goes, all this should be in a single Feature. There is no need for anything to go into a Foundation layer.

  • Thank you. Yes, there is no SXA. But here the scenario is: it will display in Tile format. All the above 4 formats can be next to each other with one being a larger one and rest been 4 smaller ones like Tiles on the wall. Will this still look good? And they alter their positions anytime. And should this be in a specific listing item where they can select/unselect any of these images? – Amin Sayed Dec 1 '17 at 14:27
  • Edited my question. Can you please suggest? – Amin Sayed Dec 2 '17 at 5:27
3

You have more options and they depends mainly on the requirements

Option 1

You can have all fields in 1 template and then depends on the filled fields in preview and normal mode which should be shown, but you show all as editable in Experience Editor. This is a good solution if you want editors to able to change the content dynamicly and you want to use the same placeholder for all of these components.

Option 2

You can have dependencies between modules. So you don't need to touch the Foundation layer. So you can have something like Compontents feature where you can have multiple modules and the modules can have dependencies on each other. For example:

  • Components - Feature
    • Image Callouts - Module
      • Base Template for this module
      • Another Template inherited from the Base Template
    • Image Text - Module
    • etc.

Personally I would choose the first option because it is more flexible from the content editor perspective. Because if you choose the second option then the editors should change the template when they want to show more fields.

EDIT:

Yes, but it's all depends on the HTML. If you need a list then you can loop through of the children of the datasources too.

  • Image List - Datasource
    • Image 1 - Child
    • Image 2 - Child
    • etc...

But you don't need a list, only if you want handle these items together. Because for example in this case you lose personalization. You can only personalize the whole list, not one-by-one.

  • Thank you for the answer. But if I go with option 1, then there are more fields which will remain empty if I just want to display Title and Background Image for some callouts. Is this something not good from the Sitecore perspective? where you should limit the no. of fields that must be blank in the content? – Amin Sayed Dec 1 '17 at 13:44
  • 3
    No problem for Sitecore if you have not filled fields. I think in this specific case, better to have only one template. – Tamás Tárnok Dec 1 '17 at 13:47
  • 1
    While it is not a problem for Sitecore if the fields are not filled in. Having this all on a single razor/rendering would make the Experience Editor fairly complex and also could add a lot of logic to the razor view - which is not a good thing. Razor should not contain logic if you can help it. 4 Renderings with compatible renderings would be a better option. – Richard Seal Dec 1 '17 at 14:05
  • 1
    @RichardSeal it's the developer in us all that wants one view with lots of logic. But I completely agree compatible renderings is the better way to handle that. Especially when working with Sitecore. – Dylan Young Dec 1 '17 at 15:50
  • 2
    @DylanYoung its the architect in us that realizes that's a bad idea ;) – Richard Seal Dec 1 '17 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.