Tapestry: opinion on page property specifications

I think it is *bad* practice to define page properties with explicit initial-values. The main qualification for this statement is based upon the premise that the page implements PageBeginRender. I oppose defining explicit initial-values (other than new HashMap(), new HashSet() etc.) because it's unclear to the maintainer how/why certain variables are being set and requires two files open, rather than the one java file, to ascertain page state. In order to be really readable and maintainable the coder should define an initial setup method and then invoke that upon first page load. Thus providing logical class definition (since it *is* part of the object and now resides in its guts) and clear code documentation.

Aaron's cookies

Chips Ahoy White Fudge Chunky cookies are the best of the lot.

Good reasoning for ORM

http://www.gloegl.de/17.html
----------------------------------
If you are working with object-orientated programming and relational
databases, you will surely have noticed that these are two different
paradigms. The relational model deals with relations,tuples and sets -
it is very mathematical by nature. The object-orientated paradigm
however deals with objects, their atributes and associations to each
other. As soon as you want to make objects persistent using a
relational database you will notice: There is a rift between these two
paradigms, the so called object-relational gap. A object-relational
mapper (or ORM as a shorthand) will help you bridge that gap.

Well, how does this gap manifest? If you are passing objects around in
your application and sometimes reach the point where you want to
persist them, you will typically open a JDBC connection, create an SQL
statement and copy all your property values over to the
PreparedStatement or into the SQL string you are building. This may be
easy for a small value object - but consider this for an object with
many properties. Thats not the only problem. What about associations?
If your Cat object you want to store has a List of kittens contained?
Do you store them too? Automatically? Manually? What about foreign key
constraints?

The same applies for loading - let's assume you load a Cat object from
the database and it has a collection of kittens. Do you load the
kittens too? Not load them yet but later? If you load the kittens,
consider each of the kitten object has an association to yet more
objects. In this case, such eager loading may easily load your
complete object tree. Not loading the kittens is however not really
better however - you will need explicit reloading later if you
probably want to access the kittens.

As you can see, the object-relational gap quickly becomes very wide if
you have large object models. And there are a lot more things to
consider like lazy loading, circular references, caching, etc. In
fact, there have been studies that showed that about 35% of an
application code was produced by the mapping between application data
and the datastore.

So what can an ORM do for you? A ORM basically intends to takes most
of that burden of your shoulder. With a good ORM, you have to define
the way you map your classes to tables once - which property maps to
which column, which class to which table, etc

DB4o

http://www.db40.com
http://www.onjava.com/pub/a/onjava/2004/12/01/db4o.html

http://www.theserverside.com/news/thread.tss?thread_id=30353

Tapestry vs JSF

Links:
http://java.sys-con.com/read/46050.htm
http://howardlewisship.com/blog/2004_01_01_archive.html
http://www-106.ibm.com/developerworks/library/j-jsf1/

http://howardlewisship.com/blog/2005/02/tapestry-jsf-and-fud.html
"...Erik Hatcher likes to "provoke" JSF-ers, such as David Geary, to
duplicate the Table component. The Table includes links for sorting
and paging through long contents ... these links just work, without
any configuration in the application. This is the Tapestry way -- drop
it in and let it work. JSF's approach is primarily a view component
and apparently can't duplicate this."

http://www.oreillynet.com/cs/user/view/cs_msg/48307
"Tapestry has literally taken a project that was stalled in
development hell for almost a year and finished it, rebuilt from the
groun up, in 3 months. We built it from the ground up using Tapestry.
We added things as we learned, but it was all very intuitive. First,
simple forms for customer input and simple screens for reporting."

Known implementations. Interestingly these all have their drawbacks.
Oracle's is an "early access edition", MyFaces is somewhat
proprietary, "The MyFaces version of Tiles Support requires the
MyFaces JSF implementation. It will not work with the Sun RI or any
other JSF implementation." And AjaxFaces looks the most intriguing,
but it's a commercial solution!

http://www.ajaxfaces.com/
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html
http://myfaces.apache.org/components/overview.html

---------
Think I need to spend a night hosing around with JSF to evaluate it.

FindFile released!

Just finished releasing FindFile-0.1. Happy to be able to finally contribute something to the OSS world. Download is available at RubyForge, http://rubyforge.org/frs/download.php/4813/FindFile-0.1.tar.gz. I've loved coding this in Ruby and been pleased with how quickly and how great it performs. Gonna be a busy summer, but I hope to knock off some TODOs that I have to enhance it.