As per the documentation of Silverstripe, template inheritance is defined as follows:
mysite (or other name given to site folder)
module-specific themes (e.g. themes/simple_blog)
themes (e.g. themes/simple)
modules (e.g. blog)
framework
Now I've got a site that has quite a few different themes. Well, "different" in that they have different names, but they still got an awful lot in common. Now I am putting all the common files in the /mysite/templates folder, but that means that if one of my themes needs a change in one of the templates, I need to remove that file from the common folder, and move it to ALL the different theme folders. In this way I end up with a lot of duplicate templates.
In my case it would be beneficial to change the inheritance order, causing the specific theme folder to take precedence over the /mysite folder. In such a way I could just copy the template that has to be changed to the theme folder and that theme one will use the changed one, while the rest keeps using the generic one in the /mysite folder:
themes (e.g. themes/simple)
module-specific themes (e.g. themes/simple_blog)
mysite (or other name given to site folder)
modules (e.g. blog)
framework
It also seems to me to be the more obviuous way to do it, but I probably am missing some important point here. Nonetheless, would doing this be possible without hacking the core?
Template inheritance rendering seems to be managed by two classes predominantly, SSViewer (a core class for handling view rendering) and Controller (which all other controllers inherit from).
For view rendering, a SSViewer object can take an array in its constructor for template inheritance. This is important because the Controller class actually instantiates the SSViewer in a function called getViewer.
It is important to mention at this stage, a normal SilverStripe site you are normally inheriting from ContentController instead which overrides the getViewer of Controller. It won't really change too much of what you need to write but it is important depending how low-level you want this to apply.
For what you want to apply to pages in general, you would be looking at overriding getViewer in your Page_Controller. As for what specifically you would need to write, that is somewhat dependent on your entire site structure. I would imagine it would need to start off a little like this though:
public function getViewer($action) {
$viewer = Parent::getViewer($action);
$templates = $viewer->templates();
//Do your processing that you need to here
//Set it back via:
//$viewer->setTemplateFile($type, $file);
//Alternatively, you can create a new SSViewer object
return $viewer;
}
It will be a bit of experimentation to work out what exactly you need to do for shuffling around the data though this was never going to be easy. Once you start heading down this path, you likely will find a number of edge cases where this may not work properly (eg. template includes).
The question and the accepted answer are for SilverStripe 3, and should be referred to for queries relating to SilverStripe 3.x. The following refers to SilverStripe 4.
As SilverStripe 4 is currently the latest stable version and now sets theme inheritance instead of template inheritance, the question and answer may not be suitable for newer installations or up to date installations.
The best way to control inheritance in SilverStripe 4 is to ensure that the themes are configured in the correct order, and that the module inheritance is configured appropriately.
Your mysite/_config/theme.yml file typically declares the theme inheritance, and you should adjust this file to control theme inheritance appropriately. For modules, you need to specify the appropriate Before and After in your mycustommodule/_config/modules.yml file.
The following example is for a sile with both the mytheme and simple themes, a custom module without an _config/modules.yml file, and a vendor module without an _config/modules.yml file.
SilverStripe\View\SSViewer:
themes:
- 'mytheme'
- 'simple'
- '$default'
In this example, SSViewer::get_themes() will return those three items as an array in the same order: ['mytheme', 'simple', '$default]. When checking to see if a template exists, $default will then be replaced by the paths of all modules which define templates, in the same order as they appear in the manifest.
<?php
use SilverStripe\View\ThemeResourceLoader;
$templatePaths = ThemeResourceLoader::inst()->getThemePaths(SSViewer::get_themes());
$templatePaths === [
'themes/mytheme',
'themes/simple',
'mycustommodule',
'vendor/silverstripe/asset-admin',
'vendor/silverstripe/campaign-admin',
'vendor/silverstripe/reports',
'vendor/silverstripe/siteconfig',
// Some vendor modules may appear here...
'vendor/othervendor/custommodule',
'vendor/silverstripe/cms',
'vendor/silverstripe/admin',
'vendor/silverstripe/assets',
'vendor/silverstripe/framework'
];
Related
I have 3 projects, (Ex. project1, project2, project3). Some parts of these projects are using just 1 Form (frmDetails) placed on a separate folder.
I want to Disable some details on my form depends on what project I open.
For example, I opened Project1 - all details on my form are displayed. Then when I opened project2 - I want "Age" and "Birthday" set Visible to false.
What functions that I need to this?
The easiest way to do that, is to make 3 separate copies of the form for 3 projects and modify them as needed.
If you wish, you could create a class from that form with minimal objects that appear in every project, and create 3 separate forms from that class per project.
Normally, after you build an executable, executable doesn't know from which project it was build. So you can't basically have one form behaving differently per project. However, per project you might add something that tells the project (be it a text, xml, Json, dbf ... file). So you could read that file's content in load or init of form and set form objects' visibility on\off if you want to do it with just a single form. It would make things harder and would be confusing but at the end it might sound 'nice' since it is only a single form. My suggestion, as said on top, create 3 separate copies per project. That way it is much easier to control them.
If you're using an application object, you can have a property of that object that identifies the project. However, I'd be more likely to do this in a more generic way that specifically looking at a single property.
You might use a set of logical properties that indicate options you can turn on and off, and then you can check those properties in your forms.
Using Sphinx's domain-aware ObjectDescriptions I can create fancy rendered documentation for them. For example:
.. py:function:: pyfunc()
Describes a Python function.
This renders the content in a nice way, and this works really well with module indices, references and so on. Cool so far!
Now, let's say I have that directive in a source document src/mymodule/functions.rst, and I have a bunch of text in src/guide/getting-started.rst, I can reference to the objects like
:py:func:`pyfunc`
Also cool!
Now, my actual question; Could I also tell the Sphinx writer to re-render the same documentation snippet for that object? To ease the user in not having to navigating away from the Getting Started page where I just want to include a single piece of content again.
What I've tried to do:
Simply copy the contents. This results in a warning that the object is defined multiple times, hurts the index and as a result references don't point to the "authoritative" place in your project, if unlucky. Not okay.
Document each object in its own file and then use .. include:: rel/path/to/pyfunc.rst in each document where I want to render it. As those includes are literal on ReST-level, this results in the same downsides as the option above. :-(
Thus, I'm looking for a solution where I would tell the renderer/writer of Sphinx to simply re-render the contents of a reference instead of producing a link. It should not add it to the index for a simple re-render.
I'm okay with a custom extension or a domain-specific custom solution - I'm already using my own custom domain, but I just used the general Python domain above as a well-known example.
Context for the use case: I'm building a Protobuf domain. Protobuf messages and enums are reused a lot and I would like to show the context of commonly reused objects inline on pages where this is useful to the reader. This means it is repeated over the whole project on purpose where it is deemed useful rather than navigating away all the time. Yet only the reference page should be "authoritative".
I've been successful with a dirty hack: abusing the XRef role logic. Cross-references in Sphinx render dynamically (e.g. Table 23) by producing arbitrary 'nodes'. By:
keeping a copy of the parent node during parsing in a custom Domain
registering a custom Sphinx/ReST XRef role to render a whole set of nodes (the saved parent node)
re-running the ReferencesResolver another time
... this basically does what I need. But yuck, it's rather ugly.
Working example I implemented in a Protobuf Domain extension.
My company is making a module for Magento to fit the needs of Brazilian business rules.
Sometimes we need to override core models to add funcionality, sometimes need to rewrite core models to change some functionality. We are in doubt wich is the best practices to do this changes. For example, when a module needs to modify some behavior that is owned by other model.
We know that the modified files need to be created under "local/mycompany/modules..." but we're running into a problem that I will describe below.
A simple example is: Our Customer model needs to add the postcode with the '99999-999' mask, with the '-' before the last three chars. That is ok, its done and working. But when we need to use this postcode to make calculations, wee need to remove the '-' char. That was made in our rewrited "Shipping/Rate/Request.php" model.
That is the point of our doubt. Which is best?
Do this rewrite inside new "Shipping" module in "local/mycompany/Shipping/Model/Rate/Request.php" or do this rewrite inside the "Customer" module directory structure?
We are confusing about the structure we need to decide.
Something important is that we won't distribute or sell the modules rewrited as separated modules.
I'll put some code here:
The postcode is received by our "Customer" module, with masks in input, done by Javascript.
This "Customer" module add more fields to customer database.
Here, I rewrite "Shipping/Rate/Request.php", inside the "Customer" module:
in config.xml of "Customers" module:
<shipping>
<rewrite>
<rate_request>Mycompany_Customer_Model_Shipping_Rate_Request</rate_request>
</rewrite>
</shipping>
Then the file "Mycompany/Customer/Model/Shipping/Rate/Request.php" contains the code to remove '-' char from postcode.
Our doubt is: In some cases, we need to rewrite the "Shipping/Rate/Request.php" again to modify other methods. Which is best?
Every rewrite is done inside the module that came from? Creating repeated files of the same class.
Use the same directory structure of Magento's core inside the "Mycompany" namespace and modify all that we need inside one file of each class? Like Magento's core?
I don't know if I could explain what I need.
Thanks!
It's best to keep the contents of a module within it's module folder.
If the extends you are talking about are part of a module's functionality than you should place them inside that module's folder. The path would then be local/mycompany/Mymodule/Model/Shipping/Rate/Request.php.
I would create this extra level in the dir structure to make it clearer that the rewritten Request.php comes form the Shipping module, but this is absolutely not a necessity.
The reason why this is a good practice is of course modularity. You will be much more able to add, remove and version modules that are contained within one folder. Think about the module's xml file in app/etc/modules and the config files in your module's directory. They describe what is in your module's directory and not all the rewrites that belong to it but are in different module folders.
Besides, if you have extended or rewritten the same model from multiple modules and you decide to remove or totally rewrite a module of your own, how will you know which files or parts of files will belong to it if they are scattered around the app dir.
For a more detailed view on how to create Magento modules please also have a look at http://www.magentocommerce.com/magento-connect/create_your_extension/
I'm using the Magnolia Spring Integration (Blossom) for my web app and I definitely don't understand how (if it's even possible) to share a unique area between two pages.
This is how I've worked so far :
I have three templates main-template, template-1 and template-2.
template-1 and template-2 both redirect to main-template by redefining their own "body" areas.
In the class of template-1 I have three areas : content-area, area-1 and area-2
In the script of template-1 I include the three areas with the following directives : [#cms.area name="content-area"/], [#cms.area name="area-1"/] and [#cms.area name="area-2"/]
The same areas are defined in the template-2 class and script
What I want is to share, lets say, area-1 between template-1 and template-2. The problem is that by redefining them in each class they are considered like different areas...
Through my tests and the magnolia documentation, what I understand is that an area can only be defined within a template class so it can be accessed in the script of this template and only the areas defined directly in the template class associated with the page will be process/rendered.
No matter what I try, as long as the areas are not defined in the page's template class they cannot be accessed and therefore included pages don't have their areas rendered.
Does anyone have a clue in how I can "include" or process "areas" from other templates in another one ? Or am I doing it all wrong ?
Thank you for your time.
regards.
I know this is an old question, but it is still a valid question, so let me answer it:
As far as I know areas can inherit from other areas (normal Java class inheritance using "extends ..."). As far as I know this wasn't available in 2013 yet, but it is now. I know this because I filed this as a feature request once and it was marked as solved at some point, and I think I also successfully used it once (don't remember clearly).
If for some reason it's still not possible to extend areas from super classes, then you could still use conventional tools like putting the logic to a helper class and making the actual areas very slim (that is just calls into the shared helper class). And the actual template (.jsp or .ftl file) can be shared anyway.
I'm working on a joomla component that includes building a schedule. On any given day it needs to look at a set of rules (day of the week, date of the year, type of event) and return all of the possible start times. It would make sense to have a class that calculates these things, but I'm not sure it fits in the model or controller (and certainly not view) categories. Am I supposed to create a com_myproject/lib (or similar name) and have joomla auto-load the classes?
I'm new to joomla and started with the framework/project provided at http://docs.joomla.org/Building_Joomla_Extensions_with_Apache_Ant.
You should create a helper class. Have a look here for an example, albeit it is for a module, but the same concept applies.
You might want to start off with Developing a Model-View-Controller Component - Part 1 tutorial and work your way through that by hand. Using Apache Ant to learn how write an extension is like taking a canon to shoot fish in the barrel. It can be done but probably not the best way of doing it.
The Joomla! MVC pattern is very peculiar and difficult to understand. I don't quite understand it myself. I was advised on the developer email list to look at how other components are put together. Guess what? All the other developers do it differently, with some of the bigger components looking like spaghetti code in their organization.
The bulk of your component code should be in the controller, either as part of the controller class or a separate class file that's imported in. You don't need a separate library directory unless you're working on a big component with multiple class files. This Joomla! thread might be applicable.