Product ideas | Community
Skip to main content

10000 Ideas

dominik_smogorNew Participant

Support tag based invalidation in dispatcherInvestigating

Request for Feature Enhancement (RFE) Summary: Add 3rd invalidation processing mode in AEM dispatcher based not on paths but tags. Use-case: Currently dispatcher supports either statfile level based or ttl based page invalidation. Those two approaches can't be reliably combined (with dispatcher 4.3.5) and are too inflexible for big multinational websites. AKAMAI has concept of tag based invalidation where each page supplies list of tags when it's cached and those tags can be used during invalidation. Current/Experienced Behavior: stat file or TTL based page invalidation Improved/Expected Behavior: 3rd mode where a list of tags (arbitrary ascii strings) is supplied from publisher with a cacheable page in a custom header. The tags are stored and indexed along with cached resources (e.g. in a page.html.tags file) in the dispatcher cache. Then when some resource is invalidated an osgi service installed on publisher is invoked by flush agent to supply a tag value. That tag value is passed on with the invalidation http request to the dispatcher (again in a custom header) which in turn invalidates all files that have this tag stored. As with stat files mode this shall indeed be invalidation not complete removal.   Examples how to use tags. 1. Product collection  - all pages pertaining to product collection supply the tag, all pages are thus invalidated together, regardless of the website structure on crx. 2. Path dependencies - components report crx resources they used as tags (e.g. resource path hash), when the resource is invalidated all pages that used it are invalidated too immadiately (e.g. all carousels, menus, footers immediately react to page name change) limiting need for less agile mechanisms like TTL and providing more flexible alternative to stat files. Environment Details (AEM version/service pack, any other specifics if applicable): Apache dispatcher 4.3.5. Both could and on premise dispatcher could implement this mode. Customer-name/Organization name:   Screenshot (if applicable):   Code package (if applicable):  

DianeSloanNew Participant

Provide option to sort comments by their location on the page (top to bottom) in the Workfront Proof ViewerNew

Description - In the Workfront proof viewer, update the "sort by page" option so that it shows comments not only by page # (page 1 before page 2, 3 and so on...as it does now), but also the location on each page, such that comments that are at the top of page 1 appear before those at the bottom of page 1 and so on  Why is this feature important to you - Our designers and editors want to be able to use the comment pane to display all the comments for each section of the page that they are revising/reviewing rather than having to jump around based on the order in which the comments were entered on the page by team members How would you like the feature to work - In all other Adobe products that we use, there is an option to sort comments by page that will show comments first by page # and then by the location on the page.  We would like the Workfront Proof viewer to have that same functionality Current Behaviour - Currently, the option to sort comments by page will show those on page 1 before comments on page 2, but it will not sort them by the order they appear on the individual pages. When there are multiple comments within the same page (or for documents that are only a single page), the sort by page option shows them in the order in which they were entered (by date/time). This is not useful for our designers and editors as they need to see all comments for a given section of the page together.  Our teams have moved away from using the Workfront proofing tools because of this issue.  It has been very disappointing to not be able to use this product in the way our employees use other similar Adobe products.