I am developing a webapp using Cakephp. I have created a default layout for the website. I created sections like header, footer, content.
Now some of the pages in my content section have same structure. These are part of a controller with various views defined for each page. What view template should I be using here? Layouts or Elements?
In case I use layout, I will be using the controller to decide the layout I will use, but won't that change the layout for whole website?
Regards
This is really a matter of preference. I try to think of layout as the "structure" of the page -- so a header, placeholder for left nav, placeholder for top nav, footer. That kind of thing. I define those sections in the layout.
I'd recommend the "pages in my content section [that] have the same structure" be your layout. As you mentioned, you can switch layouts in the controller, but any similarly structured pages (pages that will look the same as each other once you've removed the content) I would have share a layout.
Another example of layout switching could be for logged in versus anonymous users. For a logged in user, websites frequently put a "Welcome, $name" message at the top, along with links to My Account, sign out, etc. I often find myself using a different layout for logged in versus anon users. ALso, in that situation, I use the beforeFilter() method to set the layout for a given controller, since I know whether the user is logged in or not when that callback is executed.
Sorry for the rambling, but this is a bit of a gray area (when to use a layout versus different elements).
Related
I'm new to Sitecore XP 8.2 and try to study by articles and youtube.
However, I can't figure out why we should use datasource, instead of having multiple items in the content tree? How can I enable Global on the content tree?
If you by 'datasource' means 'Rendering Datasource Location' heres a real life example, where using datasource is helpfull, instead of having data items underneath each page item.
Lets say, you have a Footer module, which you would like to include on all content pages in your website. And the Editors should be able to change the content of the footer module on all pages, but the effect should be global.
In this case, could a solution be, to make a folder at the top of your tree structure called 'Shared Modules', and point the 'Footer Rendering Datasource Location' at this folder.
In case an editor changes the footer text on the main page or a subpage, the effect will allways be saved in the same location.
unlike, a 'Texbox module' which you would like to have multiple of on multiple pages. these would you like to have placed underneath each of your content pages in a folder e.g 'Page Modules'.
You can use Sitecore Datasource for a variety of reasons. One of the reasons is to use this instead of context item so that you can refer to another item in Sitecore content tree. Another good reason is to personalize your content or run the A/B testing, content testing. Using Sitecore datasource, make different parts of page componentize and all this helps content editor to improve experience in content editor.
For some good information on using Sitecore datasource, you can look at
https://www.linkedin.com/pulse/how-improve-experience-editor-sitecore-number-ways-rohit-chopra
https://www.linkedin.com/pulse/sitecore-personalize-content-conditional-renderings-sub-rohit-chopra
In short, with datasources you can re-use your items, makes your life much easier if you want to go with personalization and its easier to manage in terms of security/workflows.
A datasource is a pointer from your presentation to a content item. This item can easily be picked from a global or local placement in the content tree. You can still navigate from the datasource to other items (like subitems) if you want a more complex structure for your content.
The advantages of using datasources, is that Sitecores presentation engine, Experience Editor and marketing/personalization is based on the usage of datasources. Further you cater for reuse of content, as multiple presentations can point to the same datasource item.
By using datasources you decouple the content from the structure of your content tree and hierarchy.
In Sitecore I have created base Template & Renderings for "Header, Top Menu, Logo, Search ,Login Button…etc that comes in Header across all Pages of the Site."
Also the same template & Rendering is using in other website so we can't set value in Standard field.
Now the problem is “suppose we have 100 pages in a Site then each page we have to go and add/update rendering & data source.
Is there any way that a “Header rendering” contains child rendering and by placing “Header rendering” render all its child renderings.
Header Composite Component ===>
Logo Component
Top Navigation Component
Search Component
There is a composite component module on the Sitecore Marketplace :https://marketplace.sitecore.net/Modules/C/Composite_components.aspx?sc_lang=en
This fill's your requirements exactly.
It works by creating a "Composite Component" item, then you add your renderings for your header to that component. E.g. Logo, Navigation etc...
Then in the standard values of your page templates, you add a new Composite Component rendering and set the datasource to the component item you created.
The module will then inject the renderings from the component item presentation into your current item. So you only have to update a single place to update all pages etc...
I have this running in a few production sites and it works well. It even supports the Experience Editor.
I don't think there's a solution out of the box. SxA solves this with Partial and Page Designs at site level. Just wrote a blog about it:
http://reinoudvandalen.nl/blog/sitecore-experience-accelerator-partial-designs-and-page-designs/
I also made something that might help you: Partial Layout Presets
http://reinoudvandalen.nl/blog/sitecore-partial-layout-presets/
It even allows you to store presets per site, but keep in mind that it injects composed layouts. If you modify the preset then it does not get applied to the pages where it was injected (though you might be able to pull something of with a shared datasource per site).
Lastly the obvious solution would be to create a page template per site so you'll be able to have standard values per site.
You may want to take a look at using Placeholder Fallback.
This will allow you to add components and renderings to a top level page and then the child pages would "fallback" to using the renderings inserted into the placeholder of the top level page in the item hierarchy. The editors can also insert page specific renderings on each child page if required.
If you do not want to custom code and only out of the box features then you could use Devices. You can find more information in the documentation about Set up a device layout. Once the device is created you can specify a different default device per site:
Now when you open the Presentation Details on the __Standard Values of your templates you can specify a different Layout or Renderings per device, i.e. different ones for AltSiteDevice
In the Aurelia SPA template it assumes that every page will be inside app.html and use the same nav-bar at the top. But I'll have many pages that don't want the nav-bar at the top and actually not use app.html at all. I was looking at main.js and it looks like I could hook into bootstrap() and change the aurelia.setRoot() for certain pages (I'm just guessing here), but then I start mucking up the main.js file and it won't be long before it gets really messy and maintenance headache. I really just want to have some pages use their own format altogether and ignore the app.html formatting without doing any crazy configurations.
My initial thought is maybe app.html should just be an empty file and make every page decide whether or not it wants the nav-bar and include it on the individual pages. But now I'm duplicating the code across many pages and if the standard page layout changes I have to change all the individual pages. Not sure the best way to go about his. Any suggestions?
I actually disagree with Gilbert's answer. Using .setRoot is a best practice; the root is just the parent view/viewModel pair and you will often have different parents. This is essentially what you're doing when you're creating an empty app view/viewModel, creating a new parent that doesn't do anything. But adding an unnecessary, unused layer is just extra complication.
One of the best use cases for this is a login page. The login page is totally different from your normal app page--there's a login prompt, no navigation bar, etc. Therefore, make a "login" app root and a "app" app root and switch back and forth between them. I've built a template called Sentry that demonstrates how to do this.
Sentry in action
Sentry on GitHub
Using set root, like you said, is a bad idea. Similar to what you said, you can make app.html contain just the router view tag. Different parts of your app, that you want to share a similar page layout, will be gruped under different routes. Now each of theses routes will point to another router that will have its different styles in the view
Just think of it as an empty app.html with child app.html's that have styles in them(e.g. Different navbars, page layout etc)
I am building a brand new website in Sitecore and I am looking for advice on the following scenario:
My site has 2 version of its homepage. Both are quite different. The layout is the same, but most of the components and sublayouts on it will change depending on whether the user is logged in or not.
Does anybody has a suggestion of a good practice, or way to do that in Sitecore? My basic requirements are, have a single URL for both (the website root, it is a homepage) and do not harm the content author experience.
My thought so far was:
Use of personalization to control the components to be displayed (Concerns: performance and the content author experience he woudnt have to change component by component to see both versions)
Use of two item in the tree and intercept a pipeline to resolve the right item at the right time (Concerns: the content author would have two home items to maintain *not actually a big problem)
Does anybody has any other approach or considerations on those I listed?
Thanks
An alternative solution would be to make use of devices, and use a pipeline to switch devices if the user is logged in.
Set up your Device in Sitecore to use the default layout as a fallback so it does not affect other pages in your site (and they continue to work as expected). You are then able to set different sublayouts and components for that Item (directly or in Standard Values for the template) for each device. You can make use the VaryByDevice caching option to make better use of the Cache.
Your content editors can also switch between the devices easily in the Page Editor from the ribbon. Any further customization you need in other areas of the site, such has switching out a single component, can be run using a Personlization Rule taking advantage of "where the current device compares to value".
It does sound like you have the need for personalization based on authenticated status, so I would recommend staying with the built-in personalization interface to avoid confusion. Authors will have been trained during Sitecore training on how to use personalization, and introducing an alternative method for accomplishing the same thing could lead to a less-than-optimal experience for the author.
To address your concern of the author needing to view components by toggling each one, I would recommend installing the Experience Explorer module. You can create presets that meet your rules on your presentation and then the author can preview the site for different 'experiences'.
If you have a single URL for the home page, it is more straight-forward to go with a single item, so I would definitely advise against having two home page items that are being resolved by the same URL.
You mentioned a concern for performance, so I would recommend you making sure that you enable your sublayout caching settings. In your case, varying by Data may be the way to go, given you would personalize with two sets of datasources.
In the past I have used the following crude technique:
Make two components, one for "logged in" and the other for anonymous.
Each rendering has just one line, a single placeholder, either:
<sc:placeholder key="logged-in" runat="server" />
or
<sc:placeholder key="anonymous" runat="server" />
For "logged in" I make a personalisation rule which hides the component if anonymous, and for the anonymous component I make a personalisation rule which hides the component if the user is logged in.
I then nest all the components under the correct placeholder key.
I'm a little confused with the way Magento implements web pages, and I'm hoping someone here can help me out.
I've figured out how to adjust themes and templates, etc., but I'm wondering how I implement content with them.
There is a disconnect in my understanding of how to put content into a page. Is this done with the layout and template files, or is this done on the cms page?
I've been searching for tutorials, etc., and I'm having trouble finding them (maybe I'm using the wrong terminology), so if you know of examples or anything that might help, I would really appreciate it.
Thank you in advance for your help!
Magento design/template is a broad question, which may appears tricky at first, but so logical and powerfull once you get to know it.
In a nutshell, the .xml layout files are responsible for defining the content, and the phtml (in relation with their Block classes) actually render the html. Everytime a page load, all the layout files are parsed to retrieve all the blocks which have to appears in this particular page.
The content loaded in each page is defined by the handles in the layout files, which correspond to the module/controller/action. For example, the content of the customer's account index page (which is the result of the index action, of the Account Controller of the Customer module, see the logic of the handle's name) is defined by:
the blocks/layout defined in the <customer_account_index> handle of app/design/PACKAGE/TEMPLATE/layout/customer.xml
the blocks/layout defined in the <customer_account_index> handle of all other layout files (I'm not saying that all layout files have a <customer_account_index> handle, but those who have it, like poll.xml, will insert their content)
the blocks/layout defined in the <default> handle of all other layout files, that's why it's called "default" :)
When you say:
is this done on the cms page?
I assume you're refering to the cms in the admin: this only take care of the content block of the static pages of your store. And the rest of the page is still defined by the xml (the page.xml handle of the cms page's layout (1 column, 2 columns-left, etc...) handles like <default>, <cms_index_index>, etc...) But even there, you can modify the layout by putting content in the proper textareas.
Here are some interesting links to understand the magic of Magento's layout:
Demystifying Magento’s Layout XML
Magento for Developers: Part 4 - Magento Layouts, Blocks and Templatese
No Frills Magento Layout by Alan Storm
Designer's Guide to Magento
HTH