Posted on

skinning of af:panelBox in Oracle ADF

Requirement – To change the background color of panelBox header in ADF.

Solution- Intial it looks very easy.But its not.You cant change the background color of panelbox because, As the panel box is build using images (because of the rounded border) you have to use a set of images to change the color.

try below code in your skin file and you can skin your panelBox. You have to set the background as none.

af|panelBox::header-center {
background-color:#1F3B88;
color: #1F3B88;
}

af|panelBox::header-text {
color:White;
}

 af|panelBox::header-start:core:default {
    background-image: none;
    display: none;
    background: #1F3B88 ;
     background-color: #1F3B88;
}

af|panelBox::header-center:core:default {
    background-image: none;
    background: #1F3B88 ;
    background-color: #1F3B88;
}

af|panelBox::header-end:core:default {
    background-image: none;
    display: none;
    background: #1F3B88 ;
    background-color: #1F3B88;
}

af|panelBox::footer-center:core:default {
    background-image: none;
    display: none;
}

af|panelBox::footer-start:core:default {
    background-image: none;
    display: none;
    background: #1F3B88;
    background-color: #1F3B88;
}

af|panelBox::footer-end:core:default {
    background-image: none;
    display: none;
    background: #1F3B88;
    background-color: #1F3B88;
}

af|panelBox::center:core:default {
    background-image: none;
    border-left: none;
    background: #1F3B88;
    background-color: #1F3B88;
}

You will be able to skin panelbox like below diagram

blog

That’s it. Happy skining with Vinay in techartifact.

Posted on

!important CSS Declarations: How and when to use in ADF Skin

While designing in ADF skin.I came across of significance of !important. ADF developer always afraid of CSS like me. 😛

now we should understand meaning of this

What it says; that ‘this is important, ignore subsequent rules, and any usual specificity issues, apply this rule!’

In normal use a rule defined in an external stylesheet is overruled by a style defined in the head of the document, which, in turn, is overruled by an in-line style within the element itself (assuming equal specificity of the selectors). Defining a rule with the !important ‘attribute’ (?) discards the normal concerns as regards the ‘later’ rule overriding the ‘earlier’ ones.

Also, ordinarily, a more specific rule will override a less-specific rule. So:

a {
    /* css */
}

Is normally overruled by:

body div #elementID ul li a {
    /* css */
}

As the latter selector is more specific (and it doesn’t, normally, matter where the more-specific selector is found (in the head or the external stylesheet) it will still override the less-specific selector (in-line style attributes will always override the ‘more-‘, or the ‘less-‘, specific selector as it’s always more specific.
If, however, you add !important to the less-specific selector’s CSS declaration, it will have priority.
Using !important has its purposes (though I struggle to think of them), but it’s much like using a nuclear explosion to stop the foxes killing your chickens; yes, the foxes will be killed, but so will the chickens. And the neighbourhood.
It also makes debugging your CSS a nightmare (from personal, empirical, experience).

Lets take an example of ADF skinning.

af|inputText::label
{
background-color: transparent  !important;
background: transparent ;
color : White;
font-weight: bold;
font-size: small;
 margin: 0px;
padding:0px 4px !important; 
}

We will define now an style class for using inputText anywhere other place with different layout like 

.AfInputSizeBig af|inputText::label
{
background-color: Blue;  // see this
background: transparent ;
color : White;
font-weight: bold;
}

If you use AfInputSizeBig style class any where else but back ground color of input label is always transparent because if !important definition earlier.
You should be very careful while creating ADF skin.If you are very sure about cascading of style then use this !important .

I will post more on ADF Skinning.

Till than happy learning with Vinay in Techartifact….

Posted on

Optimistic Lock vs Pessimistic Lock – Application Module in Oracle ADF

ADF BC (Application module) manage the state of data. It have two locking mechanism -Optimistic Lock and Pessimistic Lock.Locking is Database specific feature which prevents users from different transactions to modify the same data concurrently.
In ADF , we will specify the locking mode either as optimistic/Pessimistic in adf-config.xml file.

We can the locking mode in Application Module -> Configuration -> AppModuleLocal/Shared -> Properties tab.

For the property, jbo.locking.mode it will show either optimistic /pessimistic. It will take the value overridden in adf-config.xml file.. It have same concept of database. Database also have same two locking mechanism.
Now understand each other –

Pessimistic Locking is when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks. To use pessimistic locking you need either a direct connection to the database (as would typically be the case in a two tier client server application) or an externally available transaction ID that can be used independently of the connection.

Example- user A (travel agent) try to book last flight ticket to London.He started the transaction but before clicking book the ticket, he got a phone call and talking. He got an lock of that data.
User B (Another travel agent) tries to book same ticket and wanted to make an lock to that row and he will get

oracle.jbo.AlreadyLockedException. . So its a situation of deadlock.

The disadvantage of pessimistic locking is that a resource is locked from the time it is first accessed in a transaction until the transaction is finished, making it inaccessible to other transactions during that time.

Optimistic Locking is a strategy where you read a record, take note of a version number (other methods to do this involve dates, timestamps or checksums/hashes) and check that the version hasn’t changed before you write the record back. When you write the record back you filter the update on the version to make sure it’s atomic. (i.e. hasn’t been updated between when you check the version and write the record to the disk) and update the version in one hit.
If the record is dirty (i.e. different version to yours) you abort the transaction and the user can re-start it.

This strategy is most applicable to high-volume systems and three-tier architectures where you do not necessarily maintain a connection to the database for your session. In this situation the client cannot actually maintain database locks as the connections are taken from a pool and you may not be using the same connection from one access to the next.

example-
user A (travel agent) try to book last flight ticket to London.He started the transaction but before clicking book the ticket, he got a phone call and talking. Here it will not try to acquire lock.

User B (Another travel agent) tries to book same ticket and he click commit. Ticket booked.Changes will happen in Database. But now user A will try to book the ticket , he will get oracle.jbo.RowInconsistentException.

which one to use
Oracle recommends using optimistic locking for web applications. Pessimistic locking, which is the default, should not be used for web applications as it creates pending transnational state in the database in the form of row-level locks.