Pushing the envelope

Russell has been having issues with custom tags and logic in pages. Interestingly, he remarks that it will never be possible to fully remove logic from pages. Its interesting because that was exactly what I had in mind for ViewBeans. Its still just an idea buried in my head, and some snippets of very dodgy experimental code, but it just might work...

There was some discussion last night regarding the use of JMS behind altRMI to make asynchronous calls. Taking the idea further, I wondered if it might be possible to implement asynchronous callbacks using temporary queues. So requests that take a long time, but need to return a response to the user could present a 'please wait...' message, or pop up an alert when the response has arrived, without the client having to poll the server.

Some sample code I found here looked a bit like this:

Queue tempQueue = qSession.createTemporaryQueue();
TextMessage request = qSession.createTextMessage();
request.setJMSReplyTo(tempQueue);
QueueReceiver qReceiver = qSession.createReceiver(tmpQueue);
qReceiver.setMessageListener(new MyMessageListener(. . .)); 

Could be interesting, perhaps.

Post XtC thoughts:

Frameworks / Infrastructure code / Plumbing, call it what you will. It should be easy, really easy to use. If the framework coders have to perform unnatural acts to ensure that the users of the framework don't have to, so be it. That's part of the appeal anyway (or is that just me?). Writing frameworks is something of a masochistic activity in that sense. Producing something that is so easy to use its almost a no-brainer. Hard to use frameworks won't get used. Or if they do, they'll probably be misused. Its a tough balance. You want to make the lives of developers using your framework easier, without making their decisions for them, or taking away control.

AltRMI is a good example of a framework done well - its what RMI should have been. Simple exterior, clever interior.

Paul Hammant had some wise words to say on interface / implementation separation. So important for reuse, testability, just about everything thats worth having. The collections stuff from Java 1.2 being a good example:

 Map myMap = new HashMap(); 

What if I want a map that survives restarts?

 Map myMap = new PersistentMap();

Done and dusted. No client code ever needs to know. The counter example being java.io.File. What if I want to slot in a caching file layer? or some other data source that pretends to be a file? Out of luck...

Want reusable code? Interface - implementation separation.

BTW did you know that in JSP 2.0 you can create blocks of JSP code as ciustom tags or as variables and pass them into other JSP blocks. So you could pass the header & footer blocks into a JSP page or custom tag. This might be worth bearing in mind in your 'composite view framework' from a previous post. Is that what the ViewBeans project is gonna be? [James Strachan's Radio Weblog]

Something along those lines. The general idea being that a web designer designs components, 'pagelets', small chunks of HTML, whatever, with placeholders for the data. Each ViewBean class is mapped to a different HTML component. The page is constructed by pulling the fields out of each bean in a list and merging them with the components. The completed HTML is then appended to the output stream. The therory being that the object graph in memory determines how the page is built. No logic on the page at all. Not quite sure how (or even if) it will work yet, but that's half the fun...