1. Conversion
a) Array => String
String modeStr = StringUtils.join(modes, '/')
String[] modes = StringUtils.split(protocolStr, '/')
int RADIO_PROTOCOL_A = 0x1; if (radioMode & RADIO_PROTOCOL_A) == RADIO_PROTOCOL_A
radioMode = radioMode | RADIO_PROTOCOL_A radioMode = radioMode & ~RADIO_PROTOCOL_A
A few important differences between GWT and Swing. First, the components that ship with GWT don’t follow the Model View Controller (MVC) pattern: No model object can be shared by multiple components to keep them in sync. Second, GWT doesn’t use layout managers to control the layout.
- Goal: to reunite the programmable web (RSS, XML-RPC, SOAP) with the human web.
- HTTP is a document-based protocol
• The scoping information (“why should the server send this data instead of that data?”) is kept in the URI. This is the principle of addressability.
• The method information (“why should the server send this data instead of deleting it?”) is kept in the HTTP method. There are only a few HTTP methods, and everyone knows ahead of time what they do. This is the principle of the uniform interface
• Statelessness means that every HTTP request happens in complete isolation.
• Connectedness
The difference between PUT and POST is this: the client uses PUT when it’s in charge of deciding which URI the new resource should have. The client uses POST when the server is in charge of deciding which URI the new resource should have.
- It follows one dispatcher, multiple worker threads model. The HandlerAdapter (worker thread) need to disable the channel's interest ops before the processing, to avoid selector fire more events and spawn other worker thread; it resumes channel's interest ops after the processing. However, selector is not thread-safe. So the approach is to only allow dispatcher thread updates channel's interest ops. Worker threads only queue the status change requests to dispatcher thread.
- HandlerAdapter present a Facade through which the InputHandler may interact with the framework. It encapsulates event state, channels, input and output queues. Client code registers an InputHandler for a channel, dispatcher wraps handler in an internal adapter class. The client InputHandler is decoupled from NIO and dispatcher implementation details. **Good practice **
- Client handler is passed a ChannelFacade interface through which it may interact with the channel and/or queues. **Elegant encapsulation, hide channel **
- When client code want to write data, i.e., send request, it acquires the handler, and then output byte data to the outputQueue of the channelFacade, modifies the interest ops to OP_WRITE, then next time selector will fire writable event and drain out the output queue to channel.
See: NIO Server Framework
