Skip to main content
deleted 383 characters in body
Source Link
Jonathan Williams
  • 14.5k
  • 1
  • 26
  • 59

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

Thanks for replies. On publishing, i just need to get list of all static pages published so i can use that list in my .net custom utility i'm making for cachging those pages in advance before user hits them. So i just need to confirm whether i should be using deployer extension or tridion events but firstly need to understand benefits of deployer extension over tridion events.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

Thanks for replies. On publishing, i just need to get list of all static pages published so i can use that list in my .net custom utility i'm making for cachging those pages in advance before user hits them. So i just need to confirm whether i should be using deployer extension or tridion events but firstly need to understand benefits of deployer extension over tridion events.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

Thanks for replies. On publishing, i just need to get list of all static pages published so i can use that list in my .net custom utility i'm making for cachging those pages in advance before user hits them. So i just need to confirm whether i should be using deployer extension or tridion events but firstly need to understand benefits of deployer extension over tridion events.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

Thanks for replies. On publishing, i just need to get list of all static pages published so i can use that list in my .net custom utility i'm making for cachging those pages in advance before user hits them. So i just need to confirm whether i should be using deployer extension or tridion events but firstly need to understand benefits of deployer extension over tridion events.

added 187 characters in body
Source Link
Jonathan Williams
  • 14.5k
  • 1
  • 26
  • 59

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

It may help for us to know more about the operations that you need to perform when publishing.

Here are a few guidelines though...

  1. A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then the Event System may be your best option.

  2. Depending on what you need to do, and which version of Tridion you are using, you should consider a Storage Extension, rather than a Custom Deployer Module.

  3. If your Transport Package fails to reach the Deployer for some reason (network failure, etc.), then your operation will never be performed. Depending on when, and under what conditions, that your operation needs to execute, this may affect your decision.

  4. If you have an outscaled Content Delivery architecture, with multiple Deployers, then you will need to determine which Deployer(s) to execute the code from. This may leave you with a single point of failure (and inconsistent Deployers), or duplication.

  5. Your network architecture and Firewall may also be a factor. For example, if you need to access a 3rd party external system, and your internal Firewall blocks this, then using the Event System may not work.

  6. If your operation needs to update another item within the CMS, such as updating the 'last published' field within a Component, then this may be easier from Events System code.

I am sure that there are lots more considerations, depending on your implementation requirements, but this should provide a start.

Source Link
Jonathan Williams
  • 14.5k
  • 1
  • 26
  • 59
Loading