Ajax + Dwr

Dwr is a framework for Ajax developers. It is easy to use.

Refer the site for more

<blockquote>http://directwebremoting.org/</blockquote>

Dwr Xml

---------

<blockquote><?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dwr PUBLIC "-//GetAhead Limited//DTD Direct Web Remoting 0.4//EN" "http://www.getahead.ltd.uk/dwr/dwr.dtd">

<dwr>

<allow>

<create creator="new" javascript="ViewDataJS">

<param name="class" value="com.hylafax.view.ViewData"/>

</create>

<convert converter="bean"

match="com.hylafax.sent.SentDetail"/>

</allow>

</dwr></blockquote>

in dwr xml, create tag creates a new js object of a java class. here "ViewData" java class has been converted to a "ViewDataJS" js script.

convert tag is used to convert object types to js. here "SentDetail" java class objects are converted.

In your jsps

---------------

<blockquote><script type='text/javascript'

src='/Project/dwr/interface/ViewData.js'></script>

<script type='text/javascript'

src='/Project/dwr/engine.js'></script></blockquote>

you have to add dwr jar file to your project. after that you can call your js methods which are in your java class.

you can access your script urls by typing :

http://localhost:8080/Test/dwr

here Test is your project



calling methods in java class

------------------------------

you can call methods like this



ViewDataJS.getReceiveList(division,gotBReceivedFax);

here "division" is the prameter for the getReceiveList method. you can get the results with gotBReceivedFax method.

Free fax server

Hylafax is a open source fax server written in java. You can configure the sources to use the fax server.

There is client written in java called as "YajHFC".

This is the sample client.


HylaFax Client
----------------

Job job = null;

String user = "test"; // -u
String host = "hyla fax server ip"; // -h
String destination = "destination number"; //
String from = empname; // -f
String killtime = "000259"; // -k
int maxdials = 12; // -T
int maxtries = 3; // -t
int priority = 127; // -P
String notifyaddr = addr; // -f
int resolution = 98; // -l, -m
Dimension pagesize; // -s
String notify = "none";
String pagechop = "default";
int chopthreshold = 3;
Vector documents = new Vector();
boolean verbose = false;
boolean from_is_set = false;

pagesize = Pagesize.A4; // default pagesize is US Letter

HylaFAXClient c = new HylaFAXClient();

try {
c.open(host);
System.out.println("Open host and returned " + c.toString());

if (c.user(user)) {
c.pass("test123");
c.admin("test123");
}

System.out.println("Check point 0:");
c.noop(); // for the heck of it

c.setPassive(true);
c.type(HylaFAXClientProtocol.TYPE_IMAGE);

c.tzone(ClientProtocol.TZONE_LOCAL);
System.out.println("Check point 1");
System.out.println("current directory is: " + c.pwd());

String filename = "/export/home/" + fileName; // where your file located

FileInputStream file = new FileInputStream(filename);
String remote_filename = c.putTemporary(file);

documents.addElement(remote_filename);

job = c.createJob(); // start a new job

// set job properties
job.setFromUser(from);

job.setKilltime(killtime);
job.setMaximumDials(maxdials);
job.setMaximumTries(maxtries);
job.setPriority(priority);
job.setDialstring(destination);
job.setVerticalResolution(resolution);
job.setPageDimension(pagesize);
job.setNotifyType(notify);
job.setChopThreshold(chopthreshold);
job.setNotifyAddress(notifyaddr);

// add documents to the job
for (int i = 0; i < documents.size(); i++) { String document = (String)documents.elementAt(i); job.addDocument(document); } c.submit(job);

java macros

An enhancement to the JDK7 compiler (the GPL'd version) that adds support for compile-time macros. Macros are Java classes that are instantiated and executed at compile-time. The macros take in a source file's parse tree and a "ParserFactory" that can be used to parse dynamically generated code.
The prototype compiler is fully functional and include a simple proof-of-concept macro. This proof-of-concept macro takes a Java class whose fields have been annotated in a special way and automatically produces getter and setter methods for those annotated fields.
Compile-time macros can be used to implement a variety of additional language features with no further modifications to the compiler. Notable examples include C++-like templates, aspect-oriented programming and closures. Or non-Java languages like Python can be embedded directly in a Java source code comment, and converted to a parse tree at the appropriate time.
This feature was trivial to add. JavaCompiler.parse() was modified to scan the import statements for macros and then execute them on the recently parsed tree. However, this naive implementation, while a good prototype, has several problems.
In the prototype presented here, macros are included in a Java source code program by simply imported the macro class. The compiler scans the parsed source file for import statements, tries to instantiate each imported class, and if the instantiated class implements the Macro interface, it is constructed using a no-argument constructor and executed.
This works but is inefficient. I propose a change to the Java Language Specification, that would re-use the "volatile" keyword for macro declarations. Similar to "import static" for procedural programming, "import volatile" would be used to execute a compile-time macro. This language change is not implemented in the prototype compiler, but it should be trivial to adapt the parser.
Macros currently use the API in com.sun.tools.javac.tree to represent the parse tree. This is suboptimal. The classes in javax.lang.model would be better, but they need to be modified to support full alterations of a parse tree.
Also, failure modes are not robust in the prototype compiler. It is unclear what should happen when a macro throws an exception. Obviously the compiler should generate a parse error for the class being altered by the macro, but the compiler does not yet have the ability to report a stack trace as part of a parse error.
Finally, javadoc was not altered for the prototype. Ideally javadoc would also execute compile-time macros, so that automatically generated members could have full documentation.
As macros exist solely at compile-time, I do not believe this language feature requires any changes to the reflection APIs.
I have rationales. Java is rapidly losing mindshare to dynamic languages like Ruby and Python. Adding compile-time macros can automate many repetitive development tasks while retaining the static safety of Java

Refer
-------

http://code.google.com/p/java-macros/