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
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.
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.
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 ...
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
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....
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 ...
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' ...
In terms of BluePrint design and authoring, nothing needs to change...
The process for creating schemas, components and pages etc. remains the same, and the methodology of using multiple BluePrinted publications to, for example, localise and/or translate content remains valid and can be identical to that which you know and love.
Architecture wise - things ...
Assuming your dynamically published Component Presentation is using a default DD4T style Component Template, all you need to do is retrieve the Component using the ComponentFactory as part of your controller action.
You can get the ComponentFactory from the DependencyResolver like so
var componentFactory = DependencyResolver.Current.GetService<...
The problem with multiple doctype declarations can be caused by some standard mvc view behaviour.
In your mvc project, you can define a _viewstart.cshtml file. In here, you specify the default mvc "master page" (called "layout page") to use.
This layout page will be outputted around all of your views that don't specifiy a custom layout.
you can specify a ...
Sounds like you're using the Tridion 2013 providers which come with that template.
You should run the following commands from the Package Manager Console:
Then in the DD4TNinjectModule class, change the using statement to match the provider. Lines 11 and 12.
// TODO: Change this ...
I'm not sure what the problem is, there could be a lot of causes, like a different configuration between your local environment and the other server.
It might be useful to set logging to debug.
To do this, go into your config folder on your localhost machine, open the logback.xml and set this property to debug
<property name="log.level" value="DEBUG"/&...
Good question. I have not used CWA in a long time, but I will do my best to explain.
CWA is a product/module/architecture which allows you to store all of your content in the Broker Database. You then have a CWA enabled web application which uses OOTB JAR files to retrieve the content (i.e. Pages and their component presentations as well as binary files ...
Shameless plug but check out the BuildingBlocks.DD4T.MarkupModels project, it takes care of a lot of this for you. It is just an alpha at the moment though.
Alternatively you could look at creating a suite of Html Helpers to do the job of checking for null and resolving Component Links etc.
This is indeed expected, albeit not very elegant behaviour. The GetComponents method is primary intended to retrieve components from a list of URIs which was returned by a broker query. In that case, the chance that one of those components does not actually exist is slim.
Personally, I don't use the 'batch' method GetComponents much, I usually use the ...
(Copied from StackOverflow, by Bart's request)
How Tridion Content Delivery's Object Caching works
Any Tridion Content Delivery module that accesses the storage (through the Broker or Storage layer) has a built-in ability to cache the items it retrieves. That caching is enabled by the setting you show above ObjectCache enabled="true". So by simple setting ...
As already answered by Rob and Quirijn, the LinkFactory from DD4T only does Component Linking. You can use the core Tridion Content Delivery API to page link though. Check the Tridion.ContentDelivery.Web.Linking.PageLink class and it's various GetLink methods.
//create a new PageLink instance for publication 199
var pageLink = new PageLink(199);
It looks like cd_dynamic.jar is missing in the lib folder.
Needs to remember that cd_dynamic.jar and cd_dynamic_conf.xml are dependent on each other.
cd_dynamic.jar should be placed in lib folder
cd_dynamic_conf.xml should be placed in config folder