Month: May 2012

OJMCEA Notes

Posted on

OOP:
Inheritance: inherit properties and method from object
Abstraction: Essential character distinguish from other object
Encapsulation: Seperation (hiding) external aspect
Polymorphism: assign different behaviour to something that was declared in a parent class

2 tier architecture model:
Cons:
1. validation intensive
2. each client need to make connection directly
3. not very maintainable
4. only horizontal scalability ?

webservice features:
Static and dynamic client call
Synchronous and Asynchronous WS call

SOAP Authentication:
WS Header
SOAP Message:
1. Require Envelope
2. Optional Header
3. Require Body
4.  Optional Fauilt

JAX-WS: client doesn’t need WSDL and XML document

Strategy design pattern:
subclassing alternative
eleminate conditional statement
extend model without change code

Template method:
Skeleton of an algorithm

Proxy:
placeholder for other object to control/access it

Decorator:
pre and post processing .

Service Activator:
Invocation of business service / EJB without  waiting for the result
Integration of publish/subscribe and point to point messaging
Perform business task that locigally composed of several business task

MTOM: Sending binary from/to webservices

Signed jar: 
Doesn’t mean that the sender is authentic,

Web.xml deployment descriptor:
1. protected url
2. authentication mechanism

JSF Phase:
Request:
Restore View
Apply Request
Validation
 Response:
Update Model
Invoke
Render


Servlet destroy for:
Keep track how many thread running
Clean shutdown by having destroy method, notify long running thread & wait to complete
Long running method poll periodically, check shutdown, or if stop working, clean and return

 N-TIERS:
Client Tier
Web Tier
EJB Tier / Business Tier
EIS Integration Tier
EIS TIer

JMS:
Note: JMS doesn’t define functionality that addresses load balancing, fault tolerance, security, and administration. Such mechanisms must be provided by JMS providers.

 MDB:
MDB not accessed via interface
Instance variable of MDB can keep state accross handling of client message

BASIC OOP:
Encapsulation
Inheritance
Polymorphism

Delegation
Delegation is the simple yet powerful concept of handing a task over to another part of the program. In object-oriented programming it is used to describe the situation where one object defers a task to another object, known as the delegate

Advertisements

JSF: How to pass parameter to Managed Bean

Posted on

Use <f:param> instead. It adds a request parameter.
<h:commandLink action=”#{bean.insert}” value=”insert”>
<f:param name=”id” value=”#{item.id}” />
</h:commandLink>

If your bean is request scoped, let JSF set it by @ManagedProperty
@ManagedProperty(value=”#{param.id}”)
private Long id; // +setter

Or if your bean has a broader scope or if you want more fine grained validation/conversion, use <f:viewParam> on the target view, see also f:viewParam vs @ManagedProperty:
<f:viewParam name=”id” value=”#{bean.id}” required=”true” />

Either way, this has the advantage that the datamodel doesn’t necessarily need to be preserved for the form submit (for the case that your bean is request scoped).

Use <f:setPropertyActionListener> instead. The advantage is that this removes the need for accessing the request parameter map when the bean has a broader scope than the request scope.
<h:commandLink action=”#{bean.insert}” value=”insert”>
<f:setPropertyActionListener target=”#{bean.id}” value=”#{item.id}” />
</h:commandLink>

In combination with
private Long id; // +setter

It’ll be just available by property id in action method. This only requires that the datamodel is preserved for the form submit request. Best is to put the bean in the view scope by @ViewScoped.

If your servletcontainer supports Servlet 3.0 / EL 2.2, then just pass it as method argument. This also requires that the datamodel is preserved for the form submit request. Best is to put the bean in the view scope by @ViewScoped.
<h:commandLink action=”#{bean.insert(item.id)}” value=”insert” />

In combination with:
public void insert(Long id) {
// …
}

You can even pass the entire item object:
<h:commandLink action=”#{bean.insert(item)}” value=”insert” />

with:
public void insert(Item item) {
// …
}

On Servlet 2.5 containers, this is also possible if you supply an EL implementation which supports this, like as JBoss EL. For configuration detail, see this answer.

Bind the datatable value to DataModel<E> instead which in turn wraps the items.
<h:dataTable value=”#{bean.model}” var=”item”>

with
private transient DataModel<Item> model;

public DataModel<Item> getModel() {
if (model == null) {
model = new ListDataModel<Item>(items);
}
return model;
}

(making it transient and lazily instantiating it in the getter is mandatory when you’re using this on a view or session scoped bean since DataModel doesn’t implement Serializable)

Then you’ll be able to access the current row by DataModel#getRowData() without passing anything around (JSF determines the row based on the request parameter name of the clicked command link/button).
public void insert() {
Item item = model.getRowData();
Long id = item.getId();
// …
}

This also requires that the datamodel is preserved for the form submit request. Best is to put the bean in the view scope by @ViewScoped.

You can use Application#evaluateExpressionGet() to programmatically evaluate the current #{item}.
public void insert() {
FacesContext context = FacesContext.getCurrentInstance();
Item item = context.getApplication().evaluateExpressionGet(context, “#{item}”, Item.class);
Long id = item.getId();
// …
}

Which way to choose depends on the functional requirements and whether the one or the other offers more advantages for other purposes. I personally would go ahead with #3 or, when you’d like to support servlet 2.5 containers as well, with #2.

source
http://stackoverflow.com/questions/4994458/how-can-i-pass-a-parameter-to-a-commandlink-inside-a-datatable