I have recently noticed something odd with Display Suite. I am rather new to Drupal so if its something on my mistake please do not make fun of me.
But I have noticed that no new custom display settings (view nodes are being added to either node or field collection) previously it worked perfectly but now if I create a new view mode and attaching it to the node / field collection it seems it does not apply to it.
See the photos attached. Any suggestion?
http://oi59.tinypic.com/727fqp.jpg
http://oi59.tinypic.com/jb44cj.jpg
P.S. I have cleared drupal cache but it still keeps not working.
Thanks in advance
Fist I'd say that if you're a new user to Drupal, using Display Suite is really jumping into the deep end. It's a really powerful module and creating View Modes is just the tip of the iceberg of what it can do. Second, when you create a new View Mode, you're doing it for an Entity (such as Content Types, Users, Comments, File - but not so much a single node, nor a field). You can find more info on what View Modes and entities are here. You don't need Display Suite to activate other View Modes but if all you're wanting to do is create a custom view mode, the lightweight module to use for that is Entity View Mode. Lullabot does a nice job of explaining this module here.
Anyhow, modules aside, note that the controls for turning View Modes on and off are only found on the 'Default' view mode for a given content type, ie: when on the Manage Display page of whatever content type you're working with, at the top right under the main tabs, you'll see your activated view modes. If you select 'Default' then you will see the control to turn on/off other view modes.
Now, maybe you're wondering how do you see what a particular View Mode looks. To do this, you're best off using Views as it ties in nicely with View Modes.
Hope that helps.
Related
I have an intranet system that uses the DHTMLX UI Framework as user interface, but I'm looking for more modern interfaces that suits the current interface. The current version of DHTMLX I'm using only supports jQuery 1.x, that is a serious security problem. I already asked to update the version using the same UI, but there is a lack of documentation on its updated product. I.e., if I Googled for specific method or some way to run specific task or behavior, I'm always being redirected to elder documentation, or it simply doesn't exist!
I sketched here the current main UI I have: https://dhtmlx.com/docs/products/visualDesigner/live/?preview=true&id=967kh4
Explaining the behaviors: I have the layout separated by tabs, but the Tab 0 is the main record, and "sub tabs" are records according the selected row on grid of Tab 0. If there is no selected row, all sub tabs are disabled by default. If I add a new record on specific tab, automatically it adds a new row to equivalent tab.
This front is not so usual, but allows user previewing quickly the dependencies.
Question is... Do some of you have something similar to this layout? I'm disposing layouts that has to click on the main record, have to load an entire screen just to preview its dependencies.
The image below shows the current system interface
Any suggestion will be appreciated.
I was thinking of writing a new app where a users selects an option of what procedure they want to perform and the view changes to that until done then goes back to the main menu. I came across CDHtmlDialog and looked like a nice easy way to add a nice looking menu using html. But I wonder if that is the purpose of that class? Can I set it up so when a button or graphic link is clicked it changes out the view to another one (I would need to use traditional things like CTreeView with CListView with a splitter) or is it more for staying within the HTML world?
Thanks.
From the MSDN MSDN documentation
CDHtmlDialog Class is used to create dialog boxes that use HTML rather than dialog resources to implement their user interface.
From what I can gather from your post, I think you should consider SDI application using view classes that you want. To switch views on the command you do not need a splitter window. A static splitter is used to display a number of views in a different part of the splitter simultaneously.
I have been looking through the code and the pdf documentation and I can't find anything that indicates how the StockTrader sample application decides which view (PositionSummary or WatchList) should be displayed by default.
Can anyone explain how this is determined?
If I remember correctly, the stock trader RI uses its own custom behavior named AutoPopulateExportedViewsBehavior. This behavior is different from the one used by Prism as out of the box and is designed to work specifically with MEF. Along with the ViewExportAttribute it register the view in the container while also adding in to the corresponding region at start-up. You can find both of them in the StockTraderRI.Infrastructure project inside the Behaviors folder.
Edit:
Maybe I misread the question. If you are asking how it's determined which view between the PositionSummary and WatchList views is shown first, there is no specific configuration for this. The order is related to what module is initialized first. If you were to move the PositionModule after the WatchModule in the bootstrapper, the WatchList would be the one being shown by default.
I setup a new site on dreamweaver and imported my site files in. I only did this since I wanted to play around with the design view, otherwise I just use notepad++. Anyways When I go into design view I can see the text of all my smarty tags and I don't see the design of the website. Is there a way to make the design view work properly so that my smarty code isn't shown as text and my website is shown correctly. Any nudges in the right direction would be greatly appreciated! If this isn't possible should I just stick with editing my code in notepad++ or is dreamweaver better?
You can switch to Live View. Live view differs from the traditional Dreamweaver design view in that it provides a non-editable, more realistic rendering of what your page will look like in a browser.
When you switch to Live view from Design view, you are simply toggling the Design view between editable and “live”.
While Design view remains frozen once you enter Live view, Code view remains editable, so you can change your code, and then refresh Live view to see your changes take effect. When you’re in Live view, you have the additional option of viewing live code. Live Code view is like Live view in that it displays a version of the code that the browser is executing in order to render the page. Like Live view, Live Code view is a non-editable view.
An additional advantage of Live view is the ability to freeze JavaScript. You can refer to the following Wiki to know more: http://help.adobe.com/en_US/dreamweaver/cs/using/WS753df6af718a350a-43cf1449133aea5253f-8000.html#WS16D4BD4B-0A17-44b9-95E9-ACC9795CE4F9
Regards,
Yalpi Shiva Prasad
Adobe Systems Incorporated.
So I have a PRISM v2 (M-V-VM) application up and running. It's 4 modules that load into a tab control. Great.
Now my question is - where to go from here? Most tutorials seem to stop at this point.
Maybe I'm overthinking this, but it almost seems like I'd need each module to be its own PRISM application, but that can't be right.
Please help a PRISM n00b figure out where to go from here.
What I'm looking to do next: Each tab (module) has its own toolbar with buttons, etc. Clicking a button should change the content (view) below the toolbar.
How to achieve this (correctly) with PRISM? Each module (tab) should have control over its content, however, clicking cetain buttons in one tab may trigger an event in another tab (hence the use of PRISM).
So what's the correct-PRISM way to change views within a module?
I think you are thinking about this a bit hard. I'll explain.
What is commonly referred to as the "Shell" should contain all of your navigation controls. For example, if I wanted a tabbed UI, my Shell would contain a tab control (usually you'd decorate that TabControl with a RegionName, like "ShellTabs").
Your Modules will contribute views to these shell elements. So let's say you have the email module, it will contribute an inbox view to your collection of tabs. It could contribute these views by registering them with the RegionManager for the app (like registering your view with the Region called "ShellTabs").
Modules don't have to contribute anything visual. I have one module in our app that takes care of logging and other background processes.
Hopefully this clears up some of the nomenclature and helps you know what the responsibility of each part is.