Can someone provide me the documentation of SiteEdit Properties and Methods used in Tridion 2011 SP1.
E.g: SiteEdit.ComponentPresentation(),This property is used at two different places with different parameters.
I want a complete information regarding all such properties with their return types.
All documentation can be found on http://docportal.sdl.com/sdltridion this will point you towards the API guides as well as the online documentation.
There is no such method in the 2011 SP1 version of SiteEdit. That method was only available in the 1.3 version of SiteEdit, which is very outdated by now.
However, the good news is that you can still use the markup output by that Script Extension - even in the many versions that have been released since. You really should update your templates at some point, though - at least to use a newer version of the Script Extension (but ideally to use the Template Building Blocks instead).
So anyway, you need to check the Implementation Manual for SiteEdit 1.3 to get the method information.
For your convenience, I'll explain the 3 parameters here:
The Component Presentation to output. Type: ComponentPresentation. Mandatory.
The "swap label" to use. If set, you can only swap its position on the Page with a Component Presentation that uses the same label. Type: String. Optional, defaults to an empty string.
The HTML tag to use as a parent element. All CPs that are editable in SiteEdit must have a container element (so that it can show a border around it and generally know what is considered the content of that CP). Type: String. Optional, defaults to "span".
Related
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.
I am a front end developer who uses Tridion from time to time (on a not very technical level)
.
I am looking for a way to change the document type in the Tridion 2009 rich text schema field to allow me use data-attributes (for a tooltip popover). At the moment the rich text fields are set to be either Strict or Transitional. I need it to be set to HTML5 (I know this can be done in 2011 with some changes. What changes I'm not sure.) As it stands data-attributes are stripped out by default on publish in either of these modes. Selecting HTML5 corrects this issue.
Any help would be greatly appreciated.
The rich text field in 2009 does not allow all this. But you can use a template to transform the field upon publishing. For example: you could take the title attribute on a link and transform it into a data attribute of your choice. I realize it's a bit awkward, but maybe it will do the trick.
You could do this in a C# template or with an XSLT, using the XSLT Mediator.
Could you clarify "front-end" development, please. Are you writing a Tridion GUI or are you writing a web application using content from Trdion?
If the latter, you can certainly transform the RTF content using XPath or XSL before it gets to the app server.
If the former, sounds like an upgrade to 2011 is in order! :-)
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.
Is it possible to implement tool tip (instruction) for SDL Tridion component fields using GUI extension? If so, could you please provide the details on how it can be done. The tool tip should appear right next to the field whenever the cursor is placed on the field.
Based on the selected value in one field of SDL Tridion component, can the values in an other field be restricted to specific set of values? For example, country and city fields. When the country is selected, city field should only show the cities of the selected country.
A custom tool tip with instructions for a field
You may consider using custom URLs to accomplish the same functionality. You can provide a separate URL for every field, so you could easily have a "/Extensions/Instructions/Article_Body.html" for one field and ""/Extensions/Instructions/Article_NavTitle.html" for another. That way the user can click the field name to pop up your HTML files with instructions. Although the GUI is different from what you describe, it will require less custom coding.
If you're stuck on the GUI as described in the requirements, I suggest you start by writing your own GUI extension and show us how far you got.
A dependency between fields
As Jeremy said already this is not a default option in Tridion, but can be accomplished (like pretty much anything) in a GUI extension.
This type of requirement has been covered quite extensively already in these questions:
Dynamic drop downs in Tridion designing in schema in SDL Tridion 2011 SP1
how to pass embedded schemas as drop down for the content schema in SDL Tridion 2011 SP1
Check out Can we show a different tooltip when a Dashboard Button is disabled? for the answer to question 1. The default option for question 2 is that it is not possible to do this. A GUI extension could be the answer though.
Custom URL and Description
+1 to Frank on Custom URL. Organization-specific help pages definitely help authors. Though they may not use Custom URLs for this, see a great user guide example from Yale.
Don't forget the description field. This is the easiest way to give authors basic instruction for each field and it shows as a tool tip.
For the text within a field, you can also use default settings. If you're using the inline UI (formerly SiteEdit), consider Content (Component) Types to set default values and instructions.
Category & Keyword (as a tree) for Field Dependencies
Use Categories and Keywords displayed with the "tree" option by setting subcategories (such as country) to abstract keywords. Set selectable keywords (e.g. cities) to normal. Then select the tree option to make it easier to navigate between the options.
If the use case is actually countries and cities, consider offering a better interface than the tree selector or drop-downs.
The catch is only the normal keywords would be saved in the component. However, there are workarounds to getting the keyword path.
Update: Custom Urls are not deprecated, only the old script was deprecated in favor of a new approach in SDL Tridion 2011 SP1.
I'm trying to create a custom deployer in Tridion 2011 SP1 that can index a component to a solr instance once published. Everything is working fine but I've come across a bit of a problem with the way it indexes the components fields.
I can access the meta data fields okay by using the Component.getCustomMeta() method and parsing the XML. Accessing the normal fields however does not seem to be possible without reading in the file that is being output and parsing the output. This is not entirely feasible as the markup may change and it seems to be a long way around doing what should (hopefully) be a simple thing.
I've had a trawl through the docs and there doesn't seem to be anything available to get the field values so am I at a loss here and will need to parse the output or am I missing something somewhere?
Content fields are not exposed as such on the delivery side, content is exposed as, not surprisingly, "content".
If you really need the fields, you need to:
Produce a "parseable" output for your component presentations
Parse the component presentations as they get published.
Look at implementations like DD4T for similar approaches.
In short - you cannot do it, because Tridion does not expose it Out of the Box. The only way to do it is by changing the content output format through a template.
We have done an alternative workaround to achieve for the similar requirement. One down side with the implementation is extra rendering of Component Presentations in XML and duplicate of xml storage in broker.
Here is what we have done:
Created a Dynamic CT (XML representation of content) GetComponentAsXML and mapped to all schemas
All the Page Templates has a C# TBB that looks up the content that we need to push to SOLR
C# TBB does the RenderComponentPresentation with above Dynamic CT GetComponentAsXML, this pushes the XML (engine.RenderComponentPresentation(component.Id, componentTemplateURI)
Deployer now gets the content in xml format, in addition to the other type of component presentations (like ascx, emebedded on page etc..)
Hope this information helps.