![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
The main goals of the WebWork Framework depicted on the Wikipedia's article:
- Web Designer never has to touch Java code;
- Create multiple "Web Skins" for a application;
- Change Look and Feel;
- Change Layout on a given Web Page;
- Change Flow among Web Pages;
- Move *existing* data elements from one page to another;
- Integrate with various backend infrastructures;
- Reuse components;
- Perform internationalization (i18n) of a web application;
- Keep the API small and to the point;
- Ability to learn WebWork fast, by making all the fancier features optional;
- Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];
I'm not sure if the order on the list above reflects the priority but if so I would strongly use the items from 8 until 12 as the first top one priorities:
- Reuse components;
- Keep the API small and to the point;
- Ability to learn <YOUR FRAMEWORK/API NAME HERE> fast, by making all the fancier features optional;
- Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases [1];
- Perform internationalization (i18n) of a web application;
An the last item is for certain one of the main strengths of the Springframework, as well as the terrific usage of Object Oriented advantages as Polymorphism.
I stumble upon this WebWork article because a tool I'm using for the past months makes some use of it :)
By coincidence today I just had to implement my last post flatten operation of Array Ruby class. What is is funny about it is that when I read Fowler using it as an example of a typical operation of a human interface operation I thought to myself: "Who on earth would need such an operation?" If you don´t know what it does here is a example (Ruby code):
[1, [2, 3], 4, [5, [6, 7], 8], 9].flatten = [1, 2, 3, 4, 5, 6, 7, 8, 9]
And in the end I´ve ended up implementing it myself only a couple of days later of thinking that :)
I am doing some combinations of elements in my current project and my algorithm resulted this kind of collections, that may have elements that are other inner collections. All I needed was this kind of flatten operation, of course I could review my algorithm but this solution required much less effort. I guess the use of this operation is more common than I thought.
Here is the code:
public static Collection flatten(Collection elements)
{
Collection flattened = new LinkedList();
for (Object o : elements) {
if (o instanceof Collection)
flattened.addAll(flatten((Collection) o));
else
flattened.add(o);
}
return flattened;
}
A human interface operation is one that has a very specific usage but even though it is added to your interface against the philosophy of adding only operations of a general need.
By the way, Cedric has recently posted his opinions on human interfaces too.
[1, [2, 3], 4, [5, [6, 7], 8], 9].flatten = [1, 2, 3, 4, 5, 6, 7, 8, 9]
And in the end I´ve ended up implementing it myself only a couple of days later of thinking that :)
I am doing some combinations of elements in my current project and my algorithm resulted this kind of collections, that may have elements that are other inner collections. All I needed was this kind of flatten operation, of course I could review my algorithm but this solution required much less effort. I guess the use of this operation is more common than I thought.
Here is the code:
public static Collection flatten(Collection elements)
{
Collection flattened = new LinkedList();
for (Object o : elements) {
if (o instanceof Collection)
flattened.addAll(flatten((Collection) o));
else
flattened.add(o);
}
return flattened;
}
A human interface operation is one that has a very specific usage but even though it is added to your interface against the philosophy of adding only operations of a general need.
By the way, Cedric has recently posted his opinions on human interfaces too.
Fowler has an interesting wiki entry on design of API interfaces. Although I think he missed a point on talking about java.util.List interface lack of more friendly operations (like last(), first()...) and not considering the java.util.LinkedList class interface which has much of those operations. Even though nothing so friendly (or human if you rather saying) like Ruby´s Array interface operation flatten mentioned in the article, and many others I suppose.
Anyway, as a programmer I feel writing more readable code with API with lots of useful operations.
Anyway, as a programmer I feel writing more readable code with API with lots of useful operations.
Docco might be a very useful tool if you have hundreds of PDF documents on software development. It uses data mining techniques to find relationships between documents from a set o user entered key words (with a nice graphical view). It uses Lucene under the covers too. It´s very easy to install, just unzip e run the bat/sh.
