The override that expects a Component Presentation is just a wrapper for the one that expects the ids. For Instance this override expects a publicationId, componentId and componentTemplateId:
public void remove(int publicationId, int componentId, int componentTemplateId,
I will assume that what you mean with the Broker is the Tridion Broker database.
It is possible to publish everything to the file system, it includes, content, linking info, metadata and references, however this functionality is deprecated and will be removed in future releases, having said that, in future releases, linking, metadata and references will ...
Dynamic Linking is the big one as Rob mentions.
any DCPs embedded on Pages will render
Any code that queries CPs using Criteria/Query API will need to be gutted/replaced.
If you use P&P, then any personalized content will be rendered and filtered via User Controls/Tags, and this will need replacing
If you use UGC, same as #4.
When starting a ...
Indeed the com.tridion.storage.ComponentPresentation class was changed. The create, remove and update methods now receive the Component Presentation content as byte-array.
If you need the string contents, you can simple do:
public void create(
You can always try to access the package as described here using a deployer extension. Or if you want to stick to the Storage extension, you might be able to re-use the Utilities class provided in the link above and then use its getComponentPresentationsDocument method (or another method in such class) to access the package files and/or contents.
Your code looks really familiar ;) . If super.create() fails, then the super class throws an exception and the entire transaction is rolled back. If you throw an exception in your connectDB method, the entire transaction be rolled back as well. So, instead of doing an e.printStackTrace everywhere, you should throw the exception.
If that doesn't work, have a ...
Once you have added the "additional information" using Engine.PublishContext.RenderedItem.AddMetadata, you can use a Deployer Extension. Here is an example (framework) to deal with Deployer Extensions:
Custom Deployer Extensions Framework
On a side note, if what you need to do is to add more nodes to your xml, you can do it in the template as well, not ...
The point at which the storage of the item is committed is not at individual item level, but at DAOFactory level (JPADAOFactory or FSDAOFactory for DB/Filesystem). The reason for this is typically the publish transaction will store several items (page, metadata, binaries etc.) and the commit of the storage should be all items together. So in order to hook in ...
As you've realized, this cannot be achieved using templating. If you wish to do this this way, you will need to use a different extension point, namely ITransportPackageHandler.
See my TDS presentation for more information here.
But... why don't you do this on the CM side? Make use of the Event System and the SetPublishStateEventArgs class. This is only ...
The behavior is because of the way the storage layer function for Tridion Docs.
As we know in Tridion Docs only Publications can be published/unpublished. While publishing, the storage layer stores the Publication along with its items (Page => Topic + Template, Component Presentations => Topic + Template) individually so the create methods execute for ...
I would be vary wary of any approach that removes all Content Delivery functionality, or the ability to hook into it. Customers I have seen that take this approach due to whatever requirements, tend to become very dissatisfied in the long term. Usually they bought Tridion for the whole package of functionality, CM + CD.
Some typical issues are:
I assume your storage extension is called by the Deployer. Please specify.
When an existing DCP was re-published, the Deployer used to call a remove followed by a create. This was in an older version of Tridion (i.e. 2009 IIRC). I believe this is still the behaviour that you are seeing.
Could you check to see if instead of the update method, the methods ...
You might be able to achieve that using a CM Event handler for PublishTransaction Save (Initiated phase).
If the Publish Transaction state is set to Failed and you recognize your error/warning message in the deployment feedback XML (stored in PublishTransaction.Information), you could change the state to Warning.
JPA DOAs are used only for non-filesystem storage. If you want to extend the behaviour of storage on the filesystem you need to extend the corresponding FSDAO class.
Note that you can change the storage ID (and caching settings) per publication to use and thus switch between DB/filesystem but you cannot change the DAO to use per publication as your custom ...
If it is for ComponentPresentationDAO then I can confirm that it will always be the create (for publish and Re-publish) and remove (for unpublish ) which will be called.
The Update method will never be called.
It might be because the super class JPAComponentPresentationDAO have this update method but it is not in use by the Storage Layer.
I hope it helps
As far as my experience with Storage Extension (in SDL Tridion 2011) is concerned, the update method never got called. Whether you publish a dynamic component presentation or re-publish it, it is always be the create method that got called.
My wild guess is that the super class - JPAComponentPresentationDAO have this update method but it is not in use by ...
I found a solution.
To ensure the DCP is also stored in the Broker Database, my class needed to extend JPAComponentPresentationDAO and call super.create() in my class's create() method
Also, all other methods of the ComponentPresentationDAO interface must call super.XXX() otherwise the DCP isn't removed from the Broker DB even if it is unpublished.
This sounds like an unusual implementation.
It might be worth blueprinting your website to allow you to localize the templates to render the json. The new child publication could be used with a new deployer for you to test if this gives you the output you need without any missing functionality.
Unfortunately it is not possible to use a custom com.tridion.storage.persistence.JPADAOFactoryby design, this type is statically used by the storage layer and it will ignore a custom one avoiding adding new operations to the transaction.
Rogier Oudshoorn's answer recommends looking into setting cache-expiration policy via headers that are set by your applications. That is absolutely the way to go for day-to-day operation of content expiration.
However, there are times when you really need to expire something more programmatically. For example, an item that is referenced from a home page ...
My question: Why do you want to rollback transaction of custom DB if super.create has failed? As you have called the super.create as the first call, and if there is any exception, your code for custom DB and so the related transaction would have not get executed. Isn't it?
You should have written your create method (in the storage extension) with in the try-...
I realized that the JPAComponentPresentationDAO which is the base class we are using in our custom storage extension class have got changed a lot in terms of the class members and the method signature. This required us to re-write and re-build the class inherited from this DAO such that it implements and reflect correctly all the parent members.
I have built a very similar solution for a customer and the step of storing the binaries on the deployer filesystem had two advantages for us:
it makes it much easier to debug any issues (as you can see if the deployer is working in principal and only the extension is at fault)
it made the upload to S3 much easier as the library we used would determine the ...
Storage extension has nothing to do with CMS Templates, both belong to two completely different contexts.
Templates are executed in the CMS during the publishing action.
Once the Package is sent to the deployer, the deployer process the zip received and stores the items. This is when the Storage extension is executed.
Moving logic from an storage extension ...