How to edit and save back the default tridion template building blocks say for Ex(Default Finish Actions) provided by SDL?
Where can i found the soucre of default TBB's? After locating and editing the TBB's, how to save back in TCM?
Editing default templates provided by SDL is not supported. They are stored in DLL and there's no way you can customize it. Maximum you can do is to disable some of the templates from being created. Alternatively you can can create your own set of default templates.
You can use the Template Builder to assemble and (test) run Compound Templates (Page and Component Templates). You can access the Template Builder from the Tools tab in the Ribbon.
The default TBBs should not be changed.
.NET TBBs are either C# fragments with the code directly accessible, or classes that implement the ITemplate interface.
Please see the following blog post to get you started:
http://www.createandbreak.net/2011/11/template-building-blocks-via-net.html
The code for (an older version of) most of the Default Template Building Blocks can be found on the Tridion forum (http://forum.sdltridion.com).
(I don't have access anymore, but maybe somebody can edit my answer and provide the link)
As others have said though, you risk getting into support trouble if you simply modify and replace them. It might be better to:
take the code from the forum as a starting point
create your own variant, making the modifications you need
compile this into a new TBB
replace the standard TBB in the Default Finish Actions with your own variant
That way you can accomplish most things, without risking support problems. When they doubt whether you broke is, you can just swap out your own variant for the original and prove them wrong.
Related
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
We need to customize for example the standard mail invitation template by changing the text a bit. I know this can be done by editing the freemarker template for the invitation that is stored in the data dictionary. This is however not optimal when it comes to application packaging. Is it somehow possible to extend the templates in the manner that they could be put on the extension classpath like the regular extension mechanism?
edit:
Found out that the inviation template for emails are hardcoded in the InviteSender java-class. :(
So I guess we will have to extend that class (and a lot of others) to do this.
Another solution I can think of would be to write a patch that replaces the ftl-files in the data dictionary with our edited ones at install time. Any other ideas?
It has been done and has been written in this blog.
In short No there is no out of the box solution for it.
Yes you could bootstrap your files and Patch Alfresco's (that's the most common used way).
You should also consider the fact that changing a template without to have access to the server where Alfresco is installed is a nice feature. With this functional guys who manage/operate/use Alfresco can change templates to their needs.
SDL Live Content describes the use case for Renderers as "manipulating the output produced by the rendering process" for Component Presentations. This falls between Content Manager and Content Delivery, specifically under Content Distribution / Publishing.
Rather than adding a Template Building Block (TBB) to all templates, we can use a custom renderer to "globally" change all CP's output. We can also use a renderer to publish item types not currently rendered. We can add a custom resolver for this item type along with a custom renderer and CD-side code.
We would implement IRenderer under Tridion.ContentManager.Publishing.Rendering in a .NET project and add the resulting dll to the CMS's GAC.
Questions
I can see how we would use a renderer to maybe manipulate or even wrap all outputted markup or maybe wrap all CPs.
Is this for "raw" manipulation of whatever our templates output? In other words, do we get access to any of the CM or CD APIs?
Does this renderer logic apply to all publications and templates in a given CMS instance?
The documentation refers to item types, are those Tridion item types such as TBBs?
Bart Koopman also describes how Custom Renderers work in the context of the other extension points in How To Tackle Integrations article on SDLTridionWorld.
I understand is distinct from Delivery-Side Renderers described by Jaime Santos Alcón?
This is indeed something that would be executed every time the standard renderer is invoked. While the use case for Custom Resolvers is easier to understand, the principles are the same and they're both part of the Publishing Pipeline.
I will always advise that instead of creating a custom renderer that will execute every time you render a template, you should use a Template Building Block that is added to all of your templates with that same functionality. Creating a custom renderer will likely be forgotten at some point in time and then you'll wonder why the output is different all of a sudden when nothing changed.
We often need specific items (schemas, templates, or components) in Tridion-related code. Template, Content Delivery, Workflow, or the Business Connector (Core Service) regularly need references to Tridion Content Manager URIs. We can link to components, but I typically see either hard-coded values or WebDAV URLs for everything else.
Hard-coded values
I understand hard-coding Tridion Content Manager (Native) URI's is a bad practice except for a few scenarios:
To simplify example code and make it clear what a variable is
When generated for use in Content Delivery (CD) API logic
Whenever possible we use the given API or WebDAV URLs to reference items, otherwise we must avoid using Content Porter on anything that references TCM URIs (or somehow make these references "configurable" outside of Tridion).
WebDAV URLs
WebDAV URLs seem to be better for a few reasons:
Hard-coded values in design template building blocks (TBBs) or other template formats remain intact with SDL Content Porter (breaking a relationship when moved through CMS environments, with an exception described below)
"Configuration" components that refer to specific items also do better with SDL Content Porter, though differently-named paths can "break" relationships
Use cases
In addition to having template that work well with Content Porter, I would like to localize folders and/or structure groups in lower publications. This can help with:
CMS authors that read different languages
translate item names and paths to appropriate languages
maybe help users navigate better (e.g. I suspect different-named folders may reduce confusion for where authors are in the BluePrint)
One Approach
To make references "Content Porter-friendly," at least for Template Building Blocks, I know we can use WebDAV Urls in components making sure to localize each path to the right locations in children publications. For example:
Code checks Publication Metadata
Publication Metadata points to a "config component"
Config component has paths as WebDAV URLs
As long as we set the Publication Metadata and localize the fields to the correct paths per publication, this will work for most scenarios.
Questions
Did I get this right? Is there a simpler or easier-to-maintain setup?
I believe we can alternatively use includes or map unmanaged URI in template code.
Anyone have an example of the #include approach? Do I use that at the top of a TBB and/or DWT and do references get replaced regardless of Template Mediator (e.g. will this work with XSLT Mediator, Razor Mediator, etc?)
Does the included reference work in lower publications or is this just for Content Porter? In other words, if I reference "tcm:5-123" will the template correctly reference "tcm:17-123" in publication 17?
I tend to follow a few simple rules...
There is no single valid reason to ever use a TCM ID in anything - template code, configuration components, configuration files.
If I need webdav URLs in configuration, I try to always make them "relative", usually starting at "/Building%20Blocks" instead of the publication name. At runtime I can use Publication.WebDavUrl or PublicationData.LocationInfo.WebDavUrl to get the rest of the URL
Tridion knows what to do with managed links, so as much as possible, use them. (managed links are the xlink:href stuff you see a bit all over Tridion XML).
I also tend to use a "configuration page" for content delivery, with a template that outputs the TCM IDs I may need to "know" from the content delivery application. This is then either loaded at run time as a set of configuration variables or as dictionary or as a set of constants (I guess it depends how I'm feeling that day).
Although we commonly refer to a Template Type implementation as a Template Mediator, that's not the whole story. A Template Type implementation consists of both a Template Mediator, and a Template Content Handler, although the latter is optional. Whether a given implementation will process "includes" correctly depends not on the mediator but the handler.
A good starting point in the documention can be found by searching for AbstractTemplateContentHandler.
SDL Tridion's own Dreamweaver Templating implementation has such a handler. I've just looked at the Razor implementation, and it currently makes use of the Dreamweaver content handler. Obviously, YMMV for the various XSLT template type implementations that exist.
As this is an extensibility point of SDL Tridion, whether included references will work "correctly" in lower publications depends on the implementer's view of what that would mean.
One interesting possibility is to implement your own custom handler that behaves as you wish. The template type configuration (in the Tridion Content Manager configuration file) allows for the mediator and content handler for a given template type to be specified independently, which means you could potentially customise the content handling behaviour for an existing template type.
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.