Driven By Curiosity

I got to wondering if it would be possible to add PHP to the output of the web tookit compiler. In short, the answer is yes. I’ll have to play around with it some more to see what code ends up in cached files and what code goes to nocache files, since that would be rather important.

I tried adding a PHP block to JSNI code. Oddly enough, the compiler complains about the bad syntax. Which is fine since it is bad javascript syntax, to some extent… If nothing else, it’s an inappropriate place for random HTML tags. The compiler will not complain, though, if you stick the code into an HTML comment. But comments get stripped out during obfuscation, so this doesn’t matter.

(more…)

I have seen several searches looking for information on hashmaps within the Google Web Toolkit.  As part of the ‘String-based RPC’ sample code (found here), I use hashmaps to store pending requests.  If a call to HTTPRequest.AsyncPost fails (i.e. returns false, a condition which I have never seen and from what I recall from looking through the JAR, won’t happen), the code iterates over the hashmap to call the onFailure methods of the RPC’d objects.  ServerComm.java has the loop about two-thirds of the way down.  It takes a bit of casting to make it happen.

Specifically, it is:

for (Iterator i=waitingReqs.entrySet().iterator(); i.hasNext(); ) {
((ServerData)((Map.Entry)i.next()).getValue()).onFailure(”Call failed”);
}

where waitingReqs is a HashMap.  To get an iterator, you first need to get the entrySet for the HashMap.  This is a set containing key/value pairs as Map.Entry objects.  The Iterator returns a specific Map.Entry.  I only need the value, since in this case the key is unimportant.

As a further note, there should probably be @gwt.TypeArgs definitions for the HashMap variables specifying the data types stored within the HashMap.  It works without them, but it would be better form to include them.

I’ve posted a new tutorial here documenting a string-based approach to an RPC mechanism.  This is not the ‘real’ GWT wire protocol.  Rather it is a stronger and more convenient method extended from the previous tutorials.  If you are passing form data between a PHP server and a GWT client, this may help simplify your life.

This was a little trick that I finally found.  I have a template page with a left-column navigation bar.  I wanted to add a feedback function to this nav bar.  This got me to the question of what the RootPanel is and what needs to happen to add functionality.

I figured that widgets are ultimately DOM items, so I inserted the widget element at the top of the column.  This almost worked: my widget showed up where I wanted it, but it didn’t do anything.  It turns out that you need to add it to the RootPanel first, then move it’s element to the desired location in the DOM.

In the onModuleLoad function, I have:

public void onModuleLoad() {
final String idStr = “LeftCol”;
Element leftCol = DOM.getElementById(idStr);

final Label link = new Label(”Not finding what you want?”);
RootPanel.get().add(link);
DOM.insertChild(leftCol, link.getElement(), 0);
link.addClickListener( new ClickListener() {
public void onClick(Widget w) {
PopupPanel pu = new MyPopup();
pu.setPopupPosition(link.getAbsoluteLeft(), link.getAbsoluteTop());
pu.show();
}
});
}

This also provides a popup window which relocates itself to the top left corner of the Label.  The popup code was taken directly from the example code in the Google documentation of PopupPanel.

I don’t know exactly what happens when widgets are added to the RootPanel, but this technique does allow for proper positioning and functionality of the widget when it is added to an existing part of the DOM structure.