Java Related Knowledge: December 2012

Monday, December 10, 2012

noscript and comments JQuery

The <noscript> tag is used to provide an alternate content for users that have disabled scripts in their browser or have a browser that doesnâ��t support client-side scripting.

The <noscript> element can contain all the elements that you can find inside the <body> element of a normal HTML page.

The content inside the <noscript> element will only be displayed if scripts are not supported, or are disabled in the userâ��s browser.

Tips and Notes

Tip: It is also a good practice to use the comment tag to "hide" scripts from browsers without support for client-side scripts (so they don't show them as plain text):

<script>
<!--
function displayMsg()
{
alert("Hello World!")
}
//-->
</script>

CSS JQuery buttons

<style>

button {
  margin-top: 60px; }
button.punch {
  background: #4162a8;
  border-top: 1px solid #38538c;
  border-right: 1px solid #1f2d4d;
  border-bottom: 1px solid #151e33;
  border-left: 1px solid #1f2d4d;
  border-radius: 4px;
  -webkit-box-shadow: inset 0 1px 10px 1px #5c8bee, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
  box-shadow: inset 0 1px 10px 1px #5c8bee, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
  color: #fff;
  font: bold 20px/1 "helvetica neue", helvetica, arial, sans-serif;
  margin-bottom: 10px;
  padding: 10px 0 12px 0;
  text-align: center;
  text-shadow: 0px -1px 1px #1e2d4d;
  width: 150px;
  -webkit-background-clip: padding-box; }
  button.punch:hover {
    -webkit-box-shadow: inset 0 0px 20px 1px #87adff, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
    box-shadow: inset 0 0px 20px 1px #87adff, 0px 1px 0 #1d2c4d, 0 6px 0px #1f3053, 0 8px 4px 1px #111111;
    cursor: pointer; }
  button.punch:active {
    -webkit-box-shadow: inset 0 1px 10px 1px #5c8bee, 0 1px 0 #1d2c4d, 0 2px 0 #1f3053, 0 4px 3px 0 #111111;
    box-shadow: inset 0 1px 10px 1px #5c8bee, 0 1px 0 #1d2c4d, 0 2px 0 #1f3053, 0 4px 3px 0 #111111;
    margin-top: 58px; }
 
 </style>
    <br>
    
    <button class="punch">Send</button>
<button class="punch">Preview</button>
    <button class="punch">Cancel</button>

Saturday, December 08, 2012

Tiles Advantages over JSP:include

Large websites often need a common Look and Feel (L&F). If the L&F is hard coded in all pages, changing it becomes a nightmare: you would have to modify nearly all pages. When you are using JSP include, you create the layout of the website within the page and then place the actual view component (JSP). Hence you need to repeat the same layout logic to every page causing repetition in the web page. This also discourages you to change the view of the website at a later time as you may have a lot of pages to modify.

“Tiles” is the solution for this problem. Tile is an area or region on web page. Tiles is the technology which is used to create view of a website. Using Tiles you can define the layout as a template, can create complicated layouts and use them through out the application for consistent layout. The purpose of layout is to assemble a group of tiles to specify the format of page. As it is a layout, you insert placeholders (using Tiles insert tag) instead of actual view components (JSPs). The values for the placeholders are defined by an XML. If you want to change the view of the application you can do so by changing the layout only and can save a lot of time.
With Tiles you can do things such as:
o Screen definitions that include inheritance
o Templating: you can create templates and can use them again and again o Layouts for common pages, menus, and portals
o Dynamic page building
o Reuse tiles

o I18N support for locale-specific loading

9. Tiles vs. JSP Include
9.1. Advantage of Tiles over JSP include

Code Repetition is reduced
Use of Tiles reduce the code repetition to a great extent. Code repetition is bad but repetition of layout logic could be worst. Tiles also handle this issue. As you have layout templates based on which all the pages are combined, you don't need to repeat the code for layout. Other view components are also reusable and can be used in the same application at other places reducing the code repetition.
Low coupling between pages
Coupling is the degree of interactivity between two entities. It is always suggested to minimize coupling between unrelated classes, packages, and so on. Same principle is applied to view components. Tiles reduce the coupling between unrelated view components.
High layout control
Tiles provide great layout control by providing layout templates.
I18N support for locale-specific loading
Dynamic Page building
Pages are built dynamically in tiles. You can control the page view by configuring it through xml.
Elimination of duplicate and redundant information
Tiles eliminate the duplicate and redundant information in the configuration file by providing Tiles inheritance.
Central location for view components
Tiles save definition of all the components at one place (in tilesDef.xml) and hence can be modified easily when required.

9.2. Disadvantages of Tiles

Increases the number of pages
Increases complexity
Tiles increase complexity by introducing another layout page. Understanding and implementing templating can also be difficult at initial stages.
Big API
Tiles have a bigger API set which may be difficult to understand for getting full benefit of tiles.
You have to specify a name to any component you create.

I am a big believer in the Tiles framework. It's main advantage, in my
viewpoint, is its ability to increase reuse across the presentation
tier of an application

.

With Tiles a developer can set up a few Tile definitions (templates)
that represent the different page layouts across a web app

. Each Tile
definition can have both concrete JSPs as well as empty Tiles. Then,
through Tile inheritence, each template can be extended n times to
create any number of pages. Say that a web app

has a common header and
footer across 10 pages. Tiles allows the developer

to create one JSP
for the header, one JSP for the footer, one Tile definition, and 10
JSPs for the body of each page. If the header JSP changes the change
ripples through all pages without any need to change the Tiles XML.

Sure, you could use jsp:include and get a similar result but you would
lose the flexibility of the XML configuration and the inheritence that
Tiles provides you. In the near term it will save development time
with each new page that you create that fits into one of the templates
you have defined. In the long run it will make the application much
easier to maintain.

To add to that point, Tiles helps you code views in a way that allows
you to minimize the number of objects placed in the session scope.
Many times you see a developer using a traditional MVC where a servlet
can only dispatch to only 1 jsp.

The jsp is normally called main.jsp but it calls numerouse includes.
Main.jsp accepts the request attributes, but included jsp, that may
also include other jsp for presentation purpose may not, but should
have access to the object added to the request. So many developers

would capture it in main.jsp and then add it to the session. This is
not scalable. So with tiles you dont have to do that the inheritence
allows you to access the request scope attributes at any level.

Monday, December 03, 2012

Jenkins

java -jar jenkins.war --ajp13Port=8010 --httpPort=8084

Jenkins as a service

Git Commands

git --bare init

git clone --bare -l non_bare_repo new_bare_repo

git remote add origin S:\Wasif\Depot\lanyon_documents.git

git branch -a

git remote update

git show-branch -a

git ls-remote origin

git rev-parse HEAD

git remote show origin

git difftool -y

git mergetool -y

git reset --hard ORIG_HEAD.

Sunday, December 02, 2012

10.6: Re-enable Java 1.4.2 and Java 1.5 apps in Snow Leopard

Many applications that relied on Java 1.4.2 and Java 1.5 stopped working in Snow Leopard, because Apple removed these Java versions from the system. Upgrading to the lastest versions of many applications usually will solve the problem. However, your favorite application may not have a Snow Leopard compatible upgrade. For these applications, re-installing Java 1.4.2 and/or Java 1.5 is necessary. Sometimes, even this is not enough. As an example, Apple also removed the Cocoa-Java bridge from Snow Leopard, which some Java applications such as PDFLab depended on. Reinstalling the Cocoa-Java bridge along with the proper version of Java is necessary to re-enable these applications on Snow Leopard. For example, getting PDFLab working again in Snow Leopard requires reinstalling Java 1.4.2 and the Cocoa-Java bridge. Read on for a how-to...

Installing Java 1.4.2 and/or Java 1.5 on snow Leopard:

The following is based on two blog posts: Using Java 1.5 and Java 1.4 on Snow Leopard and Installing Java 1.5 on Snow Leopard:

Download the official Java package from Apple: Java for Mac OS X 10.5 Update 4, dated June 15, 2009.
Use the excellent shareware utility Pacifist to open the downloaded JavaForMacOSX10.5Update4.pkg file.
First use Finder to go to System » Library » Frameworks » JavaVM.framework » Versions and delete the two aliases (symlinks) 1.5 and 1.5.0. Don’t skip this step, because otherwise the extraction will follow the symlinks and overwrite the contents of the 1.6.0 folder, oops!
In Pacifist, drill down into Contents » System » Library » Frameworks » JavaVM.framework » Versions.
In Pacifist, select 1.5 and 1.5.0, Control-click on the selection, and chose Install to Default Location from the pop-up menu.
In the instructions above, the same applies for version 1.4.2.

Installing the Cocoa-Java Bridge:

This is based on Getting back the Cocoa-Java bridge in Snow Leopard:

Copy from a working Leopard (10.5) installation the following folders:

the com directory in /System/Library/Java
the eight files ending with .dylib in /usr/lib/java (four of these are regular files, the other four are symlinks; if you prefer, you can copy just the files and recreate the symlinks by hand).