RE: [Springframework-developer] Component Centric Web Framework for Spring

[Keith D. <ke...@in...>]

Darren,

What's most constraining about the Servlet API in your opinion?  Is it the
API really? Or is something with the implementations of it that concern you?

I whole-heartedly agree the ability to map URLs directly to methods on
java.lang.Objects is a important feature--exactly what I saw in Django that
I liked.

We are doing this now with Spring Web Flow, where you have declarative
request path binding as well as request parameter binding.  The binding
machinery there is fully generic as well, part of
spring-projects/spring-binding (a separate library currently driven by Web
Flow's needs).

I'm not sure how many folks realize this, but Spring Web Flow at its core is
a generic controller engine (independent of the Servlet API in fact).  The
same engine can be used to orchestrate both stateless and stateful flows.
The XML configuration format folks identify most with it is targeted at
orchestrating multi-step (stateful) navigations, because that's been the
focus of the product to-date, but there is a real opportunity to engineer
specific controller packs that build-in convenience for common flows (like
mapping a single request URL to a strongly-typed Java method invocation
automatically, with support for type-conversion and validation during that
process, and automatic exposure of any return value to the view).

What problems do you believe need a scripting solution in the web-tier?  I'm
curious--it'd be interesting to consider integration of a scripting
technology into the Web Flow engine, and where they might fit.

Good stuff,

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Darren Davison
Sent: Sunday, March 26, 2006 12:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Component Centric Web Framework for
Spring

On Sun, Mar 26, 2006 at 06:29:12AM -0500, Keith Donald wrote:
> Hey Darren,
> 
> Could you maybe summarize what you see in Django that would be good 
> influence for future enhancements to Spring's web stack?  Would be 
> good to consider and discuss those for the 2.x series and beyond...
> 
> One of the features I see on a brief glance I think is important is 
> the ability to design your on URL scheme using URL mapping expressions.

Hi Keith,

In my opinion, the biggest barrier to leaner, more dynamic Java web
frameworks is the Servlet API itself.  RoR, Django, CherryPy and others
aren't constrained by it and manage to do pretty well for themselves.  What
does the requirement for an implementation of this API buy for the large
number of enterprise web apps which are basically CRUD wrappers around a
database?  Many of the existing frameworks in Java land are starting to look
a bit too heavy for this compared to the ease of setting up in Ruby or
Python.

The ability to map URL's directly to objects or methods via something as
simple as regex declarations lowers the barriers to entry greatly and makes
a simple web layer very quick to knock up.  OOWeb for example (a simple Java
port of CherryPy that a colleague and I wrote last year just to prove the
point) offers a complete web novice the ability to start generating dynamic
web content in less than 10 minutes.  You get request parameter binding to
your methods, form handling, security, logging, session replication and a
simple built-in HTTP server in a jar that's around 60KB in size with zero
additional dependencies.  OK, so it's prototype stuff, but its purpose was
to show that if you don't constrain yourself to the "standard" way of
thinking (Servlet API), you can do quite a lot of stuff with greater ease
and speed.  OOWeb is in fact being used in a couple of small production
sites anyway, but if we were to look at it seriously, we'd probably take the
HTTP engine from Jetty or something and build the object mapper around that.

The other aspect is the scriptability of the web tier.  I know the dynamic
stuff around BSF bean definitions hasn't really gone anywhere since it was
mooted a couple of years ago, but this may be the best way forward if we
want to hang on to the coat tails of things like Python and Ruby.  Jython
development seems to have stalled, which is a shame, and Groovy doesn't
really appear to be building on the momentum it looked like having a while
back either, but perhaps being first class citizens in a major web framework
would help.

Consider the Java web application framework "sans Servlet Container", and
Spring seems to be in a perfect position to exploit an opportunity.  After
all, we already have a fantastic container and all the goodies you need to
create a full featured service and data tier.  If you could throw up a web
tier around your database in the same sort of time that you can be
productive in Django and RoR (including re-code and re-load semantics) then
that might be attractive to a lot of people who are currently flirting with
the more dynamic upstarts.  Having the Java bindings available from web
scripts to the Spring container or other "Enterprise" deployed components is
the USP that the others don't have.

"Spring WebScript" - imagine the possibilities :)

--
Darren Davison
Public Key: 0xDD356B0D