I'm hoping my cryptic title isn't too cryptic, but I'll try to explain what it is I actually want to do.
I have a master page 'A' which has child pages 'B' and 'C'.
This is implemented with the standard master page model in ASP.NET just fine.
My site has two themes 'T1' and 'T2'.
They actually represent different partners, T1 being our own company and T2 is a partner.
I want to display specific things on pages 'B' and 'C' depending upon which theme I'm using. For instance I may want to insert additional buttons or graphics on page 'B' specific to partner for theme 'T2'. This content would be at an arbitrary point on the page depending upon the page itself. Some partners may not even use this feature.
The problem is I want to do this as declaratively as possible, and minimize the knowledge that the pages have about the theme.
This is where the 'reverse' master page concept comes in. I want to define an area on a child page into which 'theme' specific content can be inserted. (I'm saying 'theme' because thats what ASP.NET uses - and most likely what I'd tie the content to).
So you may be wondering :
Why can't you just use a master page for this and add extra content sections? Reason is that the content may appear anywhere on the page in a location that is specific to that page.
Why can't you use a 'nested' master page? Essentially the same reason.
Possible solution:
I'm wondering about creating some kind of user control that would have a textual key representing what type of content would be inserted there. The user control would have to know what to display for each 'theme' - probably by dynamically creating the relevant additional user control.
This seems a little clumsy - so I'm wondering what kind of solutions others may have created for similar situations.
you can use CSS to position your content sections anywhere on your page. so i wouldnt worry about page locations, etc.
if it were me, i'd just dynamically load the 2 different css files into the one masterpage and based on the same logic render the different content into the placeholders.
I'm currently working on a site that has similar requirements that are too much for CSS. In one layout the login is horizontal towards the top of the render order, and in another its in the right hand column.
We're using standard ASP.NET themes to push out CSS, logo URLs via SkinID, etc.
To obtain the custom layout I've created a "Loader" control that loads UserControls via a list specified in a Loader attribute. The attribute can be defined directly in the loader markup, or via a .skin file in the theme.
Each key in the list is just the base name of a UserControl (I add the path and extension). The controls are created via Page.LoadControl().
Do you have fix layout for different partners ? Or do you want the partners to choose the layouts on runtime ?
If the layouts are fixed than 1 way is to create zen style CSS (http://www.csszengarden.com/) and than dynamically load it as per the client/partner. If you want the partners to modify the layouts on runtime than probably you might want to use Webparts.
Hope this helps.
You CAN use nested master pages in VS2008!
See here --
Scott Guthrie's Blog
Related
I have been doing typical menu from code behind where i just show and hide divs based on their role but code becomes very long cause i have to hide every single div of each role for each user.
My question is... Is there a better practice to do this? I also just found out about Login View, is this the way to go in Web Forms?
Your code behind should not take the responsibility of altering how the View is displayed, that's the job of the view (and that's why asp controls exist).
One approach would be to have a logic that builds up a List and this list is passed as DataSource of an asp control.
Actually there's a good control that allows you to iterate a collection of elements defining a display template for each element in that list, here you can find the details:
https://learn.microsoft.com/en-us/dotnet/api/system.web.ui.webcontrols.repeater?view=netframework-4.7.2
I hope this sets you in the right path.
A common way to do this is in a WebForms app is to use a SiteMap.
A site map can be linked to roles, so that only those elements that are accessible for a user's roles are displayed. And recent versions can be made to display reasonable cleanly, as divs that can be styled how you want (the original version generated a lot if inline styles).
For an MVC sitemap there are similar solutions, such as this one.
I have few queries regarding CQ. Your reply will really make the difference to my understanding.
1) Why exactly do we need template when what all template do is to have a resourceType property attached to a content-page component. At the time of creating new page, shouldn't authors directly select that component ?
2) In other CMS like Vignette, content authors create the contents separately (not directly on the page) for ex. products details and then those contents are iterated / processed to display on the page. But in CQ, the scenario is other way round. Authors directly create the content on the page. Now if same content is needed on other page, how will that be re-used ?
3) For pages like product details, there is a fixed structure of the content like product image, description etc. Now if there is parsys component used (widely used in geometrixx demo site), there will be possibility to add the any of the allowed components in any order in parsys. Will not this create content chaos ? OR it will be author's responsibility to add it as needed by page structure ?
Regards,
Ronak
1) That is actually a good question, it would make more sense to somehow identify a component as page template. Though there is one reason for a template: The developer can already have some properties and even components within a parsys preset.
2) There is a Reference component in the foundation components which is for this exact use case. Within the dialog you can select any component from any other page. So you can create a dummy page outside of the navigation with frequently used text and reference them when needed.
3) That is always the problem between defined structure and author freedom. Each customer has to decide what is best for him. Though usually I end up having to give the author too much freedom for my liking: Welcome the infamous HTML component, because some marketing guy will have a fancy campaign online within 2 days...
EDIT (As requested some more detail to 1):
In many projects I have a rather generic page component with layout options (hide the navigation, hide or show a teaser column, etc.) in the page properties. The most common used options have a separate template for the author to choose. So the underlying page component is the same for the templates but the preset layout options are specific to a template. I hope this clarifies it a bit. Else please create a seperate question as Dave suggested anyway and be a bit more precise of what you need to know.
I was wondering if someone with Drupal experience could advice what are the best practices in the following situations. I think they are all common tasks for any website that you build.
Display a custom HTML of a certain content type at front-page (e.g., only the link and title).
Should I build a module only for this?
Customize the login form HMTL, including inputs, labels etc, to something very different from the default login block.
Again, another module?
Format the node view of some content types; for example: showing additional fields values. I have some Joomla experience and with it, it's very easy to override the template on your theme.
But with Drupal, it seems HTML is hard-coded on PHP files and there are very few thing that uses templates. Or am I missing something?
You should create a view (from Views module), and for this create display 'block'. This block you can use later on your site. Within your view settings you can choose what and how you will display.
It depends what you would like to put there. If you put just some static text, change theme could be a solution. But still, a bit smelly. What you should do, is to create a module use hook_form_FORM_ID_alter and add both - field to your form, and code to use values which user added.
Change templates for this content type in your custom theme; or use Panels module - here you have nice introduction; or use Display Suite module - which do pretty much the some work as creating a template
html is in php files, but where else can it go? Drupal also has it template overwrite system. The customization of the theme can be usually done using that alone.
As for your questions (there are also other alternative)
load the content type in view/block, display in list format on home page.
create your own theme for css changes. create custom tpl.php for
layout, and div naming etc.
same as above.
It doesn't hurt to create a new module, but generally it's not necessary unless you are going for something like a muti-step form.
You can use both Views & Panels in order to achieve what you've mentioned above.
For instance, Panels gives you the option to override the home page with your own content. This content can be organized with Views.
From drupal.org:
"The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented."
"The Panels module allows a site administrator to create customized layouts for multiple uses. At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout."
I'm creating an ASP.NET site where some pages need to have a div floated to the left with the site menu in and other pages don't have the menu div and instead the content takes up the entire page width.
I'm planning to use master pages - I was wondering how best to achieve this - a few immediate thoughts spring to mind:
Create 2 master pages, one with menu and one without. When creating content pages choose which master to inherit from. This is straightforward, but may require more rework if the site design changes
Create a single master page with a content placeholder for the menu. On each page include a menu div only if it is needed (seems more messy this approach)
Nested master pages?
It seems like this may be a common problem, so interested in how this is normally addressed. Note I am questioning the need for having pages without the menu - it would be simpler if all pages had exactly the same structure.
Nested master pages is probably the standard answer and should work well.
An alternative approach that occurs to me would be to put your menu in a panel control on the master page and expose a property that lets you toggle the visibility of the panel. I have not tried this yet, so I am not sure how practical it is, but it might be a fun concept to play with. If it works the way I expect this gives you a single master page that can be reconfigured by the content page.
It's up to personal preferences, but the way I was recommended was to create nested master pages,
the first master page would not contain the menu but the 2nd one would and then just point to one of the master pages.
Nested Master pages should solve your problem and also keep the Web Site scalable.
At my previous company we used two separate master pages for a similar scenario. One that included the menu and one that did not. And because they both inherited the same base master page, they both had the same functionality.
But then again, I think it comes down to personal preference.
Personally, I like the idea of having two separate pages as that way it's a bit easier to see what's going on, compared to the nested master pages.
I am creating a website that has 5 different sub-sites each with the same overall look, but each has a different logo and added navigation.
What do you feel is a better approach:
Use the new nested master page capabilities to create 5 sub-master pages.
Use a single master page and dynamically load user controls corresponding to each sub-site's
specific logo/navigation.
I'm currently going down the nested master page route.
Update (12/19/2008):
I am using Nested Master pages, and it is working out great. You are able to pass-through ContentPlaceHolders, and even have default content for the placeholders.
Nested Master is much better than loading a user control dynamically. Dynamically loading a control is slow.
A MasterPage is a control, which could also be loaded dynamically. However, to answer your question, it sounds like different masterpages are the way to go. It will give you much more flexibility, especially if say, one client wants their logo running down the side or something that a user control would not be able for. Master will give you full control over wrapping html.