There has been a lot of talk, even in the Java community, about the Ruby on Rails project. This framework has a now infamous video which has you watching a blog system being built in a few minutes from scratch! Trails is a new framework in Java which is trying to make building data driven web sites easier. It uses Tapestry, Spring, and Hibernate behind the scenes.

What is Trails?

The Trails framework is a domain driven development framework inspired by others that have gone before it such as Railsand Naked Objects It‘s goal is to make developing database driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.

What is a Domain Driven Development framework?

In Trails, as in Naked Objects, we focus on developing the domain objects first. We then allow the framework to Spring forth a fully functional UI to interact with those domain objects.

Introducing Trails

Some people argue about building a simple dynamic web site versus a web application. Can a more simple approach like Trails make sense?

Cool, I will play with it.

I have been spending some time playing with Hivemind and so I decided to try Tapestry too (I am supposedly working but I have a LOT of free time)

Seems like Howard is willing to produce "out of box" integration between Tapestry and Hivemind :

http://howardlewisship.com/blog/2004_02_01_archive.html

He even mention something about integrate HiveMind / Hibernate integration. But after read about O/R Broker here:

https://www.theserverside.com/news/thread.tss?thread_id=29392

, I suspect it would fit better in a Domain Driven Framework approach, basicly because it does not force us to design every domain model using JavaBeans component model.

Sure, Hibernate is much better positioned right now (docs, acceptance, test coverage, etc), anyway I think O/R Broker is easier and even more flexible than Hibernate. And after all, its all about to have fun, right ? ;)

Groovy on Rails is what I was wishing for when I saw the Ruby on Rails demo. Given the kinship of Groovy and Ruby, istseemed like a good idea. Anyway, good luck with the project!

Just what we need. A framework that makes simple things simple and hard things even harder.

Just what we need. A framework that makes simple things simple and hard things even harder.

+1

Yes, that smells like MS ideology with all its advantages and disadvantages. I watched that blog demo and looked at Naked objects in the past and have exactly the same impression: initial wow! Effect, extremely simple development of things, which you are supposed to do, but any step aside and you are in BIG troubles.

“Makes simple things simpler� hmm:
- is that thing really _that_ simple?
- why do I need to develop that thing? If it ‘simple’ then it is already done and I should be able just reuse it.

Blog video example in Rails is a perfect example: if such simple blog is enough for you: just take any blog software and you are good to go. If you need advanced blog, just spend those 10 minutes and install Jblogroller.

My points:
- There is no need to make simple things even simpler;
- There is a need to develop QUALITY software that might be integrated in bigger systems; (like shell, sed, awk, Hibernate, HiveMind, etc)
- There is a need to have REGISTRY of solutions ( like perl’s Cpan ).

PS: I guess VB gurus can create blog in less than 10 minutes

The blog example is misleading because it only shows the predefined templates that are of no use in a real application. I've been using Rails since the first release. When I first saw the demo I had the same doubts, but when I started using it I was amazed at how easy it is to do something that you are "not supposed to do". Right now I'm writing a web forum with a nested set data structure, multi-language support, and a few other things that aren't directly "supported" by Rails, and it's still very clean and development is actually fun.

I recognize experienced architects/developers does not need any framework to keep stuff simpler.

But there are still a lot of projects with some fresh graduate guys trying hard to understand all J2EE and related frameworks mess in their first year within professional projects. Its hard for anyone, even the talented guys.

Valuable tools like Spring, WebWork, JUnit and Hibernate has been helped a lot to keep these teams more productive and focused on business, not on the implementation issues. But IMHO there are still many gaps to fill.

The main benefits of Naked Objects or Trails (I haven´t download it yet) is to force these unexperienced people to not lose focus on the business, the domain.

http://www.martinfowler.com/bliki/AnemicDomainModel.html

With the domain defined, the rest of the job is the usual : presentation components talking to services interfaces. And then Tapestry and Hivemind approach fits nice here, we can easily reuse and extend the application no matter how complex are the new requirements, because we have full power of object orientation, even in the web presentantion tier.

The hard stuff still keep with the team leaders : legacy integration, security, quality of service, acceptance tests, project management (yes!), etc.

So, my point is : keeping the usual job easier is good, because usually the programmers are not so experienced like TSS readers ;)

we can easily reuse and extend the application no matter how complex are the new requirements, because we have full power of object orientation, even in the web presentantion tier.

There is a fundamental law: complexity of a solution matches complexity of problem.
Therefore I consider claims like one above to be groundless.

So, my point is : keeping the usual job easier is good, because usually the programmers are not so experienced like TSS readers

Fire dead wood and give some credits to people doing 'usual' job. They too need power tools, not template solutions for standard 'problems'.

Hello, Konstantin

I have to clarify some points I was unable to explain :

1) I do not believe any tool like Naked Objects or Trails is alone a solution for producing applications. Actually, it can help people to play / experiment their domain model visually and then after this to leverage this domain code base to start producing "usual" things like presentantion components. Just as any other tool we have : UML diagrams, specs, etc

Developers surely will prefer to write tests explore their domain but customers may not be so confortable with tests scripts. Given that collaborating with customers is another crucial factor to any project, I think this is another benefit of this approach.

So there are at least two values : improve communication between the team and to force novice and/or unskilled developers to think about the business to solve before submerge in the hell of the implementation detais.

Naked Objects does not allow us to leverage the domain code because we can not write simple POJOS but hopefully Trails will do - and for the web !

2) I used the term "usual" to describe the sometimes (at least for veterans) tedious tasks like coding Swing and Web UI interfaces. After years doing this, I realized domain layer is much more fun to work with. Its just my personal preference. But I did not said "usual" stuff is not critical to the project, its just another solution´s component and we simply have to build it too.

3)

Fire dead wood and give some credits to people doing 'usual' job. They too need power tools, not template solutions for standard 'problems'.

Are you refering to CRUD ? Naked Objects is much more than simple CRUD, AFAIK. And about the novices, sometimes my mission actually IS to work with them so...

4) I mentioned Hivemind just because Chris Nelson choose to work with Tapestry. Trails could leverage the natural synergy between Hivemind and Tapestry. O/R Broker was just a brainstorm. (just for fun, remember ?)

Hope it´s clear now. see you,

Rodolfo

But IMHO there are still many gaps to fill. The main benefits of Naked Objects or Trails (I haven´t download it yet) is to force these unexperienced people to not lose focus on the business, the domain.

That's all well and good. But it's not a black and white world. As much as users and such care about the domain (they do, they really do), all of the other crap that surrounds the domain and brings it into the users world is very important.

90% of application programming is exposing the domain to the users in some form (screens, reports, etc.).

The problem with very high level frameworks is simply that they lack the granularity to express all of the needs and nuances that make the exposed domain efficient to use for the user.

For a the 150 generic CRUD screens and forms for the maintenance and support tables, it's rarely a problem.

But when it come down to the one program that EVERYBODY uses, that one key screen (say, the Order Entry screen of a distribution system), that's where the tool and framework has to be most flexible, most maintainable, and most usable. As much as having the 150 generic CRUD screens generated for me is a boon, if I have to toss out the entire framework to do the one screen that I really need it work on, it doesn't gain me much of anything.

And that is where most of these tools simply fail. As is said, they make the simple trivial, and the hard impossible.

Many of these tools fail VERY HARD, rather than degrade gracefully, as the demand upon them rises. All of a sudden you find that you get to the point where you can not go any farther towards what you want.

Even though folks have access to the source code of moder frameworks, all of the simplicity of the framework vanishes when you neeed initimate details of its behavior to make it work for you. Most of the novice folks that these may be directed at typically don't have the skills to do that, or simply don't have the time, and give up.

Frameworks are VERY hard to do well, and this is why it's so hard to make things "simple".

Sorry for the off topic, but since Rails was cited, there are already a Hivemind inspired framework in Ruby (?!) :

http://copland.rubyforge.org/

I was very surprise to know about it, but seems like simplicity hype is really taking shape...

I do not see the benefits that the framework brings us. Maybe i am shortsighted. Can anybody give some comparion between this framework and the spring framework's total solution?

Whew,

So as the developer of Trails a little history is in order. The goal of Trails is certainly to make the simple things simple and the hard things possible, contrary to the earlier post. But you all should realize what the current status of Trails is before you pass judgment.. we are at release 0.2, and little more than an idea of how to develop software in a new way than a fully finished framework. By all means, we can argue about whether such a framework is a good idea or possible or whatever. Myself, I'm obviously convinced it can be done and is a good idea or I wouldn't have bothered.

How this got to a top-level post here on ServerSide is a little surprising: literally all I did was post a message on the Tapestry dev list looking for feedback. 2 days later its all over the place. I guess it must have struck a nerve.

So to summarize, Trails draws on the excellent work of predecessors such as Rails and Naked Objects to try be a framework for developing software in a new way. I'm using the term Domain Driven Development to try and describe this "New Way". We have a working version that can give folks an idea where we are headed. But we're just getting started: if you think the direction we are headed in is exciting, you are welcome to join us. If not, that's fine too. We'll gladly refund your J2EE drudgery ;)

Thanks,

Chris Nelson

I'm using the term Domain Driven Development to try and describe this "New Way".

Which is a catchy phrase and domain modelling is in the wind (and for good reason)

My point was that this "new way" doesn't, by definition, address what you are trading for simplicity: tx handling, security, legacy integration, concurrency, load conditioning and so forth.

These are the *real* challenges when faced with a difficult systems development task. You know, CRUD'ing domain objects is simple enough using most any technology.

I'm not against frameworks. I'm just against frameworks that only address the easy problems, not the difficult ones.

I'm not against frameworks. I'm just against frameworks that only address the easy problems, not the difficult ones.

...but having said that. If people really want those kinds of frameworks, then kudos to you and good luck.

You got it -- I am not trying to do everything here. My goal is to leverage existing frameworks like Spring, Tapestry and Hibernate to tap into the solutions they provide to some of these problems. The problem I have with some of the other DDD frameworks is that they DO try to solve these problems themselves, when they are being solved by other people in better ways. Trails is not going to be a be-all do-everything framework. I am trying to make it easier to expose interfaces to and therefore focus on the domain objects. Sure, writing CRUD operations (tho I want to do more than just that) is easy enough, but it's way to much freakin' code for my taste. I just hate writing so much code is the bottom line. I'll leave the "hard problems" to smart peeple.

So to summarize, Trails draws on the excellent work of predecessors such as Rails and Naked Objects to try be a framework for developing software in a new way. I'm using the term Domain Driven Development to try and describe this "New Way".

The novelty of Naked is that it assures WYSIWYG development. Naked is a misnomer. Each object is well dressed in a GUI.

What isn't novel about Naked is its executable model. Executable models have been around for over a decade. The MDA specification describes it. Googling for 'UML "executable model"' gives plenty of hits. I think your blog is wrong to say: "The main, big,important difference between Trails and something like MDA is that MDA and it‘s ilk seem to be mostly about code generation."

It's been a long journey, but the next version of Trails is called Tynamo - come visit us at http://tynamo.org!