I'm new to JavaScript environment and it's the one running on the system i'm newly at. We're using GWT for JavaScript.
What is the best way to detect the connections between the back-end processes and front-end actions? Eg. which back-end method is invoked when "that" button is pressed, tab is clicked, window is opened, ... .
The only way I can think of is using the debugger and Eclipse search/call hierarchies facilities: keep putting breakpoints in places where I anticipate will run-- until i hit the spot.
Is/n't there a more efficient way of doing this?
How do other developers do?
I'm a back-end developer. In a previous system, I put a port monitor-- Fiddler, saw the contents of the request the FE is sending and went from there.
I'm aware that this is a naive Q-- please bear with me.
TIA.
//======================
EDIT:
the best would be a debugger-like tool showing the stack-trace, or even the execution path in any way, telling the back-end methods that are running and/or spawning the threads. is there such a tool?
5 Answers
Answers 1
The following takes for granted that you are using a decent IDE and that you have imported the GWT project into such IDE. There's some help at the end if this is not your case.
If you know which Java class contains the front-end logic, and the element you're interested in
Find the object representing the element (a Button, a ListBox, whatever) and look at the event handlers attached to it.
Something like this:
//... @UiField ListBox myDropDownList; //... myDropDownList.addChangeHandler(new ChangeHandler() { @Override public void onChange(ChangeEvent changeEvent) { SomeService.someRPCmethod(... params, callback, ...); } }); The SomeService.someRPCmethod method implementation should contain all the backend calls.
If you know the Java class, but not which one of all the buttons is the one you're looking for
Most GWT apps make use of *.ui.xml files which are like a skeleton for the actual web page. This XML files reference the actual Java objects used in the Java class, and are usually named like the class they represent.
Locate the ui.xml file and look for something like this:
... <g:ListBox ui:field="myDropDownList" styleName="cssClassName"/> ... This should appear in your webpage like this:
<select class="cssClassName" ...> <option ...> The position inside the XML file, and the CSS class name, should help you pinpoint the element you're looking for. Once you find it, the ui:field attribute points to the Java object (try ctrl+clicking it in your IDE).
Now you just have to look at the handlers as explained before.
If you don't know the Java class which contains the front-end logic
To find the Java class for a given webpage, you can resort to the good ol' string search.
Locate a not-so-common string literal used in the web page. Not something like "Add" but more like "User registration".
Use your IDE to search the project's code base for that string. It should appear inside a .properties file, or a class with constants and literals, or maybe even hardcoded inside the front-end Java class.
Now just use your IDE to follow the references. It might be something like .properties file -> Constants interface -> .ui.xml file -> front-end Java class, or literals Java class -> front-end Java class.
If you don't have access to the front-end source code
You can try to use your Developer Tools / Fiddler to look for REST calls, which is how GWT implements RPC.
So the call to SomeService.someRPCmethod above might appear in Fiddler as a http:://yourwebpage/somepath/SomeService call with a bunch of GET/POST parameters, one of which should be someRPCmethod (the method's name). But this is not always the case.
Last (or maybe first!) resource
Ask the front-end developers, they put the calls in there and can get you on track in minutes ;)
Answers 2
I had similar issue, so I installed an extension in my chrome.Below is the name of the extension. You can try once.
Visual Event 2.1
Know what event is bound on each dom element There is one more approach, You can debug your code from front end. You can inspect element in your browser and then open Source tab.
Press ctrl + P to search the file in which you want to put the debug points.
Put debug points by clicking on the row number.
This way you need not to go to eclipse that often.
Answers 3
I would start by searching the code for the listeners of whatever events you are interested in and go from there. I work in EXT JS and I do this all the time.
Following all code paths through is the only guarantee unless all calls to the backend go through some known class.
Monitoring the network is also a good way to go.
This can be done in Chrome through the "Developer Tools" on the Network tab.
Answers 4
In GWT you have on the client side "import java.util.logging.Logger;" which output your debug info to the browsers console. On the server side you just use "System.out.println("debug");" for debugging which goes to the Apaches Tomcat log files. Which makes debugging on a live server a bit easier.
GWT uses RPC's for communication between the client and server. The data sent is serialized and can be a whole class if needed. The three folder for source in a module as 'client', 'server' and 'shared'.
For example a shared class used for sending data back and forth: (The blank constructor is required to serialise the class)
public class MySharedData implements Serializable { private static final long serialVersionUID = 1987236748763652L; // used for serializing data public List<String> lotsOfStrings = new ArrayList<String>(); // use most java vars public int width, height; public MySharedData() {} // 'need' a blank constructor public MySharedData(MySharedData data) { //do stuff } // also can } On the server side it may look something like this:
public class MyServerRPCImpl extends RemoteServiceServlet implements MyServerRPC { private static final long serialVersionUID = 4435555929902374350L; public List<String> getStringList(int var, List<String> strs) { // do stuff System.out.println("debugging output"); // to tomcat log file return stringList; } } The client will use an Asynchronous callback with two methods, onSuccess() and onFailure() so you can handle call failures. To use this is something along the lines of:
public class MyGWTApp implements EntryPoint { // the server RPC class final MyServerRPCAsync server = GWT.create(MyServerRPC.class); // create RPC instance final Logger log = Logger.getLogger("tag"); public void doSomething() { MySharedData data = new MySharedData(); server.getStringList(data, new AsyncCallback<List<String>>() { @Override public void onFailure(Throwable caught) { log.info("error"); // logging goes to the javascript console output } @Override public void onSuccess(List<String> result) { log.info("call worked"); } };) } } The above is my way of managing logging as my projects have to run straight from a Tomcat server. I also believe the server logging when run from Eclipse will go to Eclipse's console log, but I'm unsure on that. All server output and errors, including stack traces will be in the /var/log/tomcat/ folder on linux, or the equivalent on Windows. I can honestly say, I've yet not used breakpoints debugging with GWT.
Client and server code is in separate classes in their own folders within the project.
Answers 5
Just want to mention that sometimes debugger is used in situations where other tools can also help (not sure if this is the situation here - but bear with me just another two sentences):
(1) you can grep the relevant html asset , grep is a wonderful tool to learn large systems
(2) you can add log , in some cases you can switch to debug mode and see tons of log traces
0 comments:
Post a Comment