> From: Pilgrim, Peter [mailto:[EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Andrew Hill [mailto:[EMAIL PROTECTED]
>
> >
> > Any Expresso users out there?
> > Id be interested in hearing your comments and evaluation of
> > this framework.
> >
> > It uses Struts as the basis for the presentation layer, Id be
> > especially
> > interested to know if it maintains Struts flexibility of
> > allowing you to use
> > any (i.e.: not JSP) view rendering technology, or will one have
> > to depend
> > heavily on Expresso tags for a lot of things when doing the view?
> >
> Hello Andrew
>
> I am meaning to give a response as an Expresso core committer, but
> I am tied up with project requirements meetings all day. I will
> sent a full reply at home, if you can wait until then.
>
==////==
I have been Expresso developer since December 2000 when I got involved
with the framework for electronic MIS project way back for
Deutsche Bank in London. I was evaluating various MVC frameworks.
At the time Struts was in its infancy (0.5 version). Web Macro and
Velocity were available, Tapestry, and Barracuda were already
sharpened tools. I looked at the J2EE compatibility. The number of
users that supported the product. How many subscribers were on
the mailing list? Was it popular? Could get support?
How helpful were the developers? I downloaded the source
code and had a look at it to see the actual design.
We choose Expresso because it was more J2EE standards compatible
and closer to the Java Servlets and Java Server Pages specs at the time.
Expresso has a number of features. It had its own MVC framework. It had
web security. It had HTTP Controllers and most important for Deutsche
back then it had DBObjects. We are talking 2001 so Hibernate was still
very young, and JDO did not quite the maturity. DBObjects appealed
because they were like `Generic Data Transfer Object'. All the
data columns could be accessed by using key just like a HashMap.
Since a lot of the columns were going to be generically and dynamic
generated using stored procedure engine. Also at the time DBObject
supported full CRUDS (Create, Retrieve, Update, Delete & Search)
functionality pretty easily, plus it had nice search and retrieve
mechanism. Our MIS solution was targeted to a single web application,
sitting on one Tomcat / Apache Stronghold server, so we didn't require
entity EJBs or session beans (J2EE 1.1) and an expensive application
server to go with it.
I would say the value-add to Expresso was the DBObjects (data objects)
and the fact we did not have re-invent the wheel creating a
security matrix, MVC framework, HTTP controllers. Additionally
Deutsche got other features like Jobs and Long running Queues
and a couple of useful utilities thrown in for free.
The picture in 2004 is a little different. Contemporary thinking has
changed for J2EE developer.
(*) We are fast moving to lighter weight framework
(*) Dependency injection is the "in-thing"
(*) Build web applications using an abundance of other libraries and
frameworks is now a reality. We have an environment of
``mix-in technologies''.
{ Flash / JSP / XML } :
{ Struts / Tapestry / Velocity } :
{ Castor JDO / Coco Base / Hibernate [ / EJB 3.0 ] )
{ Pico / Avalon / Spring }
(*) Other elements of technology that deal with specific problem
domains in technology have become stronger and better at what
they do. e.g. Struts or Hibernate.
The current Expresso Framework as a "heavy" framework is especially
good for building a web application with a load of the heavy duty
Tonka Toy work is done for you.
What are the benefits of Expresso
Somebody else has built the user login controller and implemented
a web security matrix. You as a developer don't have to do it.
Somebody else has built the finite state controller, which is a
Action subclass and with state method, and you can effectively
transition between controllers and state (i.e. Action Chain safely)
You as a developer don't have to write this.
Somebody else has built as a abstraction of controller request and response
and guess what you call Controller from a command line program,
as if you call pure Struts Actions from the DOS or UNIX shell.
You as a developer don't have to write this.
To top it all off, somebody else said, let us have a Administration screen
function where all DBObjects and Controllers and their corresponding
security matrices can be manipulated at the front end. She also said
let have a lot of other configuration stuff that we can use in a
web application. That somebody and her good ship mate eventually
went off and wrote it. Again you as a developer don't
need to re-invent the wheel.
This is what Expresso has now. In 2001 the must-have was DBObject
library. This is less of importance for developers since we have
some very good persistence libraries such as Hibernate, JDO, and
very soon EJB 3.0. The difference between Expresso and pure Struts
is that of a elementary car chassis and monocoque and a kit car
in a box. With just Expresso libraries and suitable database
you built a completely database-driven web application
Weakness of Expresso
(*) It has some legacy framework source code inside it.
(*) The age of the framework presupposes or pre-empt some newer libraries
(i) The original MVC ideas and code base were written before JSP 1.0.
HTTP Controllers were thrown then out but reworked to integrate with
Struts 1.0 and then later 1.1
(ii) It does not have a lot of Unit test. Some code was
written before JUnit was popular.
(iii) Some of the original code was built against Java interface
in order to future-proof it.
(*) It is a little monolithic in terms of today's architecture.
The Future
The future of Expresso in 2004 and beyond I guess is creating a modular
Framework. At the moment Expresso is large, although in terms of hardware
and disk space this is becoming less important by the day. As core
committers we have seen that Expresso needs to modular in the same
way that JBoss application server is modular through JMX and MBean.
We have some pre-alpha code in Expresso that forms the basis of
turning the framework into modular application. We call this code
the Kernel. We think a ``Micro Kernel'' at the heart of the framework is
the new wave. (The kernel is not JMX model but could be
implement using JMX components MBeans in the future)
But aim for a kernel design, we can then offer a developer a bendable
piece of framework kit that he can choose whatever components he needs
or to even replace those just like JBoss does. This means if you
dont like the default cache layer, then you can write brand new
one, or write a wrapper against one you prefer it, and integrate
into the framework.
I hope it answers some of the question and hasn't driven you mad.
Fingers crossed.
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
