FW: [OT] Expresso

["Pilgrim, Peter" <pe...@csfb.com>]

> -----Original Message-----
> From: Pilgrim, Peter 
> Sent: 10 June 2004 13:00
> To: 'Struts Users Mailing List'; 'andrew.david.hill@gridnode.com'
> Subject: RE: [OT] Expresso
> 
> 
> > From: Pilgrim, Peter [mailto:peter.pilgrim@csfb.com]
> > 
> > > -----Original Message-----
> > > From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> > 
> > > 
> > > 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
> 

OOps! I aint subscribed to struts user list on my laptop at home.

--
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org