If you have a View for your Component you could do it the .NET MVC way, by hooking up to the Controller/Action you already created by placing @Html.Action("YourNewsActionMethod", "News") in your razor view for the Component. This will call the "YourNewsActionMethod" on your class called NewsController.
Chris hits a few of the main differences between the CWA and DD4T project. My view is a bit simpler, so I'll share it too.
In a Tridion implementation your content lives (at least) three places:
in the Content Manager database as XML
in the Content Delivery broker
in the visitor's browser as HTML
Tridion systems architecture
Yes it can. In short: implement a mechanism to find the corresponding publicationId for a request/url. Luckily this is part of DD4T, thanks to Quirijn. Read more about it on his blog:
If you work on a 32-bit workstation, you need to use the 32-bit Tridion DLLs. The DD4T DLLs themselves are hybrid, they should be okay.
You can find the 32-bit versions of the Tridion content delivery DLLs on the Tridion installation CD.
firstly yes its 32 vs 64 bit dll/Jar issue, but in my case i was using correct 64 bit dlls/Jar, but in the app pool mistakenly "Enable 32 bit Applications" was set to true. After setting it to false resolved my issue.
As I understand it, DD4T is an open source project. Presumably no-one has yet felt the need for this enhancement. My suggestion would be to build it yourself, and obviously, also contact the DD4T team to see if your enhancement can benefit others by being integrated into the project
The reason why the data format (in our case XML) is hardcoded, is that DD4T controls the input as well as the output of the process. The XML is intended to be consumed in a web application by the DD4T factories / providers.
If you want to publish JSON and consume it using custom application logic, you don't really need DD4T - just write a template that does ...
For MVC the setup can be almost identical. An approach I've seen looks like this:
Local web.config (could be partially published from Tridion)
Virtual dir to 'Views' in root
Virtual dir to 'Js' in root
Virtual dir to 'Css' in root
Local web.config (could be partially published from Tridion)
Virtual dir to 'Views' in ...
You can also use the metadata in the Component Template to override the default component controller/action and provider you own.
If you custom action provides a parameter of type IComponentPresentation then DD4T will take care of passing the ComponentPresentation object to you action:
// Use "Index" in the override action field in the component template
This works differently in DD4T. Unlike when dealing with the dynamic ComponentModel.Fields exposed by the Razor Mediator, you're now working with a standard dictionary, so you need to check that the key exists before you can access it. Try this:
Despite popular belief, the Cache Channel Service itself does not handle caching, it only handles propagation of what items should be taken out of the cache. The cache itself is part of the Broker and it is enabled or disabled in the storage conf.
The Cache Channel Service is there because the Deployer and Broker(s) can run in a separate memory space or JVM,...
ok I think I figured out the part I was missing. I assumed... wrongly... that the default route was not being used but it is. That is the route the ComponentController goes through. In my area route config I was not defining the default route, hence it was complaining about the route not being found.
Once I added the following to my area route config both ...
When you get errors like this, it's probable that the dd4t version you are trying to install is built against a different version of the contentdelivery dll.
You can either rebuild the dd4t solution with the tridion dlls you are using (download the source, set the references to your contentdelivery dlls, and build, or you can add the following in your web....
This should not be a problem.
DD4T is itself a small set of Compound Templates, publishing XML to the Broker DB. Then on the Delivery side, there is a custom library in your MVC application to retrieve content.
Depending on your requirements you can use them together or branch at the design layer.
Here's what you can do:
In your /bin/config directory there should be a file 'logback.xml' - you can use this file configure some logging from the application - this typically gives you a clear enough indication of the problem.
You have the SQL database connection jar file (if you're using an MS SQL db)
Each config XML file in the config ...
I was one step ahead of myself. DD4T provides the method IField.DateTimeValue, therefore you don't need to get the string value then convert to a DateTime, you simply go straight to the DateTime (as mpaton points out, ensure to check for values when putting the code to production):
if (page.MetadataFields.ContainsKey("modifyDate") && page....
As David said, there is no change to the authoring process for the editors and the Blueprint model is the same.
In terms of how the CD looks depends on your requirements and capabilities in terms of scaling and deployment set up.
You could have a single web application pointing to a single Broker database which all publications publish to in the model ...
The classic concept of BluePrinting does not change whether you use DD4T, CWA, or a classic Tridion DWT-based implementation. The only difference with DD4T is that instead of publishing rendered markup (i.e. baked HTML, Java, .NET or whatever server-side language), DD4T's templates publish XML (e.g. when you look at a component's source, just with a bit ...
There's no reason why you still can't use the TBB's. I'd recommend using them in the event you wish to move away from the DD4T mvc framework in the future.
Simply output your content as REL and transform the TCDL tags yourself when you return your content from the broker.
Another way of doing this would be to write a number of mvc html helpers that would use the smarttarget query api to fetch promotions etcetera.
The flow would be something like
get parameters from the html helper (promo name, nr of items, region name,...)
construct a smarttarget query
send a query and receive xml with results. I believe the results are tcm ...
By default the view for DD4T is determined by either the name of the Template or it can be specified on the Component or Page Template Metadata, here you can also set a different controller.
If you specify a different controller on your Template and then in that controller override GetView() to read the view from the Component Metadata instead, you have ...
There's a TridionSiteMapProvider as part of the DD4T.Mvc project, which can be used out of the box with the accompanying example TBB with generates a sitemap.
Unlike your article though, the sitemap for DD4T generally uses URLs as the editor sees them in Tridion, not controller/action style URLs you normally use with MVC.
The provider is activated ...
This is, of course, not related to DD4T and just the basic configuration in cd_link_conf.xml.
What needs to be specified is the Host element. As per the comments provided in the boilerplate cd_link_conf.xml file, specify the Domain, Port and Path. In my case, the Path was set to "http://localhost" and the domain was set to "http://localhost:889" causing ...
This is actually a problem we dealt with in our current project as well. It seems that when using version 1.25.0 of the DD4T framework there is no way to get a specific ComponentPresentation.
The cause of this problem is that the PageFactory will retrieve the first Component it can find from broker database and this will be cached for future use. So, when ...
There are two basic patterns: either you publish the linked component inside of the page ("embedded scenario") or you publish them seperately as dynamic components ("DCP scenario").
In the embedded scenario, the linklevels allow you to specify how many levels of linked components are included. In the end result, the linked components are available directly ...
No, DD4T doesn't care about your deployer, you can use whatever setup you like. DD4T consumes data through the normal Content Delivery APIs.
As mentioned in point 1, DD4T uses the normal Content Delivery APIs, so in your web application you still have all of the JARs and config xml files associated with that (cd_storage_conf.xml), just like a 'traditional' ...