Mediator pattern is a behavioral pattern that coordinates and encapsulates many-to-many communication/interaction among related objects (Colleagues) so that Colleagues interact not directly with other independent Colleagues, but indirectly with other Colleagues through a centralized Mediator. source: GoF
0 Comments
Bridge pattern is categorized as a structural pattern in GoF because it structurally decouples abstraction from its implementation so that the two can vary independently. However, it is very similar to Strategy pattern which is categorized as a behavioral pattern. source: GoF Strategy pattern is a behavioral pattern that lets the algorithm vary independently from clients that use it by defining a family of algorithms, encapsulate each one, and make them interchangeable. An algorithm that's encapsulated in this way is called a strategy. Strategy is concerned with changing the behavior of an object. source: GoF In this post, I note the approach and my thought process about determining whether a given smaller tree (t2) is a sub-tree of another larger tree (t1). First, the approach: Since I know t2 is smaller and it is to be matched/found in a larger tree t1, I'll take the approach of scanning through the larger tree t1, and t1's children, by trying to find a match of t2 in t1's left child tree and find a match of t2 in t1's right child tree, recursively. The Visitor Pattern is a behavioral design pattern that allows you to define a new operation to be applied to different classes of elements (also known as Visitable classes) without modifying those element classes directly. This pattern groups the same new operation together using a Visitor class, which contains separate member functions for each kind of Element/Visitable class. overviewVisitor pattern lets you add a new operation to a structure of objects (Visitable/Elements) to be traversed through, without changing the Visitable/Element on which it operates. Visitor class separates would-be virtual functions of the Visitable/Element class into a Visitor class. Each Visitable/Element should implement an accept(Visitor) function which delegates the request to the underlying Visitor class via calling visitor.visit(this) from accept(Visitor). Each concrete Visitor class implements a set of visit(Object) functions that does the real work for the operation to be applied to the structure of objects. Each visit(Object) function takes in a different type of concrete Visitable/Element object. The Visitor can optionally maintain a context during a traversal. source: GoF For Marklogic version below 6.0 on different platforms, XQSync is a tool that can copy documents and their metadata between databases, package documents and their metadata as zip archives, or write them directly to a filesystem. It deals with an entire database, a collection, a directory, or the results of evaluating an XQuery expression. If you're using Marklogic version 6.0 and above, the way to do this is to use a new Marklogic supported tool named mlcp. As part of Marklogic 6.0 release, a new Marklogic Supported tool named Marklogic Content Pump (mlcp) let you copy/move/migrate/shift data from one Marklogic server to another. If you're using Marklogic below version 6.0, the way to do this is to use XQsync to import/export Marklogic documents and metadata. If you'd like to hide non-applicable workflows from being seen by users, it is said that you can hide a custom you can remove a tag named 'Workflow:WCM' to control the workflow to display or to hide. No so true, at least not for CQ/WEM 5.6.1. My experiments shows that to have a workflow show in sidekick, the workflow page/node must either have no tag at all, or be tagged with 'Workflow:WCM."
|
Categories
All
Archives
May 2020
|