Posts in Category "Solutions"

How to create a dashed rectangle in Flash

If you were ever in the need of drawing a dashed rectangle in Flash, you find that it’s not so simple as using a DashedStroke. I think this is certainly a missing feature in Flash. After spending hours looking for existing code I decided to write it myself.

The first very simple approach is to create a BitmapData with the required dash-gap pattern and use it as lineBitmapStyle. This works quite well but you don’t get the nice corners.

Ugly Corners

Ugly Corners

So you really need to draw the lines yourself. The trick here is to constraint the lines to start with a dash in each corner. You need to calculate the number of gaps needed for the length of the lines and then distribute any excess pixels evenly. This is rather simple to do if you use floating point precision while drawing the lines. Of course this is easy because we’re only drawing horizontal and vertical lines and don’t support rounded corners.

Nice Corners

Nice Corners

Having created the dashed rectangle element, it’s easy to create a skin for the BorderContainer. Just create a new skin as a copy of the original BorderContainerSkin and replace its bgRect with the DashedRect. This little exercise is left for the reader :-)

Here’s the code for drawing the rectangle:

<!-- DashedRect.mxml -->
<?xml version="1.0" encoding="utf-8"?>
<s:Rect xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx">
  <fx:Script>
    <![CDATA[
      import flash.display.Graphics;

      private var _dash:int = 6;

      private var _gap:int = 6;

      public function set gap(i:int):void {
        _gap = i;
      }

      public function set dash(i:int):void {
        _dash = i;
      }

      override protected function draw(g:Graphics):void {
        var xx:int = drawX + width;
        var yy:int = drawY + height;
        var x:int, y:int, gx:Number, gy:Number;

        var nGapsH:Number = Math.floor(width / (_gap + _dash));
        var nGapsV:Number = Math.floor(height / (_gap + _dash));
        var gw:Number = nGapsH == 0 ? 0 : (width-((nGapsH + 1) * _dash)) / nGapsH;
        var gh:Number = nGapsV == 0 ? 0 : (height-((nGapsV + 1) * _dash)) / nGapsV;

        // top line
        g.moveTo(drawX, drawY);
        x = gx = drawX;
        while (x < xx) {
          x = Math.min(x + _dash, xx);
          g.lineTo(x, drawY);
          gx+=_dash + gw;
          x = gx;
          g.moveTo(x, drawY);
        }
        // right line
        g.moveTo(xx, drawY);
        y = gy = drawY;
        while (y < yy) {
          y = Math.min(y + _dash, yy);
          g.lineTo(xx, y);
          gy+=_dash + gh;
          y = gy;
          g.moveTo(xx, y);
        }
        // bottom line
        g.moveTo(xx, yy);
        x = gx = xx;
        while (x > drawX) {
          x = Math.max(x - _dash, drawX);
          g.lineTo(x, yy);
          gx-=_dash + gw;
          x = gx;
          g.moveTo(x, yy);
        }
        // left line
        g.moveTo(drawX, yy);
        y = gy = yy;
        while (y > drawY) {
          y = Math.max(y - _dash, drawY);
          g.lineTo(drawX, y);
          gy-=_dash + gh;
          y = gy;
          g.moveTo(drawX, y);
        }
      }

    ]]>
  </fx:Script>
</s:Rect>

 

And here’s how to use it:

<local:DashedRect x="0" y="0" width="100%" height="100%" dash="6" gap="6">
  <local:stroke>
    <s:SolidColorStroke color="0x000000" weight="2"/>
  </local:stroke>
</local:DashedRect>

Solution Spotlight: A look inside Integrated Content Review

I’d like to continue my Solutions focus this week with a look at the architecture of another solution built on top of ADEP – “Integrated Content and Review”.

This solution was originally designed by our Solutions Engineering team to help manage document approval work flows. This worked by authoring a “template” that defined stages in a review with participants in each stage. One of the great things about that solution (compared to a typical BPM process) is that it was dynamic. You could actually tweak the review participants while the approval workflow was “in flight”, or even force it into another stage from a management console.

The team took this concept a step further, by building “Integrated Content Review” on ADEP with a focus on Creative Campaigns (for example advertising). In addition they provided integration with Creative Suite for creative professionals to interact with the solution right within Photoshop.

If you would like a look at the live Integrated Content Review solution, check out the YouTube recording made this week on ADEPDevelopers

Here is a high level architecture diagram of how the Solution Engineering team designed their solution, pointing out some important aspects of ADEP it relies upon:

(Click to enlarge)

As in my last example, the solution is presented through a web portal application that takes advantage of ADEP UX Components (a design technology for end user applications, see: Craig Randall’s post at what is a UX component)

The solution is constructed again using “Building Blocks”. These Building Blocks (you see two of them) contribute both UX Components to the web application and additional Services that run on both the Experience Server and Document Server. Building Blocks are individual Packages that Adobe and our partners use to deliver consistent repeatable solutions. For example, Integrated Content & Review could share these Building Blocks with other solutions that need similar functionality (such as creating a project schedule)

Looking into the Building Blocks used by Customer Communications we see:

Project Management”. This Building Block provides the UI and Services needed to manage multiple “projects” that might run simultaneously during a campaign. These projects can be related to each other (such as one project dependent child projects). Projects can also have “assets” which are work items that need to be produced during the project according to “schedule’ of participants who need to review and approve the assets.

Here are some interesting points to note about the design:

  1. Projects are defined as “templates” which get stored as content in the CRX Repository via Data Services (with our built an “Assembler” for JCR). There is a Project Manager Core service that provides all the operations necessary to create and update project templates or even create a new template that extends from a common base template. These project templates are based on the Apache Velocity project.
  2. There is a Work Item Handler which is responsible for scheduling activities needed for assets in a project. For example, creating a Task for a creative professional to provide an image. The Work Item Handler invokes a service in the RCA Building Block that in turn manages the events needed to trigger notifications and work flow processes.

Review & Comment”. This Building Block (also called “RCA”) provides the UI and Services need to manage a review cycle for content. That is the initiation, revision, revocation and update of a review for “assets” that are being created as part of a project.

Here are some interesting points to note about the design:

  1. A Template Engine (Apache Velocity) executes the Template in order to to trigger “schedules” that involve assigning review tasks for project assets at different stages of the project.
  2. The Building Block contains a service used to dispatch events used by the solution to trigger notifications or to advance a review stage to the next reviewer. This eventing system is internally based on Spring Events.
  3. The Scheduler Service is used to actually trigger Process Management Tasks on the Document Server by invoking Orchestrations that are provided as part of the Building Block. All such invocation from the Experience Server is performed using the Document Services SDK. When stages of an Orchestration complete there is a call back mechanism that helps the Scheduler manage the review, for example when a review Task on the Document Server has been completed. This is performed using a DSC that calls back to the Experience Server.
  4. Sometimes a Task might not be to review existing content but to create new content. In this case the Scheduler can create a Task that will be visible in Photoshop as part of a “Task List” UI (part of Project “Salsa”). A user in Photoshop then creates the requisite asset which then gets used as the payload of the Task he/she completes.
  5. The Building Block takes advantage of PDF as the standard format for all assets being reviewed and will convert assets to PDF automatically when needed. This relies on the PDF Generation and PDF Assembler Document Services running on the Document Server.

These Building Blocks are deployed on ADEP (both Experience Server and Document Server). Document Server integration is of particular importance to this solution because of the reliance on Process Management (used by RCA to generate Tasks and route them to end users). In addition the solution depends upon the Document Server for Identity Management (Users and Groups) typically integrated with an organization’s LDAP.

There is some more information about this solution on adobe.com at: Integrated Content Review

Solution Spotlight: A look inside Customer Communications

I thought I would take a slight detour from the core ADEP Platform frameworks this week and share with you some insight on one of our Solutions built on top of ADEP, “Customer Communications”.

This solution was designed by our Solutions Engineering team to address a pattern seen over the years with our Document Server customers, particularly financial  institutions. As part of a typical document based workflow (like replying to a dispute initiated by a customer on a web site) it is necessary to quickly draft a letter based not only on common paragraph segments but dynamic data; say the personal information of the customer and the legal requirements of the State / Province in which the dispute was made. Such letters might need to be crafted on screen by a business user or they might be generated automatically.

Here is a high level architecture diagram of how the Solution Engineering team designed their solution, pointing out some important aspects of ADEP it relies upon:

The solution is presented through a web portal application that takes advantage of ADEP UX Components (a design technology for end user applications, see: Craig Randall’s post at http://craigrandall.net/archives/2011/06/what-is-a-ux-component)

The solution is constructed using “Building Blocks”. The Building Blocks (you see three of them) contribute both UX Components to the web application and additional Services that run on the Experience Server. Building Blocks are individual Packages that Adobe and our partners use to deliver consistent repeatable solutions. For example, Customer Communications shares some of these same Building Blocks with other solutions.

Looking into the Building Blocks used by Customer Communications we see that:

  1. A “Data Dictionary”. It is used to manage all the templates and letter assets that are used to generate letters. This data is stored in the CRX Content repository (JCR compliant). The Data Dictionary also integrates with external sources of data (like SAP Web Services or custom databases) to get data used in letters such as customer address details etc. Both the storage of letter assets in the CRX repository and integration with third party data sources is provided via Data Services as a standard framework in the Experience Server.
  2. An “Asset Composer”. This provides the UI and Services needed to author new letter templates and letter assets (paragraphs). The Asset Composer integrates with the Document Server to render letters (needed during authoring) by invoking customizable Orchestrations which in turn rely on our standard Document Services. It also persists those assets and letter templates in the CRX repository, again using Data Services.
  3. An “Expression Manager”.  This is a technology for auto completing additional data (for example calculating an age based on DOB) as well as data validation (required fields, formatted strings etc.). It offers a server side service that is used by the Data Dictionary to augment known data (e.g. a customer name and address) with additional derived data as one record ready for inclusion within a letter (e.g. a ZIP code). It also provides UI libraries for defining and calculating these expressions.

These three Building Blocks are deployed on the ADEP Experience Server. In addition to Data Services and CRX, the other technology point of particular need to this solution is Document Server integration because the solution includes a set of customizable orchestrations around generation of letters using PDF Forms and Assembler. This aspect of the Experience Server provides seamless integration with process orchestrations and User Security which is needed at both design time (using Forms to render letters for preview) and run time for generation of letters.

There is some more information about this solution on adobe.com at: Customer Communications

Happy Hacking

-Gary.