Re: [Bodington-developers] spring

[Antranig B. <ant...@ca...>]

Hi there, just thought I'd add my own slant on this. I'd agree with
pretty much everything Ian has said, although reverse his 
recommendations on Spring/MVC - as far as I'm concerned, pretty
much everything in Spring (core) is essentially harmless and can
be used freely - so
Spring == Excellent
SpringMVC == Good, but not very powerful

SpringMVC the way it is has to cater to the "lowest common denominator"
amongst web technologies, which given the way they are right now sets
a pretty low bar for abstraction. Your request model is a "Map", and
while you have the flexibility to lay out URLs the way you like, you
also have the trouble of dealing with them yourself as well.

I developed RSF to continue the Spring philosophy into the webapp 
area - RSF has been described as "JSF reimagined in the Spring style
of development". RSF includes its own "semi-magic" XML templating
engine, IKAT, which for webapps offers a good deal more insulation
from the underlying technology than say, Velocity, Freemarker &c
in that the template itself contains no logic, and the view logic
is not aware of the template. 

I've just made an integration for RSF with JSR-168, and now 
demonstrated the RSF samples working with no code changes in 
Servlet standalone, JSR-168 portlet (shown in Pluto) and as a 
Sakai tool - the only changes appear in HTML templates, and 
web.xml type packaging.

I won't go along at any more length about this but you can find
the docs and details on the RSF wiki at 
http://www2.caret.cam.ac.uk/rsfwiki.

I *will* be making a port of RSF to Spring MVC which might be
useful as a stepping-stone for people who are still using older
web idioms or want to work with a heterogeneous technology mix 
in the same app, but I think once people see it they will
agree there is no real benefit to this approach and they may as
well just use RSF :P

Andy is sitting next to me saying "make sure you tell people that 
if you really don't like the RSF renderer, you really can push the
other templating engines on top".

Antranig.

PS and yes, RSF does have full support for HTTP GET requests :P
(for that matter, everything else in plain HTML and HTTP)

> Hi,
> I've been lurking for all of 24 hours, Im not a Bodington expert,  
> but I
> can tell you a bit about Spring-Hibernate-JSF in the Sakai context.
>
> First off, don't use JSF.
> Unless you are prepared to buy everyone a top end IDE plugin (or
> complete IDE) from BEA, IBM, Sun, Oracle or one of the other JSF-JCP
> members.
> Personal experience here is bad. Its really difficult to debug, it has
> horrible semantics (you don't own the URL). I tried to write RWiki  
> with
> JSF (what an idiot!) and gave up when I couldn't do GET's, silly me,
> though I was writing a web application :)
> We've also used JSF for about 4 projects before, loosing developers  
> and
>   giving up. Its what caused Antranig to (go mad and) write RSF.
>
> If you want to write Win32GUI apps in a web environment and not know
> anything about the HTTP or HTML, then JSF or ASP.NET+VS2003 is for  
> you!
>
> Rant over.
>
> Spring == Good, but be careful.
> -------------------------------
> Spring is the simplest form is great (same can be said for other  
> IoC's).
> It removes nearly all the factory code and provided you are  
> disciplined
> about completely abstract APIs (putting them in the their own jar) and
> implementing those API's you get real separation of concerns.
> Be careful about the Component Manager. The native Spring Component
> manager is quite good, it has a good structure to it and will not  
> cause
> problems reloading etc. If you want more isolation ( as Sakai did) you
> can write your own Component manager, but be careful not to eliminate
> the reload ability. Having 1M lines of code that require a full Tomcat
> restart when 1 package is changes is not exactly fast development. But
> that just means that you Junit test your components properly, and  
> don't
> have to use the tomcat container as your test environment.
>
> Spring also comes with lots of goodies that can make life easier if  
> you
> don't overuse them. eg Declarative Proxies (transaction, method etc)
> Lazy inits
>
> So I would advocate, use it in is basic way and avoid too many of the
> confusing complex concepts, don't try and replace the ComponentManager
> until you know you absolutely have to.
>
> SpringMVC == excellent
> ----------------------
> This is a really nice Controller IMHO. It integrates well with Spring
> and leaves you free to choose your own model and view technologies.  
> Its
> very service oriented and doesn't make any demands on how you interact
> with URL's or HTTP. I think its better than struts, but thats just  
> personal.
>
> You *must* use the spring plugin for eclipse, it takes all the pain  
> out
> of writing the application context files.
>
> View technology
> ---------------
> Up to you, I like JSP, as view containers with most of the view  
> code in
> beans, eg 10 line JSP that does basic layout. There are plenty of  
> other
> alternatives. Most of the older ones demand that you extend existing
> classes which can be a pain and tie you in knots. It Antranig is
> listening he will no doubt tell you about RSF which is fast, has zero
> bindings and looks just like html. Tapestry is Ok, but has some  
> binding
> issues, the same can be said for Trails. You might also consider SAX
> based XSLT, provided the output is single stage and fast (ie not huge
> chains as is possible with Cocoon). You might also think carefully  
> about
>   pre-publishing content to an intermediary stage to keep performance
> right up. (This was the one thing that Coursework from Stanford did
> really well, it wrote its own templates greatly reducing server load)
>
> One thing with JSP,s watch out for the perm space they use, if you  
> have
> lots you will run out, and have to increase it. Also big JSPs are  
> not as
> fast as small JSPs with Beans...  and tags with lots of el lead to big
> call trees, all of which costs.
>
> Hibernate == good sometimes, bad others.
> ----------------------------------------
> Be careful with hibernate. If you want to do standard CRUD type
> operations on single records, with some lists, then its great. It also
> great an generating Schemas, provided you check what the schema really
> looks like. This aspect takes all the the pain out managing  
> multiple DB
> targets.
>
> Where it is not so great is the way it interacts with the DB. If you
> want to do anything complex (like an optimized join or a bulk update)
> then you are probably better off using Spring JDBC (which has a  
> proxy to
> make life easy). Some of the reasons are.
>
> 1. Hibernate treats the Object model as just that, as you navigate
> object relationships it will either load entire object trees from the
> db, or lazy load individual objects on demand. Each of these is an
> individual sql statement. Often a single SQL statement gets the answer
> at much lower cost.
> Simple example, delete all objects in a collection, this will  
> generate 1
> SQL delete per object where a single statement would have done the  
> trick.
>
> Hibernate 3 has a bulk update feature that is supposed to address some
> of this, but it will never beat hand coded SQL92.
>
> 2. On update, these multiple statements generate 1000's of locks in  
> the
> DB. Depending on how locking is implemented you will at some point run
> into deadlock situations, MySQL.InnoDB is more susceptible than  
> Oracle.
> For instance, 10 threads, started at the same time all trying to  
> create
> and update a single record, each with their own GUID will deadlock  
> after
> about 5 attempts. Thats not much load in real life. Oracle is a bit
> better but you *must* use high inittrans settings on the database  
> blocks
> (default=2, with hibernate ~50). Debugging is a complete  nightmare  
> when
> it happens.
>
> 3. Object staleness. Dont use pessimistic locking, Use optimistic
> locking and *dont* ever put hibernate objects into session and try and
> reattach them between request cycles, its a nightmare to get right  
> (JSF
> sort of makes you want to try this, another reason not to use JSF).
>
> You *must* use the Hibernate eclipse plugin ( Synchornise?) it  
> takes the
> hard work out of most operations
>
>
> Currently my top architecture stack would be
> --------------------------------------------
> A SOA, no/minimal in session state, no big in memory object models, no
> EJB (:)), Separation of Concerns etc etc etc
> Spring
> Hibernate for Schema
> Spring JDBC and Hibernate (for simple crud ops)
> Spring MVC for the controller
> JSP/SAX-XSLT/RSF for the view.
>
> If you are not already using
> maven
> to build (write your own jelly plugin to make it easy to get up and
> running , maven sakai builds sakai)
> keeps dependencies out of SVN and well defined (precise control over
> versions)
>
> svn for SCM
> as both of these make it much easier for a larger number of developers
> to work concurrently. (Sakai has had about 7K commits from about 50
> developers on about 100 components since 1/1/06)
>
> I think thats my 2p's worth.
> You might look a stealing/borrowing/reusing some of the framework  
> parts
> of Sakai if you are thinking in this area, have a look a mini,  
> which you
> could strip back further.
>
> https://source.sakaiproject.org/svn/sakai/branches/sakai_mini/
>
> url when your up is
> http://localhost:8080/mercury/
> user: admin, admin
>
> Ian Boston
>
> Matthew Buckett wrote:
>> John Norman wrote:
>>> Would you welcome some of my developers to share what we have  
>>> learned
>>> from our Sakai work? I can get Ian and Antranig to join the list and
>>> maybe someone from Indiana if you want to thrash out where these
>>> technologies work well and where they don't...
>>
>> Yeah I'd be interested to hear about others experience.
>>
>> Background:
>>
>> At the moment Bodington hands control straight to the template(view)
>> which then calls the business logic and renders the response.  
>> Templates
>> are like restricted JSPs.
>>
>> I wanted to move to an MVC architecture for the servlet layer as  
>> it is
>> one of the weaker areas of Bodington at the moment. Due to bodingtons
>> use of good URLs and very page orientated layout some frameworks  
>> didn't
>> get much consideration:
>>
>>      Tapestry - Bad URLs (better now), component architecture.
>>      JSF - Bad URLs, component architecture.
>>
>> An obvious candidate was struts as it is very popular (if aging)  
>> and as
>> a result most experienced Java developers will know a little about  
>> it. I
>> also had used it on a previous project. Although I got it working a
>> little I couldn't manage to get it to work well with Bodingtons tree
>> style URLs without starting to hack at struts itself.
>>
>> Next I looked at SpringMVC which is harder to get started with but  
>> much
>> more flexible. SpringMVC has a reasonable community, acceptable
>> documentation and books. SpringMVC works ok alongside Bodington so  
>> that
>> is what I have stuck with so far.
>>
>> For the presentation I used JSPs (no scriptlets) with Core, Spring  
>> and
>> Template taglibs. SpringMVC can work with XSLT, Velocity, Freemarker
>> istead of JSPs for view.