Posts tagged DAY
– Scott Brodersen
Adobe forums served up some nice information about logging runtime messages for your Composite Application Framework (aka Mosaic) apps. The Client Component Framework (codename: Gravity) provides the logging libraries….Composite Application Framework runs on Client Component Framework….here’s how to get those logger juices flowing:
Yes, Gravity logging APIs can be used in Mosaic as-is. To view the log output:
1. Open CRXDE lite in a browser and log in
2. Navigate to /libs/mosaic/components/index/index.jsp
3. Locate the line in the file that initializes the flashvars variable. In 10.0 this should be on line 65
4. After that line, add a new line:
flashvars.mdebug = true;
5. Click the “Save All” button to save the changes
Then, when a new application is launched, a debug window will appear with a “Log Viewer” tab. Note that the debug window will appear in the upper left corner of the browser in a layer that will be behind html or pdf content, so if your application’s layout has html or pdf content in the upper left region you may not be able to see the debug window.
What was the OP’s result you may ask?
“That debug window certainly is useful. It has much more useful information than I was expecting. The DOM Viewer is especially nice. It is good to be able to confirm which libraries get loaded.”
Solutions over ADEP have introduced the concept of an application context (aka app context), which can be seen as a unique identifier, that various server side modules use to identify the execution context (from the current execution thread) and process requests in context of that solution. For instance, when persisting content/assets onto the CRX repository, the platform’s persistence module (official known as Platform Content) uses the current (invoking) app context to determine where to store the content/assets, and what configurations to use (which would typically be different for different solutions). See snapshot below, indicating the solution specific content areas.
Note that the storage location is /content/apps/cm for Correspondence Management, and /content/apps/icr for Integrated Content Review, which happen to be the app contexts for the two solutions.
Since it is essential for the server to identify the execution context, if you do not set or establish the application context before you make calls to the solution APIs, you will encounter a server error that says : “Unable to fetch application context“. To set the app context, use one of the two methods:
App context in your Flex application
If you are invoking a solution API from a flex application, ensure that you set the app context using:
var appToken:AsyncToken = com.adobe.ep.ux.content.services.search.lccontent.LCCQueryServiceFactory.getInstance().setAppContextService("/content/apps/cm"); // setting app context for the CM solution
appToken.addResponder(new mx.rpc.Responder(<your success handler>, <your fault handler>));
App context in your Java application
If you are invoking a solution API from a java based application, ensure that you set the app context using:
com.adobe.livecycle.content.appcontext.AppContextManager.setCurrentAppContext("/content/apps/cm"); // setting app context for the CM solution
The app context concept is also used (or rather leveraged) in other scenarios such as driving solution specific Building Block (BB) configurations. Since a Building Block is meant to be reusable across solutions, it exposes certain configurations that can be different for different solutions. Hence, the BB needs to behave differently depending upon the context in which it is being used or invoked. Below is an example where the Data Dictionary BB is used by two solutions – CM and ICR – and has configurations specific to each solution, lying within the solution’s specific app context – /apps/cm for CM and /apps/icr for ICR.
Original article at http://blogs.adobe.com/saket/solutions-and-the-application-context/.
It’s not a secret feature in CQ/WEM/DAM, but it’s still comparatively unknown – the HTML5-based file upload capability. Editing content is so much more fun if you don’t have to open a dialog [click], navigate through your folder structure [click][click][click] … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/html5-file-upload-in-wem.html.
On June 20, 2011, Adobe announced its new “Digital Enterprise Platform” software or ADEP. The platform is designed to address a new problem domain that Adobe and others have identified as “Customer Experience Management” or CEM. Please use the Twitter hashtag #AdobeCEM to follow tweets regarding CEM.
For customers with extant investment in Adobe LiveCycle and are wondering about what all of this means to them, here are some points to consider:
1) The enterprise services, and the orchestration capabilities that LiveCycle provided will all continue to be available as part of the new Adobe Digital Enterprise Platform software. They will henceforth be called “Document Services“.
2) “Document Services” will continue to be J2EE (JEE) applications requiring a J2EE appserver such as JBoss, WebSphere or WebLogic as well as a relational database such as Oracle, SQL Server, DB2 or MySQL.
3) Day CQ5 will become a “Customer Experience Solution” named “Web Experience Management”. There will also be other Customer Experience Solutions.
4) Mosaic will henceforth be called “Composite Application Framework”
5) LiveCycle Data Services will become “Data Services”
5) All “Customer Experience Solutions”, “Composite Application Framework” and “Data Services” will run on the new Apache Felix OSGi framework, not J2EE (no Tomcat, JBoss, WebSphere or WebLogic required). They will be using a JSR-283 compliant Java Content Repository (JCR) – no relational database will be required.
Here’s a simple equation to remember:
ADEP = LiveCycle + (Day) CQ5 + Mosaic + Data Services + “Customer Experience Solutions” (formerly “Solution Accelerators”)
We will be renaming this blog once the Adobe Digital Enterprise Platform software is released.
For those interested in the history of Adobe’s LiveCycle brand, see this.
Original article at http://blogs.adobe.com/livecycle/2011/06/adobe-retires-the-livecycle-brand-its-services-become-part-of-broader-capability.html.