der kl@mmeraffe | ruby. java. development.

Simple Atom Feed With Ruby

2006-09-01T02:48:00.000-07:00

Its really simple, took me bout an hour :-) But it suits my needs, and i don't have to implement other libs then build in (not even xml, allright, i'm crazy). Its not fast, reliable or something, but i wanted to create an atom feed that shows the files from a directory.
Heres the code:


class Atomfeed
    attr_accessor :title, :subtitle, :link, :updated, :authorname, :authoremail, :id, :entries

    def initialize
        @title = ""
        @subtitle = ""
        @link = "http://"
        @updated = ""
        @authorname = ""
        @authoremail = ""
        @id = ""
        @entries = []
    end

    def create_feed
        @xml = ""
        @xml = @xml + "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<feed xmlns=\"http://www.w3.org/2005/Atom\">\n"
        @xml = @xml + "<title>" + @title + "</title>\n"
        @xml = @xml + "<subtitle>"+@subtitle+"</subtitle>\n"
        @xml = @xml + "<link href=\""+@link+"\"/>\n"
        @xml = @xml + "<updated>"+@updated+"</updated>\n"
        @xml = @xml + "<author>\n  <name>"+@authorname+"</name>\n   <email>"+@authoremail+"</email>\n </author>\n"
        @xml = @xml + "<id>"+@id+"</id>\n"
        @entries.each do |entry|
            @xml = @xml + "    <entry>\n"
            @xml = @xml + "        <title>"+entry.title+"</title>\n"
            @xml = @xml + "        <link href=\""+entry.link+"\"/>\n"
            @xml = @xml + "        <id>"+entry.id+"</id>\n"
            @xml = @xml + "        <updated>"+entry.updated+"</updated>\n"
            @xml = @xml + "        <summary>"+entry.summary+"</summary>\n"
            @xml = @xml + "    </entry>\n"
        end
        @xml = @xml + "</feed>"
    end
end

class Entry
    attr_accessor :title, :link, :id, :updated, :summary

    def initialize
        @title = ""
        @link = "http://"
        @id = ""
        @updated = ""
        @summary = ""
    end    
end

Thats it (Lots of stuff to refactor here, but - hey, it works). To use it, i just start a webrick httpserver and map an action to the create_feed method. Before that, i fill the Atomfeed / Entry objects:


require 'webrick'
include WEBrick

s = HTTPServer.new( :Port => 2000 )

class AtomServlet < HTTPServlet::AbstractServlet
  def do_GET(req, res)
    @directory = "c:\\dev"
    Dir.chdir(@directory)
    @files = Dir["*"]
    feed = Atomfeed.new
    feed.title = "New files"
    feed.subtitle = "Yeah, new Files"
    feed.updated = Time.now.to_s
    feed.authorname = "dan"
    feed.authoremail = "blub@nothing_here.com"
    feed.id = "123456789"
  
    @files.each do |file|
      entry = Entry.new
      entry.title = file.to_s
      entry.link = "http://"+file.to_s
      entry.id = file.to_s
      entry.updated = "134"
      entry.summary = "huuhu"
      feed.entries.push(entry)
    end

    res.body = feed.create_feed
    res['Content-Type'] = "text/html"
  end
end

s.mount("/atom.xml", AtomServlet)
trap("INT"){ s.shutdown }
s.start

Most Information here doesn't make sense, but it shows all files in the working directory :-) ruby is so much fun!

Working with wsdl2r, soap4r and complex types

2006-08-15T11:47:00.000-07:00

Ruby has great support for SOAP built in. Trivial calls at least. Look at this example:


require 'soap/rpc/driver'
stub = SOAP::RPC::Driver.new("http://localhost:8080", 
  "http://somenamespace.com")
stub.add_method('gimmeAString', 'a_string')
p stub.gimmeAString("huhu!")

Easy, isn't it? You just create a new Driver object by handing over the location of the web service and its namespace. After that you can add the method you want to call and invoke it. Thats it. At least at the "Example-Stage". I real life, you need to declare complex types and use basic authentication and stuff. How to do that?
With soap4r, the standard soap framework for ruby, comes a nice script called "wsdl2ruby.rb". Example:

./wsdl2ruby.rb --wsdl coolWSDLFile.wsdl --type client

That generates the complex types and the whole driver class you need to access your web service. Well, in theory, as brendon wilson describes in his article (thats written a lot better than this one here :-)). Because wsdl2ruby (and the whole wsdl4r part of the soap4r framework) is still in alpha stage, you can't expect too much. In my case, it couldn't handle all the complex types, so i had to fix it manually. Its not too difficult. Once you've got a generated driver you can add all necessary complex types that are missing and use the driver like in the first example at the top of this article.

A complex type definition looks like this (taken from the soap4r documentation):


require 'soap/mapping'

SampleStructServiceNamespace = 'http://tempuri.org/sampleStructService'

class SampleStruct; include SOAP::Marshallable
  attr_accessor :sampleArray
  attr_accessor :date

  def initialize
    @sampleArray = SampleArray[ "cyclic", self ]
    @date = DateTime.now
  end

  def wrap( rhs )
    @sampleArray = SampleArray[ "wrap", rhs.dup ]
    @date = DateTime.now
    self
  end
end

class SampleArray < Array; include SOAP::Marshallable
end

To use this struct, just use it as a type in the method-definition:

stub.add_method('anotherMethod', 'sampleStruct')

btw, soap4r comes bundled with lots of extremely helpfull examples for all kind of usages.

As of basic authentication, you need to install http-access2.

With an additional line of code,

stub.options["protocol.http.basic_auth"] 
  << ["ws_url", "username", "password"]

basic authentication is done. More Information on that at Chris McMahons Blog

The SOAP implementation in Ruby itself is great. It seems to be reliable and it is rubyish to code (i.e "easy"). The wsdl2ruby generator needs some more work (i tried a second wsdl file, but that too didn't work), but it helped me a lot to write a SOAP-driver for my specific web service.

Another nice tutorial is here.

Java Stack Traces

2006-08-09T06:25:00.000-07:00

Funny. Sad. True.

Article bout Stack Traces @ ptrthomas.wordpress.com

Rails: All those little things

2006-08-08T12:36:00.000-07:00

Image you've got a List (or an Array or whatever you like to call it) with objects. Those are articles with lots of fields. And you want to sort this List by one of its fields.
One thing some love (or hate) bout ruby is its use of blocks. Some say they are the most powerful thing imaginable, some say doing 2.times {p blub} isn't that cool (maybe they are both wrong and right).
Whatever. To sort a List is not a nice task in lots of programming languages. But look at this:


articles.sort! do |a, b|
 a.value <=> b.value
end

Got it? You tell the List to sort itself (by calling the sort-method and putting a block in it). The block uses a funny operator that return -1, 0 or 1, depending on which element is bigger. The method uses this information to sort the List.

Those are the little things why i really like to code in ruby (with or without rails)

Going on with Rails

2006-08-06T14:26:00.000-07:00

Yesterday i started coding a small web app involving rss, mysql and stuff. Of course i chose Rails to check out how rapid and clean its possible to implement what i wanted to. I haven't that much with Rails till now, just a little testing. But the last to days (well, just for a couple of hours) it was possible for me to implement the database model + O/R mapping, the views, the rss-feed-aggregation-logic and user-management. Without even knowing the pitfalls or tricks in Rails i've done all of this in less than 4 hours or something (with my brain thinking how to do the design. coding was a joke!).
In Rails its fast to implement a web app because:

1. The ActiveRecord-Stuff.
Tell your app which database you use, generate models for the tables. Thats it for O/R mapping. When u change a field in the db, ActiveRecord dynamically changes its behaviour. And its extremely intuitive. Imagine a table "Customer". What if you want to find all of your customers? Right, just do

Customer.find_all

(or, nowadays:

Customer.find(:all)

). You want to change the customer-id? Type

customer.id = 1

Want to save the changes? Type

customer.save

There is nothing you have to code for the db-model in Rails.

2. Use of Ruby
I wanted to read rss-feeds. Of course, you can do this in every language imaginable. But with Ruby, its a sure bet that its extremely easy. I used "FeedTools":

@feedxml = FeedTools::Feed.open(feed.address)

now you can use the feed as a plain old ruby object.

3. no config
For some it may be a drawback to follow the conventions of Rails. Using plural-forms for tables isn't something everybody likes (including me), but when you create a "Customers"-Table you just have to generate your model "Customer" to dynamically access it. Same with actions in the controller. Create a method "login" and a rhtml "login". Now you can jump to localhost:3000/login and everything is done for you. Maybe for bigger apps thats not perfect but its great for prototyping.

4. No code bloat or bloated framework
The written code is always in Ruby, so its never to long, easy to read and to maintain. Rails has lots of stuff you will find handy but doesn't come with every latest technology every java developer have to fight with ;-)

I'll code along over the next couple of weeks, if the final app is something interesting i'll post it here :-)

Developing an IOC-Container for Dependency Injection Part II

2006-07-31T13:21:00.000-07:00

Part I | Part II | Part III

Welcome to the second part. Today we want to define how our configuration file shall look and start with the implementation of our container.
Look at the config-file of my personal dreams:


<services>
 <service name="Customer" class="ioc.example.Customer">
  <property name="id" value="1">
  <property name="names" type="list" value="[12,15,16]">
  <property name="numbers" type="array" value="[a,b,c]">
  <property name="smallmap" type="map" value="[1:a,2:b,3:c]">
  <property reference="User">
  <property reference="Admin">
 </property>

 <service name="User" class="ioc.example.UserImpl">

 <service name="Admin" class="ioc.example.Admin">
  <property name="adminName" value="Sam">
 </property>
</service>

We call every injected class a service. For every service we provide a implementation class. A service can have properties. We don't want to be too extreme in the beginning, so we just want Strings, lists, arrays , maps and references to other classes (via ).
The Details for the configfile above:
Here we define a Bean for the concrete class ioc.example.Customer and mark it with the id Customer. We define some Properties for that Bean:
id is a property that we initialize with the value 1. The container should automatically set the correct type for every primitive. The second property, names, is a list that we initialize with the values 12, 15, 16. It should also be possible to use arrays (for the beginning they'll be automatically String[]) and maps, as you can see at the properties numbers and smallmap. Now to the interesting stuff: The properties User and Admin are referenced beans, defined below in the same file. the Container must take care of all the Dependency Injection Stuff.
As you can see, it shouldn't matter wether you are using a simple concrete class for injection or an implementation of an interface (UserImpl).

So how can we implement the container? First we define the Interface:


package ioc.container;

public interface IOCContainer {
  public Object getInstance(String id);
  public Object getInstanceByClass(String clazz);
  public Object getInstanceByClass(Class clazz);
}

What are we doing here? We need methods to retrieve the auto-wired objects. And we want to have the ability to get them via the name (the id) or the class/class name.

Here comes the Implementation of the Standard IOC Container:


01 /**
02 * Standard Implementation for the IOCContainer
03 */
04 public class IOCContainerStandardImpl implements IOCContainer {
05    
06   Map services;
07   IOCConfig conf;
08    
09   public IOCContainerStandardImpl(String config) {
10        
11     //Read Configuration-XML
12     conf = new IOCConfigParser().parse(config);
13        
14     //Create all Services
15     services = new IOCServiceFactory().createServices(conf);
16   }
17    
18  /**
19   * Create an Instance with the 
20   * id of this class
21   */
22   public Object getInstance(String id) {
23    return services.get(id);
24   }
25    
26  /**
27   * Create an Instance with the class
28   */
29   public Object getInstanceByClass(Class clazz) {
30     return services.get(clazz.getName());
31   }
32    
33  /**
34   * Create an Instance with the fully
35   * qualified name of the class
36   * 
37   * @param clazz
38   * @return
39   */
40   public Object getInstanceByClass(String clazz) {
41     return services.get(clazz);
42   }
43 }

Lets dive into the details:
First, in line 12, we read an configuration xml (like the one above) and parse throught it with an IOCConfigParser class. Here we receive an presentation of our services. Maybe thats not necessary, but that way we can put the configuration in a state and fill it with information that makes it easier to create the "real" services afterwards.
At line 15 we use an IOCServiceFactory class to create all services. That means instantiation of the correct classes, filling them with startup values with correct types defined in the config-file and wiring them together. And this means lots of reflection of course ;-) The services (or the beans, pojos, objects, whatever) are stored as a map in an instance variable. The other methods just give the corresponding service to the caller.

But that should be enough for today. In part 3 we dive deeper and look whats behind the IOCContainer, the Factory and so on. Stay tuned.

Ruby on Rails First Steps

2006-07-29T08:04:00.000-07:00

add this article to del.icio.us

Ruby on Rails is a lightweight MVC Web-Framework, written completely in the ruby programming language. It depends heavily on its code generation philosophy, you can generate the whole directory tree for your project, including templates for your models, views and controllers. Rails doesn't rely to much on configuration files, its more "convention over configuration. So you can obey some rules (don't have to, but the u need config files) and rails is doing some amazing stuff automatically. Therefore, there are no ridiculous mapping files (customer.id maps to customer.id, doh!), rails maps automatically between the relative to the objectoriented world at the persistence layer.

But lets dive into a small example. Here, we want to build a small, maybe usefull application: a todo list system, where you can create todo-lists and add tasks to them. It should also be possible to change, delete or view your todos.

Technical details first: To use Rauls, we nee Ruby. Depending on your local operation system choose the corresponding download at the Ruby-Homepage. In most Linux-Dists you don't need that step because ruby is already installed.
To develop a database driven application, we need a database management system. Typically we choose MySql, its free and everybody knows it. Get ithere. When you are there, be sure to also download the MySQL Administrator, an easy to use front end for the mysql server.

After the installation we open a shell an use gem, the official Ruby package manager, to download and install Rails.

gem install rails --include-dependencies

Alright, now we can start. Lets create our project "todo".

rails todo

Rails now creates the whole directory tree. Later, all the generated and changed models, views and controllers are in the subdirectory "app".

Next we create a new database (schema) via the MySQL Administrator with the name "todo" including two tables:

lists (id, name, description)
todos (id, name, txt, list_id)

Ok, now we edit the file database.yml in the directory todo/config and set the right database properties. Thats pretty easy and all you have to do for this simple example.

The first steps are done, start the webserver:

ruby script/server

Now at http://localhost:3000 Rails shows that its runnning. Lets see what we can do with it.
Because we named our list-table "lists", Rauls knows, that a component "List" will map to it. Rails is pretty clever in that point, it understands plural forms of lots of english nouns (including things like "entries" and "entry"). Here we can see the motto "convention over configuration". We have some conventions to obey, but we don't need things like deployment descriptors an mapping files.

Lets generate model and controller for the component "List":

ruby script\generate model List

ruby script\generate controller List

Rails generates the stubs, helper-classes and unit-tests.

Now we edit the script list_controller.rb at the directory app/controller (clean naming, isn't it?) and write into the class:

scaffold :list

A click at http://localhost:3000/list/new shows us what real prototyping is: The CRUD (Create, Remove, Update, Destroy) functionality is there without us doing anything, just with one line of code.

Check out these websites and tutorials for more information:
Ruby on Rails Homepage
top 12 ruby on rails tutorials
onlamp.com tutorial for rails

News: Google starts Sourceforge alternative

2006-07-28T01:05:00.000-07:00

Not beautiful but interesting, thats for sure!

code.google.com/hosting

Developing an IOC-Container for Dependency Injection Part I

2006-07-27T00:49:00.000-07:00

Part I | Part II | Part III

Before we start: If you don't know whats behind IOC and Dependeny Injection, then read Martin Fowlers Article or jump to Wikipedia.

A couple of months ago i played with lots of IOC-Containers out there. Two of them interested me in the long run: Spring and Picocontainer. Spring because of its clean concept (yeah, i know, sometimes xml sucks, but if you make it intuitive...) and Picocontainer because of its "lightweight" concept. But both of them have there drawbacks.

Picocontainer has great code, as you can expect it from the codehaus (the guys with groovy), but nearly zero documentation. Spring, on the other side, is far to big for small projects that like to have an IOC-Container. You can separate the Container in Spring from the O/R-Mapping and MVC Stuff, but its still big. And where would be the fun without writing an own Container?

So what do we want? I'd say, we like to have a really, really lightweight container implementation. It should be extendable and testable. For configuration (for the wiring-together) we use simple xml. Really simple.

To "see" what we want, we write a tiny Test:

First, we want to instantiate an IOC-Container with a given config-File. The IOC-Container should have an interface and an implementation class, so we can change the implementation later on if we want to.


IOCContainer ioc = new IOCContainerStandardImpl("example-config.xml");

Then we want to create an instance of a class via the container.


Customer customer = (Customer)ioc.getInstance("Customer");

Ok, lets test wether customer holds the correct object


customer.logik()

We don't want to tell the Container which implementation class (say, CustomerImpl) is behind the interface (Customer) via code, cause then you have to change the code every time you want to change your implementation. The implementation should be wired over a small, easy to mantain config-file, where you can change the implementation from the outside.

But that should be enough for the first part, the next will be up soon ;-)

Ruby and XML

2006-07-25T13:15:00.000-07:00

Ruby has builtin-support for XML via the rexml-module. This module supports various types of XML-parsing (e.g. building trees, event based streaming,...). We'll try the DOM-like-tree, but don't be afraid - its absolutely not as horrible as working with the DOM api under java.

Now, we want to parse the titles from a given weblog. We gotta use 3 modules for that


require 'rexml/document'
require 'net/http'
require 'uri'

Just that we don't have to type REXML before every command, we include that class


include REXML

Reading data over http is pretty straightforward in ruby


url = 'http://danslog.blogspot.com/atom.xml'
data = Net::HTTP.get(URI.parse(url))

Thats all. But we want to parse, unmarshall and whatever the given xml data


doc = Document.new(data)

The variable doc now contains the DOM-like-tree. Lets do an each over the titles in the feed. You can use xpath for that (imho the best xml spec out there)


doc.root.elements.each("entry/title") do |element|
  p element.text
end

That should output something like this:

"Groovy and SOAP"
"Pattern: Good Citizen"
"Ruby on Rails"
"News: AJAX-Framework als Apache-Projekt vorgeschlagen"
"Picocontainer"

Of course, streaming rss-feeds is even easier with ruby streaming apis for, well, rss-feeds, but i wanted to show how easy it is to work with xml under ruby.

Here is the whole class:


require 'rexml/document'
require 'net/http'
require 'uri'

include REXML

class RSSTitleCheck
  def initialize
    url = 'http://danslog.blogspot.com/atom.xml'
    data = Net::HTTP.get(URI.parse(url))
    doc = Document.new(data)
    doc.root.elements.each("entry/title") do |element|
      p element.text
    end
  end
end

RSSTitleCheck.new

You can find more info about REXML and HTTP-Access for Ruby here:

rexml intro @ xml.com
rexml tutorial @ germane-software.com
networking libs @ rubycentral.com/book

Groovy and SOAP

2006-07-13T03:19:00.000-07:00

All right, i've never seen SOAP implemented as easy as this:

Write a groovy-Script like that:


class SOAPTest {
  String printMe(String name) {
    return "Hello "+ name
  }
}

Start a SOAP-Server:


import groovy.net.soap.SoapServer
def server = new SoapServer("localhost", 6980)
server.setNode("SOAPTest")
server.start()

And check it with a client:


import groovy.net.soap.SoapClient
def proxy = new SoapClient("http://localhost:6980/SOAPTest?wsdl")
def result = proxy.printMe("Johnny")

More Information at the Codehaus-Homepage:
Groovy and SOAP @ codehaus.org

Pattern: Good Citizen

2006-07-07T02:15:00.000-07:00

Every good OO-Developer knews: couple your objects as loose as possible, I already mentioned a popular IOC-Container (PicoContainter, article)
Dan North and Aslak Hellesoy defined the pattern "Good Citizen", you can check it out at the PicoContainer-Homepage. It sets some Rules for "well designed" classes, like the Dependency Injection Pattern which is the basis for all the IOC-Frameworks out there.
Maybe not all the rules are my cup of tea (like the one with seperately defined return values like StringList.EMPY), but nevertheless, if everybody would only write "Good Citizens", there would be less headache for the everyday life of a developer...

to the Pattern@codehaus.org

Ruby on Rails

2005-12-23T13:06:00.000-08:00

I have translated this article in english here

(this is an older article in german, you can find new articles here

Ruby on Rails ist ein streng auf MVC basierendes Web-Framework, geschrieben und erweiterbar in und mit Ruby. Es baut sehr stark auf einem Generator-Ansatz auf, die komplette Verzeichnisstruktur und die Vorlagen für Models, Views und Controller können generiert werden. Durch den weitesgehenden Verzicht auf Konfigurationsfiles ist es auch für Menschen mit Abneigungen gegenüber Administrationsübungen (Der Autor schließt sich hier ausdrücklich ein) wunderbar geeignet.
Es entfallen sinnentleerte Mapping-Dateien (Klasse Angebot -> Tabelle Angebot), da Ruby anhand von Namensgleichheit zwischen der R- und O-Welt die Objekte und Attribute auf die Datenbank mappt.

Um das ganze auch mal anhand eines Beispiels zu testen, hier eine kleine, praktische Anwendung: Eine Todo-Listen-Verwaltung. Hier sollen Todo-Listen nebst einzelnen Todos angelegt, geändert, gelöscht und angesehen werden können.

Aber kommen wir zuerst zur Technik. Um mit Rails arbeiten zu können brauchen wir zuerst Ruby, das bekommen wir auf der Ruby-Homepage. Um eine Datenbankanwendung entwickeln zu können, benötigen wir ausserdem ein Datenbanksystem. Typischerweise verwenden wir hier das (mittlerweile) auch einfach zu bedienende MySQL, hier im Beispiel in der Version 4.1. Nebst dem kostenlosen MySQL Administrator 1.1. Beides auf der MySQL-Homepage zu beziehen.

Nach der Installation können wir in per Kommandozeile mit dem bei Ruby mitgelieferten Package Manager Rails installieren.

gem install rails --include-dependencies

Nun erstellen wir das Projekt "Todo":

rails todo

Dadurch wird der komplette Verzeichnisbaum generiert. In dem Unterverzeichnis "app" landen später die views, models und controller.

Als nächstes erstellen wir eine neue Datenbank (Schema) unter MySQL mit Namen "todo" inklusive zwei Tabellen:

lists (id, name, bezeichnung)
todos (id, name, txt, list_id)

So, jetzt editieren wir im Verzeichnis todo/config die Datei database.yml und passen sowohl die Entwicklungs-, Produktions- und Testdatenbankeinstellungen entsprechend unserer Umgebung ein.

Starten wir nun den Web-Server:

ruby script/server

Mit einem Klick auf http://localhost:3000 bekommen wir den erfolgreichen Start bescheinigt.

Lassen wir Rails nun seine Stärken ausspielen. Durch die Benennung der Listen-Tabelle in "lists", schließt Rails darauf, dass eine Komponente "List" in unserer Anwendung auf sie mappt. Rails ist hierbei (im Englischen) sehr Clever, mappt auch von "Entries" auf "Entry". Hier erkennen wir zum ersten Mal den von den Entwicklern und dem Autor vertretenen Vorsatz "Konvention über Konfiguration". Zwar ist der Code Konventionen unterlegen, dafür sind Deployment-Deskriptoren und Mapping-Files passe.

Generieren wir nun model und controller der Komponente "List":

ruby script\generate model List

ruby script\generate controller List

Erneut generiert Rails die Stubs für uns, inklusive Helper-Klassen und Unit-Tests.

Editieren wir nun unter app/controller die Datei list_controller.rb und schreiben innerhalb der Klasse

scaffold :list

Ein Klick auf http://localhost:3000/list/new zeigt uns, was wirkliches Prototyping ist. Die CRUD (Create, Remove, Update, Destroy) Funktionalität ist komplett vorhanden. Und das mit nur einer Zeile Code im Controller.

Mehr hierzu demnächst.

add this article to del.icio.us

News: AJAX-Framework als Apache-Projekt vorgeschlagen

2005-12-22T13:17:00.000-08:00

Hm, brauchen wir AJAX? Mal überlegen, was war mein erster Gedanke? A steht für Asynchronous. Das ist ok. J für JavaScript. Autsch. JavaScript als Bestandteil eines neuen Hypes? AJ - And XML. Spätestens seit zu großen build-Files diverser Ant-Jünger und zerklüffteten 2.1er EJB-Deployment-Deskriptoren auch lieber nicht.
Da hofft man also, dass der Endandwender sich mit dem Response/Request Zyklus abgefunden hat bis modernere Technologien Abhilfe schaffen, da findet doch einer raus, dass man über ein XMLHTTPRequest-Objekt per JavaScript Abfragen auf den Server machen kann. Jetzt auch bei Apache.
Nun, JSP sorgte dafür, dass man per Tags keinen serverseitigen Skriptcode mehr benötigt, jetzt haben wir wieder den Clientseitigen.
Wems gefällt. Mehr dazu hier:
artikel@golem.de

Picocontainer

2005-12-21T13:00:00.000-08:00

Picocontainer ist ein sogenannter IOC-Container. IOC steht für Inversion of Control und wurde (soweit ich informiert bin) von Martin Fowler vor einiger Zeit auf den Begriff Dependency Injection konkretisiert. Grundsätzlich bedeutet IOC, dass die Kontrolle für die Erstellung von abhängigen Objekten nicht mehr explizit sondern implizit gesteuert wird.

Beispiel:
public class KundeDAO {
[..]
Database db = new OracleDatabaseImpl();
[..]
}

In dieser Klasse ist die Verknüpfung zur Datenbankimplementierung fest, eine Wiederverwendung der Klasse wäre unter eines Deploys auf einem MSSQLServer problematisch. Falls eine Vielzahl kleiner Objekte viele Beziehungen zueinander aufbauen ist von einer losen Koppelung kaum noch zu sprechen.

Vereinfachend gehe ich jetzt nur auf zwei Arten von Dependency Injection ein

Möglichkeit 1:
Setter Injection

public class KundeDAO {
[..]
Database db;

public void setDatabase(Database db) {
this.db = db;
}
[..]
}

Möglichkeit 2:
Constructor Injection

public class KundeDAO {
[..]
Database db;

public KundeDAO(Database db) {
this.db = db;
}
[..]
}

Schauen wir uns in erster Linie Möglichkeit 2 an. Die Beziehungen (hier vereinfacht nur die Datenbank) werden übergeben, durch die Abstraktion zum Interface Database kann jede Form von Datenbank übergeben werden. Damit bleiben die Objekte lose gekoppelt und die Wiederverwendbarkeit steigt enorm.

Mit einem IOC-Container wie Picocontainer entfällt die direkte Verwaltung und Zuordnung der Beziehungen und die platz- und zeitraubende Instanzierung abhängiger Objekte, da der Container die Abhängigkeiten "injiziert" (daher Dependency Injection) und die Klassen selbst nicht mehr für die Erstellung verantwortlich sind.

Um das auf obiges Beispiel anzuwenden, würde ein Code-Snippet folgendermaßen aussehen:

MutablePicoContainer pico = new DefaultPicoContainer();
pico.registerComponentImplementation(OracleDatabaseImpl.class);
pico.registerComponentImplementation(KundeDAO.class);
KundeDAO kunde = (KundeDAO) pico.getComponentInstance(KundeDAO.class);

Hier werden einem neu erstellten PicoContainer die einzusetzenden Klassen übergeben und anschließend eine Instanz der KundeDAO-Klasse erstellt. Per Hand würde man das folgendermaßen abbilden:

Database database = new OracleDatabaseImpl();
KundeDAO kunde = new KundeDAO(database);

Bei einem so trivialen Beispiel wie hier macht das eher wenig Sinn. Wenn allerdings viele Klassen viele Abhängigkeiten untereinander haben ermöglicht Pico eine weniger starre Kopplung.

Soviel zur Einführung. Pico bietet auch Lifecycle-Support an und wirkt sehr sauber entwickelt (Test-First). Mehr Infos gibt es hier:

Picocontainer Homepage
Pico 5-Minuten Einführung

CSS - Einführung Teil 1

2005-12-21T12:58:00.000-08:00

Wer schon einmal eine Homepage erstellt hat, kennt das Problem: Der Code wird spätestens bei den Designanpassungen (Schriften, Hintergrundbilder,...) unübersichtlich und vor allem schwer wartbar. Das kommt daher, weil das "Was?" (Was wird angezeigt?) und das "Wie?" (Wie wird es angezeigt?) im HTML vermischt vorliegen.
Die Lösung aus der Misere: Cascading Style Sheets, von Freunden "CSS" genannt.

Ein Beispiel. Nachfolgend eine Demonstrationsseite (das unter CSS-Jüngern alseits bekannte "CSS Zen Garden Projekt") in reinem HTML.

Demo-Seite

Hier ist lediglich das "Was?" hinterlegt. Da CSS extern das "Wie?" übernehmen kann, können mit zwei unterschiedlichen CSS-Dateien ein und die selbe HTML auf vollkommen unterschiedlichen Wegen interpretiert werden.

Beispiel 1
Beispiel 2

Diese Beispiele haben beide ein und dieselbe HTML-Datei, die Texte sind identisch, aber durch CSS wird da Layout vollkommen anders dargestellt.

Ein erster Schritt:

Nehmen wir einmal folgenden HTMLcode zur Grundlage:


 <html>
  <head>
  </head>
  <body>
    <h3>Ein erster Test</h3>
    Mit ein kleinwenig Text
  </body>
 </html>

Zeigt man diesen Code im Browser an, wird einfach eine Überschrift mit etwas Text abgebildet:

Ein erster Test

Mit ein kleinwenig Text

Langweilig, oder? Passen wir doch ein wenig die Schrift an. Wir schreiben eine Datei test.css:


  body {
    font: normal 10px/1.6em "Lucida Grande", "Verdana", sans-serif;
  }

  h3 {
    color: red;
  }

Dem aufmerksamen Betrachter fällt auf, dass vor den {}-Klammern jeweils ein HTML-Tag steht. In den Klammern werden dann Anpassungen für diesen Tag implementiert. Wenn wir also wollen, dass sämtliche h3-Überschriften auf unserer Website rot sind, müssen wir lediglich das obenstehende css-File einbinden.
Hierfür müssen wir im <head>-Abschnitt folgenden Code hinzufügen:


  <link rel="stylesheet" type="text/css" href="test.css" />

Das Ergebnis mit CSS:
hier klicken

Demnächst mehr!