techno.blog("Dion")

I talked about the lovely clean, responsive, UI of tadalist.com.

There is ONE tweak that would make me happy as a bunny. At the moment you can subscribe to an RSS feed of your ToDos. At the moment the RSS pings you with new additions, which is nice, but isn’t what I want.

I would like the RSS feed to come at me with the following everytime a ToDo list has been changed (new item, item marked as ‘done’, etc).

RSS for Todo List: Code Changes for X

TODO:
- Add method foo() to Bar
- Refactor FileParser
- Scrap whole thing for Rails implementation

DONE:
- Add method bar() to Bar

This would be great as then when I am offline, I will always have my current Todo’s in my RSS aggregator. When a new RSS entry comes in for a ToDo list, I would just nuke my last one.

OR, if the same GUID was used, it would just be replaced!

I found out about TaDaList.com from Jim Weirich:

I just came across this one today, and its the real reason I started this blog entry. Wow, what a simple idea. And so beautifully executed. Notice the lack of submit buttons. Just start typing todo list entries, hitting a return to go to the next one. Finished a todo item and want to check it off? Just check the box

Poor Pat asked Mark Roth of Sun to not jump in a take peoples syntax.

The problem is that once JSP (via JSTL) says “${foo} will resolve to X”. Other frameworks don’t get a look in. Pat was worried that #{..} would be eaten up yet and OGNL uses that for maps and such!

Matt Raible was on the chat session with Mark Roth and asked these questions:

I asked the following question as part of the chat:

Is there any chance that web frameworks (like WebWork) could override the default settings for the EL? So ${myForm} can look in areas other than page/request/session/application scope – i.e. WebWorks’s ValueStack?

It looks like this *is* going to be a part of JSP 2.1 – from Mark Roth:

JSP 2.1 is not only concerned about supporting Faces. We also want to support other frameworks. the new unified EL 2.1 API supports the concept of a pluggable VariableResolver (similar to the one that Faces has) which allows you to plug in your own logic for how variables like ${myForm} are resolved. So yes, this will be supported.

Imagine that? Pluggable Resolvers? Now we can live nicely together.

Note to Self: Write a nasty revolver which does weird things with ${} and get it somewhere to confuse people on projects:

Why does ${foo} print out SO YOU WANTED SOME FOO DID YAH! instead of the value?

Matt has written about Trails – like Rails, but with Tapestry, Spring and Hibernate.

I put in a cheaky comment to see what a video on setting up a simple web application would look like. Matt thinks it would be 20 minutes long. That is on a good day, with no mistakes. Compare this scenario to the Rails demo.

Matt talked about how we seem to produce so many files in Java, due to the way we architect things:

model.Person
dao.PersonDAOTest
dao.PersonDAO
dao.hibernate.PersonDAOHibernate
service.PersonManagerTest
service.PersonManager
service.impl.PersonManagerImpl
webapp.action.PersonActionTest
webapp.action.PersonAction
web/pages/personList.jsp
web/pages/personForm.jsp

The last two JSPs can be generated, but that’s still a buttload of classes (9) just to CRUD (and test!) a database table. Not too mention all the files you need to edit for Spring and i18n.

dao/hibernate/applicationContext-hibernate.xml
service/applicationContext-service.xml
test/web/web-tests.xml
web/WEB-INF/classes/ApplicationResources_en.properties
web/WEB-INF/menu-config.xml

Ouch. Matt also pointed out that he has had requests to add support in AppFuse to generate all of these files for you. This would look good in a demo, but how about maintainence?

This is an issue with code gen in general, and one that you see a lot in languages like Java. Even with tools such as great IDEs (IntelliJ/Eclipse) and and code gen, that only helps when you are writing the code. What about reading it (which you do a lot more of in a applications life time (hopefully!)).

What I like about Rails is that it isn’t about code gen. It is about smart defaults which are extension points. For simple CRUD dynamic web sites the defaults can work well, and your application is done quickly. If you need to extend the functionality then you get in there and put in the extension points (in this case, you normally just create the right methods / objects).

I have always liked the mantra of:

make simple things simple, and hard things possible

I think that a lot of frameworks don’t allow this.

I also think that there is a HUGE difference between a dynamic website, and a web application, and would choose very different tools depending on which of these I am building.

There are many great choices out there.

Rails first put out a video of a Mac OS X desktop setting up a simple blogging application right in front of your eyes. This has turned into the Rails Academy, and more videos are being added.

For example, there are now new lessons in which you see a full install from scratch on Windows.

It would be funny to do a parady in which someone starts from scratch, sets up a JVM, an application server, an IDE, downloads a bunch of open source tools, etc ;)

David Hannson (creator of Rails) talked about Dave Thomas who is showing Amazon Rails, Ruby, and more this week.

Man, if Amazon starts getting into the Ruby wave there would be a bunch of folk who could go up and get some work done :)

If you don’t know much about Rails, you have to check out the Setup Movie.

Picture having someone video you as you start a new web application. Picture having something done in 10 minutes. Watch the video, and you will see how cool the web framework is!

Joe Walnes just emailed the SiteMesh list with plans for SiteMesh 3. They all sound good, and it is great to see work ramp up.

If anyone has good ideas, send them over to the list.

If anyone is using Tiles. Give SiteMesh a try ;)

Hi everyone,

I just thought I’d give you an update of what’s in store for the upcoming SiteMesh releases and how they benefit you.

Firstly, there are a number of accumulated bugs that we’re steadily working our way through. The recent 2.1 and 2.2 releases have been mostly bugfixes, and this will continue for the 2.x series, including those related to using MVC frameworks such as Struts and WebWork.

http://jira.opensymphony.com/secure/BrowseProject.jspa?id=10000&report=roadmap

Meanwhile, SiteMesh 3 has been brewing. It’s been four years since SiteMesh was first open-sourced (it existed for two years before that as closed-source) and in that time it hasn’t really changed significantly. SiteMesh 3 is going to see the largest set of improvements since it was initially released.

== Flexible HTML processing ==

The core of SiteMesh is based around an HTML parser that is very fast and tolerant to badly formed HTML, however at the cost of being extremely hard to extend.

SiteMesh 3 will contain a new parser, which is easy to customize, without compromising on performance and tolerance to malformed HTML. This will allow extensions to be written that can:

* Extract user-defined properties from the page beyond the predefined ones from
<title>, <meta>, <content>, etc.
* Remove blocks of content from the page.
* Transform HTML as the page is parsed.

SiteMesh will come bundled with extensions for popular tasks and it will be trivial to add your own. More on this in a follow discussion.

== Improved Velocity integration ==

This follows on from some work done by Atlassian and will allow a page
to be generated using the Velocity API as an alternative to calling Servlet
RequestDispatchers and the Filter.

This offers significant performance improvements for applications that don’t
use JSP and allows more of SiteMesh to be used in environments outside of
the Servlet container, which leads nicely on to the next feature.

== Offline support with StaticMesh ==

There has been a lot of demand for using SiteMesh to generate web-sites in an
offline manner. A common case for this is a simpler alternative to
DocBook style tools, allowing documents to be authored in standard HTML
capable word-processing tools (such as MS Word, OpenOffice and Mozilla
Composer), giving you the full capabilities of a rich-text word-processor and
without the need to learn a special markup/schema.

SiteMesh can then process these raw HTML files and generated another set of
static HTML files with the appropriate presentation and navigation added.

Building upon the extended HTML processing capabilities, it will also be
possible to do things like generate a table of contents, footnotes, and
diagrams from inline syntax.

There have been at least three seperate incarnations of StaticMesh appear over
the last few years. We hope to bring the best bits from each of these into the
final version.

http://www.pols.co.uk/downloads/static-mesh/tutorial.html

StaticMesh will have a simple API for configuration, bundled with a
command-line wrapper and Ant task.

== Backwards compatability ==

Just to ease your minds, you’re not going to have to rewrite your applications
to use SiteMesh 3. Great effort will be taken to ensure that backwards
compatability is preserved. The library will have more features, but at the
same time a lot of the old stuff can be simplified. Dependencies will be
minimized and optional – for example, you will only need velocity.jar if you’re
actually using the Velocity stuff.

I’ll be posting more information in follow up discussions.

[Watch this space...]

cheers
-Joe

There has been a lot said about Struts. Most of what I hear is:

• It sucks! My pet framework is much better
• It is great! Although I have never used anything else
• It is good enough

I have heard the “it is good enough” a lot recently. This especially seems to come up when developers are on project where the requirement is to use Struts. “My boss told I had too”. “It is a corporate standard”.

I especially feel sorry when someone who writes a popular framework is forced to use it ;)

For a lot of people, they have grabbed this reality, and have chosen to make the most of it. This results in work such as Cobbie’s, in which has has adapters which allow him to use actions which work in WebWork 2, right in Struts. Add to this a nice testing framework, and other items (e.g. use SiteMesh rather than Tiles, using Spring, etc) and then it has you wondering. Is Struts that bad?

I think it is definitely usable. I mean people are coming up with good solid applications using Struts. However, I am not sure why I would choose it on a new project (other than for political reasons, or due to the staff [a group of Struts experts]).

I am lucky enough to be working on project where we got to choose the web framework. We can use Tapestry or WebWork and noone has cared. What a pleasure?

What is the future for Struts? I think it is destined to take a U-turn, or it will die in legacy. What is the U-turn? Make it work as that framework on top of JSF, which makes JSF usable ;)

I went to see Erik Hatcher talk about Tapestry at the local JUG last night.

It was a good talk, as Erik does a good job and explaining what is good and bad at a developers level (no foofy high level marketing-speak :)

If you have used Tapestry, it is painful to look at JavaServer Faces applications. I had a really interesting conversation with Erik about how a framework is needed ON TOP of JSF, to give you a nice way to work.

How will we get this framework?

• Tapestry Server Faces: In theory, since JSF has a lot of extension points, a Tapestry layer could be placed on top of the JSF event handling model. It would look like Tapestry. Feel like Tapestry, but would be running in JSF (I don’t know what Tapestry would gain from doing all of this work though)
• A Faces Impl: Something like MyFaces can come a long and write a layer on top of the JSF crud. They are already doing a good job on making some things easier… and this would be taking it to the next level
• Struts: Some would argue that Struts as it exists is @deprecated (as Erik puts it). It could evolve to become glue on top of the base JSF framework
• JSF itself: They could make the spec and the RI decent. Shocking I know.
• Some New Thing: Of course, some bright spark can come along and out-do everyone :)

I wonder if this approach could work. Could we have a usable layer on top of JSF? Would JSF tools be able to work with this world too? Or will we always be stuck in a lowest common denominator?

As every vendor comes out, they have their own set of widgets, so you end up working on “Oracle JSF” versus “JSF” anyway. I know, in theory you could use Oracle components on some other server…. but in reality: it is about the tools, and sometimes that doesn’t work that great.

In this vein, it was good to see the JSF Component Metadata Proposal from Oracle.

I really hope that there will be a JSF world where my HTML isn’t hidden away under ugly taglibs. This is the web. We work with HTML. Let my designers see it!

Mike Henderson is on a roll with his entries on Tapestry, and custom hooks.

Less Configuration – Enhanced Tapestry Component Resolution, Part Two, Part Three.

I like to be able to organize files into groups with folders and I also don’t like to do too much configuration file maintenance. Tapestry will find components in the /WEB-INF directory in my WAR without configuration but with many pages and components in an application it becomes unwieldy. Tapestry allows me to add these components to my specification, specifying the path, relative to the /WEB-INF folder, and t-deli.com provides an ant-task to automate the maintenance of these component declarations. What if I could structure my pages and components into any directory structure I want and not have worry about maintaining the application specification file, even with an automated tool? I could add components while testing without a restart. Since servlet containers can explode a deployed WAR file into a directory structure this method would even work in a deployed Tapestry application.

Fortunately, Tapestry has a number of extension points which can be used to extend various framework behaviors. One of these is the ISpecificationResolverDelegate interface.

I wonder if any of this will change with 3.1…. especially with the enhanced HiveMind stuff.