I'm starting a Drupal 7 site and have noticed that almost every page will require a separate layout.
in order to style an individual node do i just name a template mode-NID-page.tpl.php or is there more to it?
I think i will also need to add gallery widgets, etc.. but i think that's a separate matter. But would this involve displaying fields in the above template?
First off: I don't think it's a good idea to theme pages based on their NID.
That aside, here are two possibilities how you can achieve something like this:
Theme the normal node template, but include some logic there. You could for example include specific template files based on the NID. Not a clean separation of course, as such code should not go into templates. For a cleaner separation you could attach a custom field to the pages that holds the template file used for themeing.
As you want to create individual styles for different NIDs I assume that the number of those is not exorbitantly large. In that case, you could create separate content types. Each of the NIDs should then be converted into a node of that content type and of course each content type can have its own theme template then.
Downside of the second approach is that there might be some work involved if you have a lot of settings that would need to be transferred to the content types (e.g., permissions). But then again, the new pages will be nodes too, so most things should just work out of the box as they did before.
Related
I have a large app with a structure and UI that has been designed to meet the original requirements.
I am now faced with a situation where I have to make an alternative read-only "view" of certain parts of the app for embedding in an iframe (I have no say in this, this is how it has to be).
I'll be referring to these two ways of viewing the app at the "display context".
I am struggling with visualising how to achive this, I can see two solutions both of which have distinct disadvantages:
Have lots of ng-if directives attached to template elements, the ng-if would be bound to the current display context of the app and show/hide elements depending on how it was being used. Even if these were one-time bindings, it would potentially turn the templates into an unreadable mess of nested ng-ifs everywhere
Create entirely separate templates for the two different display contexts. While much cleaner than the first option, it would mean a lot of duplication and maintaining two templates per view whereas previously it would be one.
I should add that the nature of the views is very ng-repeat heavy, a list of data containing categories, each category contains items, each item contains a multitude of data, at each level data may need to be hidden/displayed/manipulated for display depending on the display context. I have made heavy use of directives and components to break things up into logical chunks, however these directives and components are still very much geared towards the original use, rather than the newly required one.
I have also considered creating an entirely new app for this, however I'm not sure this would bring any benefits as I'd be using controllers and injecting services containing tons of stuff that would be never used, I'd also be increasing my duplication problem.
Does anyone have any feeling, suggestions on a good way forward for this as at the moment I'm feeling anything is going to be horrible.
Many thanks
I am somewhat new to Angularjs and little confused the approach I need to take for my project. Can any one provide me some pointers?
My requirements are:
I am using Angular Ui-layout. On the right end split area part I would be having 100 buttons, when I click any one of these buttons, I should be able to display a particular type of question in the middle split area. The questions can be of different type like Multiple choice, fill in the blank, etc. In the middle split area whatever may be the question like Multi choice or fill in the blank, etc I need to have few common buttons like Save, Next, Clear the Answer, etc. These butons functionality is common for all types of questions. When I click any one of the buttons (out those 100 in the right split area) it should just display different type of question that is specific to that button in that middle split area. I have gone through articles directives, template, template url, dynamic templates, transclusion, etc. I am thinking whether ng routing will be of better option here instead of going for custom directives? But these are all some what confusing to me, can any one help me for me to stat up my project with good design?
I have recently developed an odd behaviour in my views. I am trying to generate a simple view that simply lists all entered data of that content type in a table. I have stripped all bells and whistles from the view to get it working but it just won't.
When I create a new view, I can add the relevant fields for the content type, filters etc. It all works as expected. If I then save and try to create another page view for the next content type, all my fields disappear (including the original fields used in the original view). The only fields available are core fields like content:type, content:title, content:post date etc.
I have checked permissions, display values in the content type, searched extensively online. Most people's issue is the relationship hasn't been established but my view doesn't rely on a relationship, it is a simple display view.
Any help or pointers would be truly appreciated.
Thanks in advance Nelle
Drupal 7.22
Views 7.x-3.7
This is a bug in Views. See this bug report for a work-around (disable Views caching and UI Javascript).
Did you tried to remove filters from new page?
There is an important option when you use the same view to create many pages or blocks :
when you edit a field or filter, you should choose where to apply modifications (For All displays or this page (override)
When using the simple item list module BasicItemListActivity you don't have the ability to customize the layout of the item list, you can only change the colors. What should I do when I want a customization like having a list with several images per item or several text fields / prices?
The BasicItemListActivity is a bit too simple for these requirements. What you're looking for is actually one of the powerful views like ItemGridView (for tables or grids) or ItemCarouselView (for carousels).
Each of these views actually displays another custom view for each of the items you have. A good view to choose for this purpose is BasicItemCellView - which offers a lot of customization on how each item in the list is presented. Don't forget to connect the BasicItemCellView to the container view using the CellModule property.
I'm using Ext Js 4.1.1.
In many of the Ext JS widgets I am using, I am required to reuse data. For example, the items collection for buttongroup in top toolbar may be repeated in menu bar on the left side. For manageability, I should be able to have the array for items collection defined in a separate file (which could potentially follow the class naming convention for auto loading).
The approach I tried is that I am creating a class that has statics. Each static function returns an array that can be assigned to items collection of the widget. This works but I believe that using a class is an overkill if I can just use an array. Any suggestions?
Not sure if it will be useful to create separate objects for storing configuration for toolbars, buttons groups and etc. In the context of the extjs in almost all cases you need not only manage configuration but also behavior of a component.
The best way for me here - creation of generic/basic predefined classes, where you can state not only configuration but work around the behavior, add you'r custom events and process any unexpected results. After it you can easily reuse and extend it easily.
For instance you have a menu or a toolbar with 3 items A, B, C. For sure you need to know wherever you use it what was clicked (for instance) A, B or C. Creating a class and manages required events you can fire you own events which will tell you what was clicked and it is much easier to use in any context where this component will be used. Add post and pre processing, template methods and etc...
Creating a big file just with configuration is not readable and not extendable, will be a case whre you will need to add functionality and behavior to all such generic components and it will be not easier to do with just arrays or simple configs. Separating even just simple general components having just simple configuration (in the beginning) will bring more expressive in the code structure and readability and in the later time gives you the power to manage it.
Pure configurations can just keep the code accurateness and re-usability but what about behavior for in almost cases you need to control..
The design, maintainability and extensibility are very important points in every big web-applications and in context of extjs 4.