Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Welcome to Oracle Blogs

Welcome to the Oracle blogging community!

older | 1 | .... | 959 | 960 | (Page 961) | 962 | 963 | .... | 989 | newer

    0 0

    Introduction

    In this primer article on JET Composites, I'll just be looking at the basic tasks involved in creating a simple Composite Component. Think of this as a "hello world" tutorial equivalent. In later articles I'll be expanding on many of the topics that are only touched on here, so if you work through the articles in sequence everything will make sense as a whole and you'll get a good grounding in this feature.

    Setting Up

    Throughout this series of articles I'll be building up some example Composite Components that you can follow along with should you wish. So to start off, I'll just create a new JET Application as a workspace for the subsequent code to live in:

            yo oraclejet myfirstcomposite --template=basic
          
    Once that's done I've created a new ojModule called workArea, just to act as a place to test any composites that I create. I'm assuming that you'll be familiar with creating modules, but if not, jump to the steps outlined in the addendum at the end of this article.

    Setting up the JET Application to use Composite Components

    The first thing that should be on your checklist when consuming Composite Components into an application is to make sure that both the text and css requireJS plugins are configured up. If you create an application from the Yeoman scaffold, you will have the text plugin defined already, but not the css plugin. To either check this, or indeed carry out the task of configuration, locate your requirejs.config{}. This configuration will usually be found in js/main.js if you have used the scaffolds, but this may differ of course if you have hand crafted your application, or perhaps if you have more than one configuration (e.g. for unit-testing). Your basic requireJS configuration should look a little like this (notwithstanding additional paths and configurations that you may have added):

            requirejs.config(
            {
              baseUrl: 'js',
              // Path mappings for the logical module names
              paths:
              //injector:mainReleasePaths
              {
                'knockout': 'libs/knockout/knockout-3.4.0.debug',
                'jquery': 'libs/jquery/jquery-3.1.0',
                'jqueryui-amd': 'libs/jquery/jqueryui-amd-1.12.0',
                'promise': 'libs/es6-promise/es6-promise',
                'hammerjs': 'libs/hammer/hammer-2.0.8',
                'ojdnd': 'libs/dnd-polyfill/dnd-polyfill-1.0.0',
                'ojs': 'libs/oj/v2.2.0/debug',
                'ojL10n': 'libs/oj/v2.2.0/ojL10n',
                'ojtranslations': 'libs/oj/v2.2.0/resources',
                'text': 'libs/require/text',
                'css' : 'libs/require-css/css',
                'signals': 'libs/js-signals/signals'
              }
              //endinjector
              ,
              // Shim configurations for modules that do not expose AMD
              shim:
              {
                'jquery':
                {
                  exports: ['jQuery', '$']
                }
              }
            }
            );
          
    In the above1 path configuration you can see both the text and ccs plugins are defined as we require.
    When you are consuming Composite Components from outside of your codebase, you may be asked to add additional library paths to this configuration as well, just consult the supplied documentation for the Component.

    On to Creating the Composite...

    In this first example, I'm going to walk through the task of creating a very basic composite that displays an image and a name which will be passed in as parameters to the component2. I'll call the component ccdemo-name-badge. Our aim here is to create something a little like (but simpler than) the basic Composite Component demo in the cookbook.

    Note: In this basic article I'll be leaving a lot of detail out, but rest assured each topic of interest will be covered in much more detail later.

    Step 1 - Give it a Home

    The very first thing we need to do is to define a home directory for the Composite Component in the application. I'll discuss more about standards for naming etc. in the next article, so for now just go with the flow.

    1. Create a new directory called components under the existing js directory.
    2. Create a new subdirectory under js/components called ccdemo-name-badge

    Step 2 - Define The Composite Component Metadata File

    The JSON format metadata file is a key part of your composite component. It provides a declarative definition of the component in terms of the properties, the methods and any events that it supports. In this first simple example we're only going to worry about a couple of attributes. Methods and events will be covered in detail later in this series.

    As mentioned the metadata is defined as a JSON file so go ahead and create a new file in the js/components/ccdemo-name-badge directory called ccdemo-name-badge.json

    In this example Composite we just want to define two attributes badge-image and badge-name. To do this the JSON file needs to define a definition of a properties object, which in turn contains the definition of each of the above. Harder to say than actually do, here's what it would look like:

        {
          "properties":{
            "badge-name" : {
              "type" : "string"
            },
            "badge-image" : {
              "type" : "string"
            }
          }
        }
        
    And that's it, both properties will be strings as the type attribute indicates.

    Step 3 - Define the Template HTML

    In some cases the HTML template by be totally dynamic and impossible to define ahead of time. In our simple example, however, that's not the case. We have a well defined structure which we can create as an HTML template for the layout for the component.
    Create a new html file ccdemo-name-badge.html in the js/components/ccdemo-name-badge directory:

    <div class="badge-face">
          <img class="badge-image"
              data-bind="attr:{src: $props['badge-image'], alt: $props['badge-name']}"/>
          <h3 data-bind="text: $props['badge-name']"/>
        </div>
        
    So in this template you will notice the the knockout data-bind attribute is being used to define the attributes for the IMG and H2 tags. We are then binding to the $props object which the framework provides to give you direct access to the attributes of the Composite Component tag, in this case the badge-name and badge-image attributes.
    Important: if you cross reference this example with the basic Composite Component demo in the cookbook, you will notice a difference. Both fragments of HTML use the $props object to bind to data, but the cookbook version uses dot-notation e.g. $props.name whereas I've used the $props['badge-name'] notation. Both of these notations have the effect of mapping to an attribute of the $props object, but in my case, because my component property names have dashes in them I can't use the simpler dot notation as $props.badge-name is not valid syntax. So remember this when working with Composite Component attributes which contain a dash in their name.

    In later articles I'll show how you can bind to values other than just the attributes via $props in this way.

    Step 4 - Define the Component CSS

    In nearly every case you will have some style information associated with your component. As a standard you should always include a style for the component as a whole which will suppress the display of the component until everything is ready to go. The framework will automatically set the .oj-complete class onto the component to trigger the display when everything is ready. In this simple example, I'll supply this standard base class for the component as a whole that will control this visibility. Aside of that, there will be an additional badge-face class to style the actual badges and a further class for the badge image. The CSS file is called ccdemo-name-badge.css and is placed in the js/components/ccdemo-name-badge directory:

        ccdemo-name-badge:not(.oj-complete){
          visibility: hidden;
        }
    
        ccdemo-name-badge{
          display : block;
          width : 200px;
          height: 300px;
          margin : 10px;
        }
    
        ccdemo-name-badge .badge-face {
            height : 100%;
            width : 100%;
            background-color : #80C3C8;
            border-radius: 5px;
            text-align: center;
            padding-top: 30px;
        }
    
        ccdemo-name-badge .badge-image {
            height : 100px;
            width : 100px;
            border-radius: 50%;
            border:3px solid white;
        }
        

    Step 5 - Define the Component ViewModel

    In the long run, all Composite Components are going to exhibit some sort of behavior (if not then you should probably not be using a component in the first place). As such we'll need somewhere - a ViewModel JavaScript file - to act as the home for that behavior code. In this first simple example, I'll just stub out a very simple component ViewModel that does not actually do anything useful. This will illustrate your starting point for every Composite and will be where code can be added later on. To do this, create a new JavaScript file called ccdemo-name-badge.js in the home directory for the Composite Component. The content of the file should just define the component model skeleton as shown here:

            define(
                ['ojs/ojcore','knockout','jquery'
                ], function (oj, ko, $) {
                'use strict';
                function CCDemoNameBadgeComponentModel() {
                    var self = this;
                };
    
                //Return a constructor for this componentModel
                return CCDemoNameBadgeComponentModel;
            });
          
    Note that the return statement for the component viewModel is not creating an instance of the model, but rather is returning the constructor function itself. Taking this approach, each instance of the Composite Component that is used will have it's own distinct component model. This is what you want in most cases.

    Step 6 - Create the Component Bootstrap Script

    The final piece of the Composite creation process is to create the bootstrap file to register the Composite Component. This little script pulls together all of the artifacts that we have already created and used them to register the component with the framework. Without this script, nothing would happen!
    The bootstrap script is small, and in many cases will contain pretty much exactly the code show below with only the component name and define() block imports differing from component to component. In the js/components/ccdemo-name-badge directory, create a new JavaScript file called component.js as follows

          define(
            ['ojs/ojcore',
             './ccdemo-name-badge',
             'text!./ccdemo-name-badge.html',
             'text!./ccdemo-name-badge.json',
             'css!./ccdemo-name-badge',
             'ojs/ojcomposite'],
             function (oj, ComponentModel, view, metadata, css) {
             'use strict';
                oj.Composite.register('ccdemo-name-badge',
                  {
                      metadata: {inline: JSON.parse(metadata)},
                      viewModel: {inline: ComponentModel},
                      view: {inline: view},
                      css: {inline: css}
                  });
             }
          );
          
    Because this script is so important to the functioning of the Composite Component, it's worth examining it in a little more depth.

    Looking at the define block first of all, you can see that I define a requirement for each of the four previous files:

    1. './ccdemo-name-badge'→ ccdemo-name-badge.js which defines the component model
    2. 'text!./ccdemo-name-badge.html'→ the HTML template loaded using the requireJS text plugin
    3. 'text!./ccdemo-name-badge.json'→ the component metadata file, also loaded using the requireJS text plugin
    4. 'css!./ccdemo-name-badge'→ the ccdemo-name-badge.css file loaded using the requireJS css plugin
    You can see from the above why it is so important to ensure that you have the text and css plugins defined for requiredJS at the very start.
    These scripts and streams are injected into the bootstrap function as ComponentModel, view, metadata and css respectively. You are free to change the names of these function arguments of course, but using these names makes it pretty clear what each one will do.

    Within the bootstrap function, the code makes the all important call to oj.Composite.register(). This function does all the actual work of registering the custom Composite Component with the framework. The first argument to the register function is name name that you want to assign to the tag - in this case ccdemo-name-badge. This name does not have to really match the name of the directory we have created as a home for the composite or indeed the names we have used for the various files. However, it keeps everything much more organized and understandable if your component name matches the directory name that defines it, so there is no reason not to stick to this standard.
    The second argument to the register function takes an object which as we see here has four attributes:

    1. metadata
    2. viewModel
    3. view
    4. css
    Each of these is mapped to the corresponding objects passed into the main bootstrap function. Note how the metadata value is mapped through JSON.parse(). This is because the requireJS text plugin has just been used to read this file and we need to convert from text stream that that produced back into a JS object.
    You will also note that each of the above attributes are passed the injected file contents as an object with an attribute name of inline e.g.
        viewModel: {inline: ComponentModel},
        
    This is simply telling the component registration process that the passed object is the actual value that it should use for that attribute. It is possible, as we will see later in this series, to pass a promise rather than the object directly, however, you are unlikely to need to use that functionality when you are just starting out.

    There is more that can happen as part of the registration process, but really, this simple version is all that most Composite Components will need, so I'll leave it there.

    Using the Composite Component

    So now that our ccdemo-name-badge is complete we can use it in the application. That should be easy enough right? Just open your target view e.g. js/views/workArea.html in my case and add the new tag (using an appropriate value for the badge-image that actually points to an image that you have):

    <div>
              <h2>Test Composite</h2>
              <ccdemo-name-badge badge-name="Duke Mascot" badge-image="/images/duke.png"/>
          <:/div>
        

    Now run the application and navigate to the view that contains the Composite Component tag as necessary. What do you see? Well probably all you will see is the <H2> Test Composite text and nothing else. Why is that? Well just like any of the JET components, we have to tell the ViewModel that there is a dependency on the component in the first place so that it can be loaded. In order to do that I just have to add the component reference to the viewModel define block, in my case within the js/viewModels/workArea.js. Specifically we reference the bootstrap script name that registers the component (ccdemo-name-badge/component.js):

       define(['ojs/ojcore', 'knockout', 'jquery',
               'components/ccdemo-name-badge/component'],
         function(oj, ko, $) {
           function WorkAreaViewModel() {
             var self = this;
           }
    
           return new WorkAreaViewModel();
         }
      );
      
    With that in place, the Composite Component now renders as expected:
    Image of completed composite component

    What Next?

    Now that you've seen how to create a basic Composite Component we can start to drill down and explore various sub-topics in more detail. The next article in this series spends a little time on establishing your standards and conventions for creating Composites.


    Addendum - Creating the workArea ojModule

    Starting from the project structure created from basic Oracle Jet Yeoman basic template:

    1. Create a directory called views under the js root directory.
    2. Create a directory called viewModels under the js root directory.
    3. Create a new html file in the views directory called workArea.html. This can start off just containing an empty <div>, although you might want to put some text in there initially so you can see that the module has been successfully incorporated into the page.
    4. Create a new js file called workArea.js under the new viewModels directory. Set the contents of this file to the initial simple listing shown below.
    5. Edit the generated js/main.js file and add 'ojs/ojmodule' to the require list after the existing 'ojs/ojmenu' entry (remembering the comma).
    6. Edit the generated index.html file and locate the div with role="main". Inside this div you can add the reference to the new workArea module:
      <div data-bind="ojModule:'workArea'"/>.
      This is where all our subsequent content will appear.
    Code listing for workArea.js:
        define(['ojs/ojcore', 'knockout', 'jquery'],
          function(oj, ko, $) {
            function WorkAreaViewModel() {
              var self = this;
            }
    
            return new WorkAreaViewModel();
          }
        );
        


    1 The version numbers shown in the fragment above are reflective of the Oracle JET 2.2.0 release and may well be different if you are consuming a later version.

    2 This component is not intended to be actually useful, just to show the basics.


    0 0

    What if ... What if a database upgrade fails in between? First of all you should have enabled one of the common protections for issues happening during an upgrade: Guaranteed Restore Point to Flashback Database Restore an RMAN Online Backup Restore a partial Offline Backup See our slide's... [Read More]

    0 0

    image

    Attend our January edition of the SOA & BPM Partner Community Webcast live on January 31st 2017 at 16:00 CET.

    Oracle B2B and evolution to API Driven B2B

    This session will present an overview of Oracle B2B platform and show a demo of the current functionality. Oracle B2B is a highly available, high-performing B2B platform that is being used by major customers across different verticals such as retail, supply chain, and utilities. Hear from Product Management about the product overview, architecture, and best practices. Also hear about how B2B integration is evolving into an API driven B2B and hear about Oracle's vision and roadimage map.

    Krishnaprem Bhatia
    Twitter: KrishnapremB

    Krishnaprem Bhatia is product manager in the Cloud Integration product management team focusing on B2B, Healthcare and API Management products. He has over 15 years of work experience in software development and product management. As a product manager at Oracle he has worked extensively with customers and partners worldwide in all industry verticals. He holds Computer Science & Engineering and MBA degrees and loves to read, travel and work out.

    Call ID: 6965489 Call Passcode: 333111

    UK: +44 (0) 208 118 1001 & United States: 140 877 440 73

    More Local Numbers


    Schedule:

    January 31st 2017 at 16:00-17:00 CET

    Visit the registration page here.

    Missed our SOA & BPM Partner Community Webcast? – watch the on-demand versions:

    ·SOA 12 & BPM Suite 12c Roadmap update November 29th 2016

    ·Microservices October 25th 2016

    ·Oracle OpenWorld 2016 update September 27th 2016

    ·API Cloud Platform Service August 30th 2016

    ·BPM Suite & PCS Update July 26th 2016

    ·Integration Cloud Service June 28th 2016

    ·Sales Plays Webcast June 9th 2016

    ·Real-Time Integration Business Insight May 31st 2016

    For the latest information please visit Community Updates Wiki page (SOA Community membership required).

    SOA & BPM Partner Community

    For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

    BlogTwitterLinkedInimage[7][2][2][2]Facebookclip_image002[8][4][2][2][2]Wiki

    Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress,webcast


    0 0

    London App Brewery is a great organization run by Philipp Muellauer and Angela Yu, focused on mobile development. They organize workshops, training sessions, and events. Yesterday Oracle hosted a London App Brewery event about Oracle JET, at the Oracle office in central London: How to Visualise Data and Analytics on Mobile and Web Apps using Oracle JET.

    The event was well attended and very diverse, from students to professionals and from all kinds of industries. I introduced mobile development with Oracle JET to the group and there was a lot of discussion and interaction afterwards. People really appreciated how Oracle is taking an open source approach based on existing libraries and technologies, rather than reinventing the wheel and building new frameworks etc.

    There were also some nice Tweets:

    Anyone out there looking for a partner to organize sessions about mobile development in and around London, let Philipp and Angela know at London App Brewery, I can highly recommend them, they have a large database of technology enthusiasts and are great to work with! 

    Also, many thanks to my colleague Paul Tinker, who made all the connections between people and organizations and enabled everything to happen. :-) 


    0 0

    The 2017 RSA Conference is three short weeks away and Oracle is going to be there in force discussing whether cloud security is an evolution or revolution, why users are the new perimeter, and how to do the regulatory rumba!  If you are attending RSA, we would love an opportunity to meet with you there.... [Read More]

    0 0

    The M7-8 and M7-16 servers are data center servers designed with the highest reliability and availability features.These servers have a high redundancy of components and perform numerous health checks.

    Benefits of taking SPARC M7 Training

    Oracle University's hands-on training course covers the functions and features of the SPARC M7-8 and M7-16 servers. 

    Taking our 2-day S Oracle SPARC M7 Server System Administration course equips you with vital, in demand skills that empower you to do the following:

    • Install and configure M7 servers 
    • Identify the SPARC M7-8 and M7-16 server components and architecture
    • Perform system administration tasks, while maintaining and troubleshooting 
    • Upgrade software and firmware

    Expert instructors will discuss best practices for platform configuration and administration using ILOM, domain configuration and logical domain configuration. They'll also help you become familiar with data collection and fault analysis.

    Isn't it time to make yourself more attractive in a competitive global job market?

    Develop in demand expertise using the world’s most advanced high-end systems for enterprise workloads, with unique capabilities for information security, database and Java acceleration. 

    Learn more about this training course >

    We welcome any questions you may have in the comments section below.


    0 0

    Oracle Solaris is moving to a continuous delivery model using more frequent updates to deliver the latest features faster, while fully preserving customer and ISV qualification investment. Get the knowledge you need as an Oracle Solaris 11 System Administratorby starting with a career path to become an Oracle Certified Associate.

    An Associate level certification demonstrates your skill and fundamental understanding of the commands, and utilities used in Oracle Solaris 11 to deliver security, speed, and simplicity for enterprise cloud environments and DevOps.  A Professional level certification covers system administration skills such as configuring network interfaces, managing swap configurations, crash dumps, and core files.

    When you leverage Oracle Certifications with training, you get the benefit of being trained and tested by Oracle experts who want to make sure you are equipped with the right skills to do your job. Choose your path to get the most out of your investment with an Industry recognized credential from Oracle.

    To Get This Certification:Oracle Certified Associate, Oracle Solaris 11 System Administrator
    Take Related Training:Oracle Solaris 11 System Administration
    Pass Exam:Oracle Solaris 11 System Administration 1Z0-821

    To Get This Certification:Oracle Certified Professional, Oracle Solaris 11 System Administrator
    Pass Exam Above:
    Oracle Solaris 11 System Administration 1Z0-821
    Take Related Training:Oracle Solaris 11 Advanced System Administration
    Pass Exam:Oracle Solaris 11 Advanced System Administration 1Z0-822

    Advance your System Administrator Career! Please share any comments you have below and we will respond to your inquiries.


    0 0

    In my previous blog post I did showcase how to restart a failed database upgrade on the command line before Oracle Database 12c, with Oracle Database 12.1.0.x and with the new Oracle Database 12.2.0.x: Restarting a failed Database Upgrade with catctl.pl(Upgrade Blog - Jan 24, 2017) Here I'd like to... [Read More]

    0 0

    Windows 10 logoMicrosoft introduced a new model for updating Windows 10.  Instead of a traditional major upgrade cycle every few years, Microsoft has split their updates into three different "branches":

    • Current Branch (CB)
    • Current Branch for Business (CBB)
    • Long Term Servicing Branch (LTSB)

    Microsoft has an overview of this service model here:

    What is certified with EBS?

    E-Business Suite 12.1 and 12.2 are certified with all three Windows 10 service options: Current Branch, Current Branch for Business, and the Long-Term Servicing Branch. 

    All updates on all of those service branches are expected to work with EBS 12.1 and 12.2.  These updates include the Windows 10 Anniversary Update and the upcoming Windows 10 Creators Update. 

    EBS 12.1 and 12.2 customers do not have to wait for certification announcements before updating their Windows 10 desktop clients to any of the updates on any of the three Windows 10 service branches.

    What about EBS 11i and 12.0?

    In 2015 we certified the Current Branch (the version released by that date) of Windows 10 with EBS 11i, 12.0, 12.1, and 12.2.

    EBS 11i and 12.0 are now in Sustaining Support. This means that:

    • We have not tested any Windows 10 updates with EBS 11i since December 2015. 
    • We have not tested any Windows 10 updates with EBS 12.0 since January 2015.

    Support implications for EBS 11i and 12.0 customers

    We do not have any plans to test new Windows 10 updates (e.g. Windows 10 Anniversary Update or Creators Update) with either EBS 11i or 12.0.  We have no plans to release new EBS 11i or 12.0 patches for compatibility issues with new Windows 10 updates.

    We will issue new EBS 12.1 and 12.2 patches only to fix issues reported with Windows 10 updates that can be reproduced with EBS 12.1 and 12.2.

    If you are concerned about the ongoing compatibility of your Windows 10 desktops with EBS 11i or 12.0, you should:

    1. Upgrade to EBS 12.1 or 12.2
    2. Freeze your Windows 10 desktop configurations at their current working levels
    3. Perform you own testing of new Windows 10 updates before rolling them out to end-user desktops

    Related Articles


    0 0

    Introduction

    Now that we've covered the very basics of JET Composite Component creation, I wanted to step back and help you make sure that you get your standards set up correctly before you get any further and start to build your own.

    Here I'll cover four fundamental topics:

    1. Composite Scope
    2. Composite Naming
    3. CSS Styles
    4. Code organization

    Composite Scope

    A key decision to make when thinking about your use of Composite Components is exactly what constitutes a good scope for a reusable Composite Component. What I mean by that, is the task of finding the correct balance for your application in terms of how many components you need to express the required functionality and how complex each is. With any reuse mechanism such as JET Composites, there is an initial temptation to go overboard and define everything as a separate component. For example given the design goal of "We want to standardize how all our toolbars look"; should that be interpreted to mean I should have a single Composite Component to represent a standard toolbar? Well possibly, but does it also mean that I should have one component for an Insert toolbar icon, a second component for a "Delete" toolbar icon and so forth? Probably not... When considering how to effectively use Composite Components you'll have to balance the costs (both in development and runtime terms) verses the benefits. Each Composite has a cost, even just in terms of the contributing files that need to be loaded to create it. So, creating for example, a whole set of separate toolbar button specific Components would really be less than wise in most scenarios.

    Of course in some cases you will have an obvious re-use target in mind, for example, using this Composite as a plugin in a SaaS application, so that's really going to guide you well with respect to the scope of the thing. However, within the context of a normal application, you may have alternative mechanisms which may be more suitable as a vehicle for re-use. Examples of this may be the use of ojModule or even something as simple as Knockout templates if all you need is reusable UI.
    When thinking about a candidate for a composite component you should always try and evaluate if this use case is a good one and that can generally be judged by positive answers to questions such as:

    • Will I re-use this thing in lots of places?
    • Will a componentized version of this be easier to use?
    • Will this component encapsulate behavior as well as attributes
    The last of these is particularly important. If all you are doing is encapsulating some attributes and presenting them without events or custom methods then really a Knockout template will do the job just fine, you don't need the full power and cost of a composite component.
    Given this set of criteria, my simple example given in Part II of this blog series fails to pass the last test. However, I'm sure that you'll forgive me for trying to keep things simple for illustrative purposes at the beginning.
    Another good case for using a Composite is of course when it is a self contained component that takes care of managing particular set of data that is not directly sourced from the consuming application. An example of this might be something like a chat client that plugs into your app but which handles all of it's own server access and so forth. This is not a must-have feature though, there are many cases where a Composite will rely solely on data passed into it from the consuming application.

    Naming and your Composite Components

    First of all let's think about the actual tag and attribute names. Here we have some guidance as part of the Web Components specification. The standard here is simple and designed to reduce the chance of future name collision. Your HTML tag should contain at least a dash/hyphen (-) character. Hence <acme-coyote-tracker> would be a good name for a Composite Component tag, however, <CoyoteTracker> would not. The same would be true of attributes as well e.g. character-name rather than say just name although it is not required by the standard.

    A Note About Standard Element Attributes etc.

    When a composite Component is created, it extends the base HTMLElement type, as a consequence, every Composite Component already inherits a defined set of attributes, methods and events including the id and title attributes.

    Checklist of Naming Standards

    I'd suggest that you follow the following guidelines:
    1. Your tag should include a dash/hyphen character as defined by the Web Component Standard.
    2. Name your tag in a way that assigns some kind of namespace to it. For example, if your project or company is called "Acme" then use that as as prefix (acme-...). The aim here is to reduce the chance of naming collisions with other Web Components that you do not control.
    3. For tags, case has to be ignored as users are free to use any case in their document when referencing a tag, so stick to lower case in your definition to prevent confusion.
    4. CCA properties in the JSON metadata that define tag attributes can either use camel-case or the dash/hyphen character in the name of property to increase the expressiveness of the names whilst reducing the risk of collision with existing inherited attribute names. Note see CamelCase Composite properties below
    5. Be cautious about overloading the standard HTML attributes. For example you could use the value supplied by the standard title attribute as meaning something special to your component but that might end up confusing the user as it's not acting in the same way as other HTML elements. If in doubt, see rule 4.

    Camel-Case For Composite Properties

    You may notice a slight problem with the naming rules comparing tags and the tag attributes outlined above. I've said that case is ignored by the browser for tags, but then stated that you can use camel-case for the properties - surely the same rules apply? Well yes, and here's where things can get a little confusing if you're not paying attention. The tag name is supplied as the first argument to the oj.composite.register() API and that must certainly be lower case as a matter of course. The tag attribute names, however, are not actually directly defined for the Composite Component. Instead they are derived from the properties object that you define within the Composite Component metadata. The core rule for the actual tag attributes that are derived from these property definitions is the same as for the tag, i.e. they should be case insensitive, so the framework will do some mapping for you when the property information is read. If you define your property as being all lowercase (with or without a dash/hyphen) then the property name will be used directly as the attribute name. This is the approach I used in Article II. If, however, your name your property in mixed case e.g.:

          {
            "properties":{
              "coyoteName" : {
                  "type" : "string"
              }
            }
          }
          
    The the tag attribute that you would use to populate that when using the Composite Component would be called coyote-name. The attribute name is derived by breaking the string at the camel-case segments, inserting a dash/hyphen and converting all to lowercase. The framework will then manage the mapping between the hyphenated version and the defined property name that the Composite Component uses internally. Thus, the Component consumer may use component like this:
    <acme-coyote-tracker coyote-name="Wile E. Coyote"/>
          
    But then internally in code, or in its HTML template the component can use the camelCase reference and get the supplied value. e.g.
    <h2 data-bind="text:$props.coyoteName"/>
          
    The reason that you might want to use this approach is that if you defined the in-metadata property as "coyote-name" rather than "coyoteName" in the first place, then you would have to use the slightly more cumbersome property access syntax within your component:
    <h2 data-bind="text:$props['coyote-name']"/>
          
    So the choice is yours.

    File Naming

    As we saw in Part II, we will generally have up to five standard files involved in each Composite Component:

    1. The bootstrap / loader JavaScript
    2. The metadata JSON
    3. The HTML template file
    4. A CSS file
    5. The Composite ViewModel JavaScript
    The convention here is that the first of these is called loader.js or component.js. I actually prefer the latter of these two options simply because it makes the require instruction in ViewModels that consume the Composite Component a little more readable and indicative of what the thing is. e.g.
            define(['ojs/ojcore', 'knockout', 'jquery','acme-coyote-tracker/component'],...){}
            
    That being said either approach is fine.
    The remaining files for the Composite Component should share the same file name prefix as the associated tag, e.g. acme-coyote-tracker with the extension that represents their function:
      1. acme-coyote-tracker.json
      2. acme-coyote-tracker.html
      3. acme-coyote-tracker.css
      4. acme-coyote-tracker.js

      Class Naming

      Finally, for consistency you should think about how you refer to the Composite Component ViewModel throughout your code. This is in no way critical, but given that some standard is better than no-standard when it comes to helping others understand what your code is doing, it's a good idea to pick a naming convention and stick with it.
      My preferred convention is to derive the name for the mode class from the name of the component, with the dashes stripped and converted to camel case, with ComponentModel appended to the end. Thus for our acme-coyote-tracker component we use AcmeCoyoteTrackerComponentModel:

            define(['ojs/ojcore','knockout','jquery'],
              function (oj, ko, $) {
              'use strict';
                function AcmeCoyoteTrackerComponentModel() {
                var self = this;
                ...
                };
      
              return AcmeCoyoteTrackerComponentModel;
            });
            

      Styles

      In the basic sample shown in Part II of the series I discussed how you should at least define a simple class selector that suppresses the visibility of your Composite Component until the framework has completed it's processing. You should always include this as a matter of course as your default CSS.

              acme-coyote-tracker:not(.oj-complete){
                  visibility: hidden;
              }
      
              acme-coyote-tracker{
                  display : ...;
              }
            
      That aside, the core concern with any styles that your component requires will be the usual one of managing style conflicts. As such you should ensure the isolation of any classes that you define in this CSS by defining them in the context of the component:
              acme-coyote-tracker .desert-background{
                  background-image: url('images/paintedDesert.png');;
              }
            

      CSS Resource Loading

      In the example above, I'm using the url() directive to assign a background image to the desert-background styleclass. Note here that the location of these resources will be relative to the root directory for the component. Thus the paintedDesert.png will be, in this example, physically located in an images sub-directory which is a peer of the actual CSS file.

      Code Organization

      In terms of a single application where you put code for your composites is not critical it just needs to be consistent and of course easy to map in your requireJS configuration. If you are using a standard JET project layout, as generated by the Yeoman scaffolding, I'd recommend that you standardize on a location such as /js/components/, or similar, as the root for all your Composite Components, then you can place each individual Composite Component in its own subdirectory that shares the name of the component. Thereafter all the files that compose the Composite are referenced from this component root.

            /js
              /components
                /acme-coyote-tracker
                    component.js
                    acme-coyote-tracker.json
                    acme-coyote-tracker.html
                    acme-coyote-tracker.css
                    acme-coyote-tracker.js
                    /images
                       paintedDesert.png
            

      This latter point is important because you always want to load the resources required for the Composite from a location relative to the bootstrap script (./*)1:

            define(
            ['ojs/ojcore', './acme-coyote-tracker', 'text!./acme-coyote-tracker.html','text!./acme-coyote-tracker.json', 'css!./acme-coyote-tracker', 'ojs/ojcomposite'],
            function (oj, viewModel, view, metadata, css) {
                'use strict';
                oj.Composite.register('acme-coyote-tracker',
                    {
                        metadata: {inline: JSON.parse(metadata)},
                        viewModel: {inline: viewModel},
                        view: {inline: view},
                        css: {inline: css}
                    });
               }
            );
            

      You will note that in this case we're making the assumption that whatever JET application is consuming this Composite Component has the ojs path in its requireJS definition. This of course is a fairly safe bet, however, in general you are going to have to consider how to document a particular components dependencies particularly if non-JET shipped libraries are required.

      What's Next?

      In the next article I'll be diving into Composite Components in more detail and specifically looking at properties. 


      1 In a future article I will cover the nuances of loading Composite Components from outside of your application.


      0 0

      clip_image001

      JMS is perfect for setting transaction boundaries and in OSB it is pretty clear on how JMS transactions are handled. However, in SOASuite using the JMS adapter the SOA Infrastructure is handling your JMS transactions by default; and messages are removed from the queue rightaway because the Get's are Auto-acknowledged. If something fails, you would expect that messages are rolled back to the JMS queue and eventually moved to the error queue. But, again by default, not with the SOASuite/JMS Adapter. In that case the BPEL process, for instance, fails and get's in a recovery state, to be handled in the 'Error Hospital'in Enterprise Manager. But I want JMS to handle it! (Says the little boy...)
      So how do we accomplish that? Today I got the chance to figure that out.
      Start with a JMS setup with a JMS Server, Module and a Queue with an Error Queue that is configured to be the error destination on the first queue. On the first queue set a redelivery limit to 3 and a redelivery delay on for instance 60000 ms (or something like that). I'm not going in to that here.
      Create also a Connection Factory in the JMS Module with a proper jndi, something like 'jms/myApplicationCF'.
      In the JMS adapter on SOASuite there are several OutboundConnectionFactories already pre-configured. It is quite convenient to use the one with JNDI 'eis/wls/Queue'. But if you look into that, you'll see that it uses the default WebLogic JMS Connection factory 'weblogic.jms.XAConnectionFactory'. Not much wrong with that, but you can't configure that for your own particular situation. But more over it is configured with 'AcknowledgeMode' = 'AUTO_ACKNOWLEDGE'. As you can read in the docs there are three values for the AcknowledgeMode:

      • DUPS_OK_ACKNOWLEDGE, for consumers that are not concerned about duplicate messages
      • AUTO_ACKNOWLEDGE, in which the session automatically acknowledges the receipt of a message
      • CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message's acknowledge method

      So create a new outbound connection factory, with a JNDI like 'eis/jms/MyApp'. 
      Now, apparently we don't want  'AUTO_ACKNOWLEDGE', because that would cause the message-get acknowledged 'On Get'. So you could rollback until 'Saint Juttemis' (as we say in our family) but it won't go back on the queue. Dups aren't ok with me, so I'll choose 'CLIENT_ACKNOWLEDGE' here. Then there's another option: 'IsTransacted'. I want that one on 'true'. Then in ConnectionFactoryLocation, you'd put the JNDI of your JMS Connection factory, in my example 'jms/myApplicationCF'. So you'll get something like: Read the complete article here.

      SOA & BPM Partner Community

      For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

      BlogTwitterLinkedInimage[7][2][2][2]Facebookclip_image002[8][4][2][2][2]Wiki


      0 0

      clip_image002

      Oracle official sample Chef cookbooks and Puppet modules are now available on Oracle’s official GitHub page at https://github.com/oracle/chef-samples and https://github.com/oracle/puppet-samples for Java, WebLogic and Fusion Middleware.

      Chef and Puppet are arguably the most popular provisioning frameworks and we would like to help you with your WebLogic and Fusion Middleware provisioning by publishing samples for Chef and Puppet.  The Chef and Puppet sample modules and cookbooks are almost the same and are using the same development frameworks.

      We start this series of posts with an introduction what these cookbooks and modules can do and provide a simple quickstart how to create a WebLogic domain in Chef or Puppet on a Windows, Linux or Solaris host. In the following posts we will install FMW software, patch and extend a domain with FMW software.

      These Chef cookbooks and Puppet modules allow you install WebLogic together with Fusion Middleware on any Linux, Solaris or Windows host. The cookbooks should work in Chef 11 & 12 and can be used with Chef server or with Chef Solo. The modules should work on Puppet 3 & 4 and it should not matter if you use Puppet Enterprise, an agent or just use puppet apply.

      The first release on github will contain the following cookbooks and modules:

      • fmw_jdk, installs JDK 7 or 8 and optionally configures the urandom random number generator service for Linux distributions.
      • fmw_wls, installs WebLogic 11g or 12c and optionally create thes Oracle user and group on solaris and linux.
      • fmw_bsu, patches a WebLogic 11g middleware home.
      • fmw_opatch, patches WebLogic 12c or any Fusion Middleware 11g, 12c product.
      • fmw_inst, installs FMW 11g, 12c product including Oracle SOA Suite, Service Bus, MFT, OIM, ADF Runtime, and WebCenter.
      • fmw_rcu, creates a 11g, 12c Common or SOA Suite FMW repository on an Oracle Database.
      • fmw_domain, creates a domain in development mode, configures the node manager, start the admin server and extend the domain with ADF/JRF, Service Bus, SOA Suite and optionally with BAM and Enterprise Scheduler.

      A couple of important notes about these cookbooks and modules:

      • They don’t download any (free or licensed) software from OTN, Oracle support or edelivery, this is the responsibility of the user/customer.
      • Oracle Support won’t support these cookbooks or modules but you can raise issues or send us pull requests on github.
      • Binaries should be locally accessible in a directory or a network share.
      • They will create a domain only in development mode.
      • They won’t do multi-node provisioning like pack/unpack of a domain on cluster nodes.
      • Passwords in Chef can be defined in databags and in Puppet you need to do it yourself in Hiera.
      • They have dependencies to each other and will automatically include or require the depended manifest or recipe.
      • The default recipe/manifest does not do anything, you have to use the specific recipes or manifests. In Puppet the default manifest will be used to set some module defaults.

      Detailed overview

      These cookbooks and modules contains recipes and manifests with resource/providers in Chef and type/providers for Puppet. The recipes and manifest are a quick way to get you started and these minimal recipes are just calling the matching resource/type providers. You can call these yourself in one of your own cookbooks. Read the complete article here.

      SOA & BPM Partner Community

      For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

      BlogTwitterLinkedInimage[7][2][2][2]Facebookclip_image002[8][4][2][2][2]Wiki


      0 0

      Make sure you take a look at the January Updates below:

      Critical Patch Updates(CPU) are collections of security fixes for Oracle products. Oracle strongly recommends applying the patches as soon as possible.

      ·Critical Patch Update for January 2017 Now Available

      Latest upgrade recommendations for E-Business Suite updates and technology stack components.  These quarterly recommendations are based upon the latest updates to Oracle's product strategies, latest support timelines, and newly-certified releases. 

      ·Quarterly EBS Upgrade Recommendations: January 2017 Edition

      JRE codeline that are certified with Oralce EBS 12.1 and 12.2. Standard policy is that all E-Business Suite customers can apply all JRE updates to end-user desktops:

      ·JRE 1.8.0_121 Certified with Oracle EBS 12.1 and 12.2

      ·JRE 1.7.0_131 Certified with Oracle E-Business Suite 12.1 and 12.2

      ·JRE 1.6.0_141 Certified with Oracle E-Business Suite 12.1 and 12.2


      0 0

      Let’s say you have some files, stored as BLOBs, in your database, and you want to make them available via REST. So of course you install Oracle REST Data Services, and now you have two options: REST Enable the table or Deploy a custom RESTful service With the first option, I get an ‘automatic’ REST... [Read More]

      0 0

      Microsoft recently announced the availability of Windows 10 version 1607, also known as the Windows 10 Anniversary Update.  With this latest release, Microsoft is desupporting the first release of Windows 10 -- version 1507 -- on March 26, 2017. After that date, no new patches will be created for version 1507.

      Oracle's policy for the E-Business Suite is that we support certified third-party products as long as the third-party vendor supports them.  When a third-party vendor retires a product, we consider that to be an historical certification for EBS.

      What can EBS customers expect after March 2017?

      After Microsoft desupports Windows 10 version 1507 in March 2017:

      • Oracle Support will continue to assist, where possible, in investigating issues that involve Windows 10 version 1057 clients.
      • Oracle's ability to assist may be limited due to limited access to PCs running Windows 10 version 1057.
      • Oracle will continue to provide access to existing EBS patches for Windows 10 version 1057 issues.
      • Oracle will provide new EBS patches only for issues that can be reproduced on later operating system configurations that Microsoft is actively supporting (e.g. Windows 10 version 1607)

      What should EBS users do?

      Oracle strongly recommends that E-Business Suite upgrade their end-user desktops from Windows 10 version 1057 to the latest certified equivalents.  As of today, Windows 10 version 1607. 

      What about EBS desktop-based client/server tools?

      EBS sysadmins might use up to 14 different desktop-based tools to administer selected parts of the E-Business Suite.  These are:

      Still in use (i.e. eligible for Error Correction Support)
      • BI Publisher (BIP/XMLP)
      • Configurator Developer
      • Discoverer Administrator/Desktop
      • Forms/Reports Developer
      • JDeveloper OA Extensions
      • Sales for Handhelds
      • Warehouse Builder
      • Workflow Builder
      • XML Gateway Message Designer
      Obsolete
        • Applications Desktop Integrator (ADI)
        • Balanced Scorecard Architect (BSC)
        • Financial Analyzer
        • Financial Services Suite
        • Sales Analyzer Client

      All of the tools still in use are certified with Windows 10 version 1067.

      For complete details, see:

      Related Articles


      0 0

      To get started on Oracle Linux, the first step is to learn to install this operating system. By taking the Oracle Linux System Administration training you can learn how to:

      • Obtain Oracle Linux operating system software
      • Describe the Anaconda installer
      • Install Oracle Linux
      • Describe the Firstboot utility

      If you are using Oracle Linux 7, you can take the Oracle Linux 7: System Admin coursein the following formats:

      • Training-on-Demand: Start training within 24 hours, following lecture material through streaming video at your own pace and booking time to get hands-on experience when suits your schedule.
      • Live-Virtual Event: Attend a live event from your own desk, no travel required. Choose from a selection of events on the schedule to suit different time-zones including 6 and 27 February, 6 March, 3, 10, 17, and 24 April and 15 May 2017.
      • In-Class Event: Travel to an education center to take a class. Below is a selection of in-class events already on the schedule.
       Location  Date  Delivery Language
       Brisbane, Australia
       27 February 2017  English
       Perth, Australia
       6 March 2017  English
       Sao Paolo, Brazil
       20 February 2017  Brazilian Portuguese
       Cairo, Egypt
       19 February 2017  Arabic
       San Salvador, El Salvador
       22 May 2017  Spanish
       London, England
       3 April 2017  English
       Paris, France
       27 February 2017  French
       Berlin, Germany
       27 February 2017  German
       Hamburg, Germany
       27 February 2017  German
       Munich, Germany 
       15 May 2017  German
      Milan, Italy
      10 April 2017 Italian
      Rome, Italy
      6 February 2017 Italian
      Turin, Italy
      13 February 2017 Italian
      Dehli, India
      24 January 2017 English
      Wellington, New Zealand
      13 February 2017 English
      Makati City, Philippines
      8 May 2017 English
      Pasig City, Philippines
      13 February 2017 English
      Singapore
      17 April 2017 English
      Johannesburg, South Africa 27 February 2017 English
      Bangkok, Thailand 27 February 2017 English
      Belmont, CA, United States 13 February 2017 English
      Orlando, FL, United States 13 March 2017 English
      Reston, VA, United States 17 April 2017 English

        If you are using an earlier version of Oracle Linux, take the Oracle Linux 5 & 6 System Administration course in the following formats:
        • Training-on-Demand: Start self-paced training within 24 hours.
        • Live-Virtual Event: Attend a live event from your own desk, no travel required. Events are added to the schedule to suit different time-zones.
        • In-Class Event: Travel to an education center to take a class. Below is a selection of in-class events already on the schedule.

         Location Date
        Delivery Language
        Brussels, Belgium 3 April 2017 English
        Helsinki, Finland
        6 February 2017 English
        Munich, Germany
        24 April 2017 German
        Tokyo, Japan
        13 February 2017 Japanese
        Utrecht, Netherlands 3 April 2017 English
        Pretoria, South Africa 5 June 2017 English
        Chicago, IL, United States 27 February 2017 English
        Belmont, CA, United States 3 April 2017 English
        Reston, VA, United States 1 May 2017 English

          Resources:


          0 0

          clip_image002


          Oracle Fusion Middleware provisiong is always a critical prerequisite which will substantially influence the success or failure of our development projects. Those of us who have spent many years working with this toolset in its many versions, should know for sure what a distressful experience it is to work with sloppily or incorrectly provisioned environments.

          Provisioning can also consume a lot of our precious time, whether it is performed locally or in controlled environments belonging to our organization / customer. As the components have evolved, setup options have also become increasingly complex and diverse (although maybe friendlier from a UI perspective), and even though we may have mastered this craft and are capable of producing a nice and shiny configuration, replicating this consistently and for multiple environments where we can expect high variance regarding product versions, particular requirements, limitations and criticality levels, is without any doubt a very challenging and potentially error-prone endeavor. Add dependencies, intangibles and deadlines to the mix and this can become as complicated as any other project task.

          Nevertheless, for the time being and with all the tools at our disposal, this provisioning processes can be easily streamlined and automated, so we can stop the suffering while also learning some really exciting stuff and providing value to our organization / customer.

          Automated provisioning: what are we looking for?

          This “value” we’ve mentioned may represent lots of things when talking about an optimized provisioning cycle, for example:

          • Agility / Speed: which will also translate into developer productivity, time to market and enhanced DR / scaling capabilities.
          • Consistency / Standardization: so we can focus mostly on resolving business-oriented challenges rather than tripping up with environment-related issues.
          • Change management: being able to evolve our environments by patching, upgrading and fine tuning in an orderly fashion, and without the fear of it collapsing like a house of cards at the minimum alteration.
          • Competency building: so your team will be able to learn, perform and improve well-delimited and highly repeteable tasks rather than playing “heroball” (where everyone and everything ends up depending on a single engineer’s prowess and availability, sound familiar?)

          So, which options do we have?

          There are so many, but let’s talk about some of them and provide some examples and references. For instance, we will always have the good old config wizard: Read the complete article here.

          SOA & BPM Partner Community

          For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

          BlogTwitterLinkedInimage[7][2][2][2]Facebookclip_image002[8][4][2][2][2]Wiki


          0 0

          Introduction

          In this article I'm going to drill down on all aspects of attributes and data in JET Composite Components. In the initial tutorial article we just referenced the tag attributes directly in the HTML template via the $prop object. In this article I'll expand on that and look at a whole range of related topics including the following:

          • How to access attribute values from within the component ViewModel
          • Changing attribute values in an already rendered Composite Component
          • Reacting to attribute value changes within the component
          • Binding to data in an external viewModel
          • The attribute definition metadata in detail
          And more besides. For illustration throughout, I'll be referring back to and extending the simple Composite Component developed in Article II in this series. If you want to follow along you might want to jump back and review that article if you've not already been through it.

          Terminology - Properties v's Attributes

          To clear up some nomenclature before we start, when I refer to attribute I mean the attribute on the custom component tag that a consumer will use within their views to embed the Composite Component. This attribute will map directly to a Composite Component property which we have pre-defined in the Composite Component metadata. So largely the two terms can be used interchangeably, however, as we'll discuss the name of the attribute does not always match the name of the corresponding property. Additionally it is possible for a Composite Component to define internal properties which are not surfaced to the consumer as tag attributes.

          Accessing Composite Components Property Values

          With any component, an obvious requirement is to be able to somehow pass data into the component and to do that in a structured way that defines the API of the component itself. The JSON metadata file associated with the component (see ccdemo-name-badge.json in Article II in this series) defines the component API and as part of that declares the properties which will be exposed as attributes on the component tag. So how do we utilize these attribute values from within the component?

          Directly in the Component View

          As we saw in the basic tutorial outlined in Article II of the series, the simplest way to access the attributes passed to the component tag is via the $props object. This can be used directly in the HTML of the view template used by the component, for example:
          <span data-bind="text:$props.propertyname" />
          or
          <span data-bind="text:$props['propertyname']"/>
          The latter form being for when the actual name of the property as defined within the Composite Component metadata is not a valid identifier for use with dot notation, for example it contains a dash/hyphen.

          So the use of $props gives us a direct passthrough for the UI and because the $props object internally is backed by observables, any changes made to it will be automatically be propagated.

          Inside of the Component ViewModel

          What if you need to access the value of an attribute/property from within the component viewModel? This is a pretty common case as well, so let's examine that.

          At this point we encounter the Composite Component lifecycle for the first time. I'll be covering the entire lifecycle in a later article, and for now we'll just look at the basic approach of getting access to the attribute values when the Composite Component has been provided with a Component viewModel constructor during registration1 - This was the approach that I took in Article II.

          When a Composite Component is registered with a constructor function as the viewModel (as opposed to being passed an object instance), the framework will automatically call this constructor to create a viewModel for the instance of the component being created. At this stage, we actually need to go back to the ccdemo-name-badge.js file from that sample, and make a slight change. When the new instance of the component viewModel is created, this constructor is used, but it is also passed a context object which contains information that we will need in order to access the passed attributes as properties. So lets make that change to ccdemo-name-badge.js first of all:

              define(
                  ['ojs/ojcore','knockout','jquery'
                  ], function (oj, ko, $) {
                  'use strict';
                  function CCDemoNameBadgeComponentModel(context) {
                      var self = this;
                  };
          
                  //Return a constructor for this componentModel
                  return CCDemoNameBadgeComponentModel;
              });
              
          So the constructor function now receives a context object. For the purposes of this article we only care about one of the properties of this context object:
          • props - a promise which returns a map of the attributes passed to the component
          So let's amend the constructor function to use the props promise to access one of the attributes passed to the component by the consuming view.
                define(
                    ['ojs/ojcore','knockout','jquery'
                    ], function (oj, ko, $) {
                    'use strict';
                    function CCDemoNameBadgeComponentModel(context) {
                      var self = this;
                      context.props.then(function(propertyMap){
                          //Save the resolved properties for later access
                          self.properties = propertyMap;
                          //Extract the badge-name value
                          var badgeNameAttr = propertyMap['badge-name'];
                    };
          
                    //Return a constructor for this componentModel
                    return CCDemoNameBadgeComponentModel;
                });
                
          Of course in this example, I'm not doing anything useful with the badgeNameAttr value I'll do that next. Note as a matter of course, once the propertyMap is resolved I store that for later reference from elsewhere in the component.     

          Component Data that is Not Mapped to Attributes / Properties

          Whilst we're considering Composite Component data in terms of values passed in through attributes, we should also acknowledge that in a lot of cases, data used within the component may be derived in some other manner. Often the data will be associated with some external service or simply generated within the Composite Component itself.
          In this respect, Composite Components are just like any other Knockout based module. The viewModel for your component view is, of course, the same component ViewModel that we've used above. As such, any properties (e.g. observables) defined in the component model are available for reference inside of your template HTML. To illustrate this, let's make a simple change to the ccdemo-name-badge component where we add a property within the component ViewModel that massages the supplied badge-name attribute to create an uppercase version of the first segment of the name. This results in an updated component that looks like this:
          Updated composite component showing uppercase first name
          Doing this will require us to access the badge-name property as we did above and assign that to another variable which is private to the component model called uppercaseFirstName. This involves a minor change to the code we already have, I'll just show the promise then clause for brevity2:

            context.props.then(function(propertyMap){
              //Save the resolved properties for later access
              self.properties = propertyMap;
              //Extract the badge-name value
              var badgeNameAttr = propertyMap['badge-name'];
              //Do something with the badge name
              self.upperFirstName = badgeNameAttr.split('')[0].toUpperCase();
            };
            
          Then the new upperFirstName value can be used using a Knockout binding in the usual way. Here's the updated version of the view for the composite component where the upperFirstName value on the component model is used directly (no reference to $props).
          <div class="badge-face">
              <img class="badge-image"
                  data-bind="attr:{src: $props['badge-image'], alt: $props['badge-name']}"/>
              <h2 data-bind="text: upperFirstName"/>
              <h3 data-bind="text: $props['badge-name']"/>
            </div>
            

          Traversing the Knockout Binding Hierarchy

          A note of caution. If you are an advanced Knockout user you might be accustomed to walking up the binding hierarchy using data-bind expressions that refer to sources such as $root or $parents[n] and so forth.
          Now these expressions will still have a place in your code when working in the context of say a foreach and other structures nested within the scope of the Composite Component. However, what you should try to avoid is any case where you are reaching out from the Composite Component into the ViewModel hierarchy of the view that is consuming the component. By doing so, you would be making assumptions about the environment in which the Composite Component is being consumed. This effectively introduces invisible dependencies on consuming applications adding to the burden of documentation and consumption of the component.

          Binding Data by Reference

          In the example that we've been looking at so far, the attribute values being used by the Composite Component have been effectively hardcoded into the tag in the consuming view. e.g.

          <ccdemo-name-badge badge-name="Duke Mascot" badge-image="/images/duke.png"/>
            
          What we might want to do, however, is to make it a two-way street and not only pass values into the Composite Component, but to allow the component to change that value and pass it back to the consuming view. Having this functionality makes a component much more useful as you can start to use it in editing environments such as forms or editable tables. The good news is that the Composite Component Architecture supports this out of the box with only a small amount of configuration required in the definition of the Composite Component properties. Before we look at the metadata let's look at the syntax from the perspective of the consuming view that is using the Composite Component. The consuming view can pass a reference to a property within it's viewModel by enclosing the property name in double braces {{...}} for a read-write reference and square brackets [[...]] for a read only reference3. To see this in action, I'll amend my sample to first of all add the name and image information that I need to the viewModel of the workArea module:
            define(['ojs/ojcore', 'knockout', 'jquery','components/ccdemo-name-badge/component'],
              function(oj, ko, $) {
                function WorkAreaViewModel() {
                  var self = this;
                  self.personName = ko.observable('Duke Mascot');
                  self.personImageURL = ko.observable('/images/duke.png');
                }
          
                return new WorkAreaViewModel();
              }
            );
            
          Now the view for the workArea module can use the reference syntax instead of hardcoding, I'll pass the personName in as a writable value and the personImageURL as read-only using those two variations on the syntax:
          <div>
                  <h2>Test Composite</h2>
                  <ccdemo-name-badge badge-name="{{personName}}" badge-image="[[personImageURL]]"/>
              <:/div>
            
          So now, without any change, the Composite Component is now being fed with dynamic, rather than hardcoded data.

          One nice feature of this automatic binding is that the framework will handle the conversion of the data from and to the observable for you automatically. So a change of the observable value in the consuming viewModel will be automatically reflected into your Composite Component as well without you needing to write any code (and visa-versa).
          Note, however, that changes to an externally supplied reference values like this will not re-run the Composite Component lifecycle, so, should you have internal mechanisms within the Composite Component that need to react to the value change in an attribute value then you will either have to handle this through a computed observable or through property change listeners which is something that I'll cover in the next article in this series.

          Attribute Metadata in Detail

          Next, let's look at the Composite Component Metadata that is used to specify the properties (and therefore tag attributes) of the component.
          So far, we've seen a very simple definition where only the property name and the datatype was supplied. However, there are a few more options that are supported. Let's go through the full list:

            {
              "properties": {
                "your-property-name": {
                  "description" : "Some descriptive text",
                  "type": "string | boolean | number | array | object | function ",
                  "value" : some value as per the selected type,
                  "readOnly" : true | false,
                  "writeback" : true | false,
                  "enumValues" : array of valid values
                }
              }
            }
            

          A Note on Property Name

          Before diving into the attributes of the property definition itself, I just wanted to remind you about the effect that the name that you actually select for your property can have. This is covered in detail in Article III in this series (Conventions and Standards). The point to remember is that if you use camel-case in the name that you choose for your property int he metadata, this will be mapped to an attribute with a slightly transformed name to allow it to work in an HTML document. Thus a property defined in the metadata with the name myProperty would actually be used/set in the document tag as the tag attribute my-property

          The description Property

          The description, as the name suggests, provides you with a place to add some textual documentation about the purpose of the Composite Component property. This information is currently for documentation purposes only and has no impact at runtime. It is therefore not required although of course it's use would be recommended. In the future, design time tooling that exposes Composite Components will be able to use the description to improve the design time experience.

          The type Property

          Type is of course the key property for the definition. If the user supplies a value in the tag attribute that does not match the declared type then the framework will log an error message in the form:
          Unable to parse value <supplied-value> for property <your-property-name> with type <defined-type>.
          In this case, the property will remain as un-set (i.e. undefined in the property map that is passed via a promise to the Composite componentModel instance). Additionally note that:

          1. If the offending property had a defined default value, this will not be set in this case.
          2. The other properties of the Composite Component will be processed normally
          3. Apart from the logged message on the console, the framework will take no remedial or "stopping" action. The lifecycle of the Composite Component will proceed as normal
          Thus it is your responsibility to always check each Composite property that you use in an appropriate manner when the promise is resolved.

          The common primitive types that you would use for your properties are:

          • string
          • number
          • boolean
          The framework will attempt to coerce any type supplied directly in the tag to these types for you. You can also specify non-primitive types for example:
            {
              "properties": {
                "namesArray": {
                  "type": "array",
                }
              }
            }
            
          Which could be used either with a Knockout binding to pass the array, or handily the framework will also resolve this into a array of size 4 in the property value:
          <my-tag names-array='["John","Paul","George","Ringo"]'>
            
          Likewise you can define a general object type:
            {
              "properties": {
                "personObject": {
                  "type": "object",
                }
              }
            }
            
          And pass a JSON string:
          <my-tag person-object='{"name":"Fred Flintstone","age":31}'>
            
          Note that in both the array and object case we have to use double quotes within the attribute value to enclose any string values, so the tag attribute as a whole must use single quotes if values are being passed in-line in this fashion.

          When using these non-primitive types you would generally not be expecting the user to enter JSON strings directly into the tag attribute. In most cases the values will be passed in from the enclosing viewModel (e.g. using the {{...}} or [[...]] notation as discussed). However, the onus will be on you to validate the property values provided just in case the consumer has entered a JSON string manually and made a mistake.

          Function Callbacks

          The final type you can see in the metadata illustration above is function. As the name suggests this allows you to pass a function reference / callback from the consuming viewModel. Such callbacks will allow you to achieve a much smoother integration with the calling application. You might, for example, use this to carry out lazy loading or other integration tasks which need to take place in the context of the caller rather than the Composite Component. Function references are passed to the Composite Component via the tag attribute, using the {{...}} notation4 e.g.

          <my-component scroll-next={{moreRowsCallback}} />
            
          Obviously before using such callback functions you will want to be careful about documenting exactly what the shape of the callback function should be.

          The value Property

          The value property of the Composite property definition provides a default value for that property should the consumer not provide the value via the tag attribute. One slight catch to watch out for here concerns types. If the type of this default value does not match the declared type of the property as a whole it will still "win" if the attribute is not supplied via the tag markup. Thus in the case:

              {
                "properties": {
                  "doSomething": {
                    "type": "boolean",
                    "value" : "true"
                  }
                }
              }
              
          If the do-something attribute is not supplied by the consumer then the property will be made available with the default value as part of the properties map, but as a string value not the expected boolean.

          The readOnly Property

          The readOnly property is a boolean attribute which, if set to true, prevents the property from being mapped from the tag attributes. This then provides a convenient way to create an internal property for the Composite Component that can still be manipulated from within the component itself, but which cannot be set directly by the consumer. If a default value is set for the property in question, it will be respected. If the consumer tries to supply the value as part of the component tag it will simply be ignored.

          The writeback Property

          Writeback is specifically used in cases where you wish to allow the Composite Component to be able to consume a binding via the {{...}} syntax and to make it a two way conversation. If writeback is set to true, the observable that was passed into the component will automatically be kept updated with any changes made to the associated property within the component. This means that you don't have to write any plumbing code to keep the consuming page in step with the composite. If writeback is false then changes made within the compenent will not be propagated back.

          The enumValues Property

          The enumValues property will be ignored in versions of Jet prior to 3.0, although you can use it for documentation-only purposes before then. As the name suggests, when used with a string type of property, enumValues will allow you to restrict the valid values that can be supplied.

          Updating Properties

          Finally for this article let's look at updating properties. Although the properties are initially populated from the tag attributes they are not read-only. You are able to store the reference to the properties map once the initial promise has been resolved, this is what I have been doing in the code samples above by assigning to self.properties. Then you can just update the values as required. If the property that you change the value of is associated with a bound value from the consuming view, and the writeback property is set then the framework will automatically synchronize the consuming view attribute with the new property value that you have stored. This also true if you simply have an input bound to the attribute via the $props reference e.g.

          <input type="text" data-bind="ojComponent:{
                               component: 'ojInputText',
                               value:$props.inputValue}"/>
            

          An Important Note About Complex Objects

          When a binding reference is passed to your Composite Component, any auto-propagation of changes between the component and source of the binding are based on object identity. When you bind a complex object type via {{...}} or [[...]] notation is it possible to update a child property of that object without effecting the top level object identity. The effect of this is that it is possible for a Composite Component to actually update a property of such a complex object even when writeback is set to false or the object was passed with [[...]] notation. In order to prevent this from happening if it is a problem for you, you will have to clone the incoming object when you parse your properties. Such a clone would be fully decoupled from the source object.

          What's Next? 

          Hopefully that's a good primer on Composite Component Properties. In the next article, I'll be looking at Composite Component events.


          1 Actually here's where things get a little complicated. In reality, there are two ways that the component can get initialized and the properties read. Either as part of the object constructor function as I've shown here or using the initialize() lifecycle method which will be called when an object instance was passed to the component registration.

          2 Generally in these code samples I'm trying to keep things simple and compact, as such I'm also going to omit error checking logging and all that other good stuff you would have in a real application.

          3 The [[...]] binding notation implies read-only with respect to the data origin. It is possible to change the property value but that change is kept private to the Composite Component and not written back to the source observable. (Not withstanding the note about complex objects).

          4 Actually you can use either {{...}} or [[...]] notation to point to the function reference, however, given the implicit meaning of a function callback the curly brace notation seems to be more correct as the one to standardize on.


          0 0

          Dear Integration Experts

          As an Oracle Partner Network Gold member or higher we would like to offer you:

          • free ICS trail services
          • free ICS certification
              once you become a member (free of charge) in the

          SOA Partner Community

            .

          As a community member you receive also our monthly updates with the latest PaaS information including sales &  marketing kits, product updates and trainings. Please first login at Oracle Partner Network and then visit SOA Partner Community. If you have any questions please contact the Oracle Partner Business Center.

          SOA & BPM Partner Community

          For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

          BlogTwitterLinkedInimage[7][2][2][2]Facebookclip_image002[8][4][2][2][2]Wiki

          Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress


          0 0

          When we talk about database upgrades and migrations the most important (and unfortunately time-/resource consuming) activity is testing. But often testing resources are limited or, even worse, don't exist. I've worked with customers where we migrated a core EBS system off AIX to Linux - but only got a 6 year old... [Read More]

        older | 1 | .... | 959 | 960 | (Page 961) | 962 | 963 | .... | 989 | newer