If you want to understand the concepts of XML namespaces, you need to ask few questions as follows...and get answers for them

• What are namespaces
  
• Why are namespaces used
• When are namespaces used
• What is the connection between XML, XML namespace and XSD/DTD

So let me give my answers for the above questions..

What are namespaces and what do they provide?

XML namespace is a way to group elemens of an XML file, inorder to avoid element naming conflicts...
XML namespace allows the XML parsers to process elements differently even if the elements have the same name.

Why does a parser has to process elements differently when the element names are same?

To answer this question...i have to take an example..

Assume that you have a XML file with the following content...

<organization>
           <projectlead>
                      <employeeid>123</employeeid>
           </projectlead>
</organization>

Assume that you have a parser (a java program)which can read the above XML file and lists out the Employee ID's..What the parser does is, gets all the "EmployeeID" elements in the XML file and then prints the value of the text node child element.

Now after sometime, someone comes and changes the XML file as follows..assuming that the java parser which is already present, will not list the EmployeeId of the "MYProjLead" element...

<organization>
           <projectlead>
                      <employeeid>123</employeeid>
         </projectlead>

           <myprojlead>
                     <employeeid>1233</employeeid>
           </myprojlead>
</organization>


But the parser lists out even the value of the EmployeeID  element present under "MYProjLead"...But this is not what is required...We want the parser to process only the "EmployeeID" elements present in the "ProjectLead"...
This is an example where the parser has to process the same Element  differently as they are present in different context...

This context can be specified explicitly using the XML namespace...So once we specify in which context an XML element is present, parsers can process elements differently based on the context (XML Namespace)...

So How do we specify the context ?

In XML we specify the context using a namespace as follows.

<organization>
           <projectlead xmlns="http://projectLeaderContext">
                      <employeeid>123</employeeid>
         </projectlead>

           <myprojlead xmlns="http://someCustomProjectLeaderContext">
                     <employeeid>1233</employeeid>
           </myprojlead>
</organization>

The context (actually the namespace) is specified using the "xmlns" attribute..

Many times it will be useful to understand what happens during the commit phase in ADFbc. It is very much useful to know when the validation happens, when the post changes happen etc..

The following sequence happens when a commit is successful.

1. Validation phase : During this phase all the entities which are marked as modified are validated.
2. Post changes phase: This is the phase where changes from the middle tier will be pushed to the database but will not be commited. This phase consists of two things
   
   
   
   • Lock phase: Where each row that has to be updated will be locked in the database.
   • Prepare for DML phase:  This is the place where you can modify the values of any entity attribute,if you want to before the changes are posted.
     
   • Do DML phase: Where the actual dml statement is fired.
   
   
   
3. Commit Phase: When all the above phases are executed without any problem, the commit happens in this phase.

The following are the EntityImpl methods which will be called in the above phases.

• Validation Phase: validateEntity()
• Post changes Phase : postChanges(TransactionEvent e)
• Lock Phase: lock()
• Prepare for DML: prepareForDML(int operation,TransactionEvent e)
  
• Do DML phase: doDML(int operation, TransactionEvent event)
• After Posting is done: donePostingAll(TransactionEvent transactionEvent) 
• Before Commit: beforeCommit(TransactionEvent transactionEvent)
• After Commit: afterCommit(TransactionEvent transactionEvent)

Normally, a shell script is nothing but a series of commands to be executed. Some commands open up a sub shell and will prevent the remaining commands in the script from getting executed..

To run such commands in the sub shell opened by the command use the
-exec option..

For example when you use the ADE commands like

ade useview view_name

a new subshell will be created..In this new sub shell, if you want to run any command, do the following..

Create a new shell script which contains all the commands to be executed in the sub shell ..for example

subshellcommands.sh
------------------------
ade pwv
cd $ADE_VIEW_ROOT/bin
ant -f build.xml build

Now the actual script that contains the ade useview command should be as follows..

mainscript.sh
-------------
ade useview -exec /full/path/of/the/file/subshellcommands.sh view_name

Found a good article which explains the differences between the usage of the EL expressions like
${expr} (immediate) and
#{expr} (deferred)

Here is the link

Here are some of the important points from the article (in case if you don't want to follow the link..

The primary limitation of the JSP EL (expressiongs like ${expr}) is that its expressions are evaluated immediately, meaning that the JSP container immediately parses and resolves the expression when it processes the page and returns a response.

Immediate evaluation is sufficient when a JavaServer Faces page is rendered for the first time. However, after the user enters values into the UI components and submits the page again, those values are converted, validated, and propagated to server-side data objects, and component events are processed. In order to convert data to the proper type, validate it, store it in an external object, and process events in an orderly fashion, the JavaServer Faces life cycle is split into separate phases to handle each of these tasks. Therefore, it must be possible to evaluate expressions at different phases of the life cycle rather than immediately, as is done in JSP technology.

Another problem with the immediate evaluation of expressions is that it is done in read-only mode. JavaServer Faces components need to be able to get data from server-side objects during the rendering phase and set the data in the server-side objects during postback.

Finally, JavaServer Faces components need a way to invoke methods on server-side objects during various stages of the life cycle in order to validate data and handle component events. JSP functions are not sufficient because they can only be used to call static methods defined in a TLD file; they cannot be used to dynamically invoke public methods on objects.

The following piece of code is used to set a dynamic where clause to a view object. It also shows how to set  values to the named bind parameters present in the dynamic where clause.

    public void addWhereClauseWithNamedBindParams(){
        ViewObject vo=this.getEmp1();
       
      
        vo.setWhereClause(null);
       
        vo.setWhereClause("Empno=:eNo");
        vo.defineNamedWhereClauseParam("eNo",new Integer("7369"),null);
        vo.executeQuery();
       
        vo.removeNamedWhereClauseParam("eNo");
        vo.setWhereClause(null);
    }

The following piece of code shows how to add a dynamic where clause to a view object .
It also shows how to set the bind parameters (using the positioning style not the named bind parameters)

    public void addWhereClause(){
        ViewObject vo=this.getEmp1();
       
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
       
        vo.setWhereClause("Empno=:1");
        vo.setWhereClauseParam(0,new Integer("7369"));
        // you can also use the following code to set the positional parameters.
        // vo.setWhereClauseParams(new Object[]{new Integer("7369")});
        //
        // The difference between the two apis is that one explicitly provides
        // the bind parameter position and in the second one the position is implicity
       
        vo.executeQuery();
       
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
    }

Using the "setWhereClauseParam" or "setWhereClauseParams" api's you cannot set the named bind parameters....

http://www.oracle.com/technology/products/adf/patterns/11.1.1.1.0/UnsavedDataWarning.html