Re: [Mav-user] Tagonist

2005-11-13 Thread Mikael Ståldal

On Wed, 6 Jul 2005, Jeff Schnitzer wrote:

However, over the last couple years I kept bumping into shortcomings of the 
servlet-front-controller approach taken by Maverick, Struts, WebWork, and 
friends.  Specifically:


* If you have more than a couple web developers, they bump into each other 
when editing the xml sitemap config file.

* Explaining the xml sitemap config file to nonprogrammers is unpleasant.


Those two (related) problems can be solved within the 
servlet-front-controller approach. The central sitemap config file is 
unnessecary, you can have automatic implicit mapping from request URL to 
a Java class name for the Action. The only central config you need then 
is a list of Java packages to search in. If no class is found, then a 
view can be searched for instead.


If additional configuration for a page is needed, that can be added as 
metadata to the Action class (possibly by using annotation in Java 1.5) 
and/or to the view (depending on the view technology).


This is implemented in LSP (http://sourceforge.net/projects/lspx/).


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
[INVALID FOOTER]


Re: [Mav-user] Tagonist

2005-07-06 Thread Eelco Hillenius
It is great that Maverick is 'done'. Of the model 2 frameworks, I still 
think it is the best, though WebWork and SpringMVC have some more 
features (which is not nescesarily a good thing).


I bumped into the same shortcommings and a ton more. I'd like to 
specifically add some problems I have with model 2 frameworks:
- When pages get more complex, your code will be spaghetti. No matter 
how you fix it (chaining actions, having a massive base action class or 
using utility classes all over the place), it gets to be a mess.
- The procedural nature of the servlet-front-controller pattern doesn't 
help you develop OO skills.
- No reuse. Never thought that would be a real problem, but it is. We 
had the need to develop variants of applications, where we could have 
had a large advantage when page/ panel reuse would have been possible. 
As it is not with the model 2 frameworks, you end up with a lot of code 
(and configuration!) duplication. We also see a lot code duplication for 
things like pageable lists et.
- No matter which templating technology you use, XML, JSP, or Velocity, 
webdesigners don't like it too much compared to 'just' HTML, with which 
they can use their editors of choice.


One area in which Maverick still shines, is for sites that have a XML 
backing. For that, the transformations system works great. For future 
sites with this characteristic, I'll check out Tagonist.


However, I 'moved on' too and I am currently active for component based 
framework Wicket (http://wicket.sourceforge.net). The project was 
started by Jonathan Locke, who worked on AWT and Swing for Sun and did a 
lot of good work for Java over at Microsoft. It is not as minimalistic 
as tagonist, but it's aims are to make developing web application 
easier, prettier and generally more fun without sacrificing enterprise 
needs, like scalibility etc. I just returned from JavaOne where we had a 
presentation and were part of a 'web framework smackdown' panel 
disussion. Pretty exciting for a framework that is this new (released 
1.0 just last month).


Anyway, I'd like to stress that I'm not abbandoning Maverick either (it 
helps that there is just no work to be done ofcourse), and will still 
support its WebWork-ish extension Baritus.


Good luck with your project Jeff! Regards,

Eelco Hillenius


Jeff Schnitzer wrote:

Hi everyone.  All has been pretty quiet on the Maverick front for 
quite a while, but that's not surprising - Maverick is pretty much 
"done".  However, over the last couple years I kept bumping into 
shortcomings of the servlet-front-controller approach taken by 
Maverick, Struts, WebWork, and friends.  Specifically:


* It's hard to build portals or otherwise compose pages from smaller 
bits of component functionality.
* You tend to evolve towards one Controller/Action class per screen.  
Controllers rarely get reused.
* If you have more than a couple web developers, they bump into each 
other when editing the xml sitemap config file.

* Explaining the xml sitemap config file to nonprogrammers is unpleasant.

So I started tinkering.

I started out trying to turn Maverick inside-out by creating a custom 
JSP tag that would instantiate Maverick controllers ad-hoc from within 
JSP files.  It worked reasonably well and allowed you to instantiate 
multiple controllers on a page, thus allowing each individual 
controller to have finer functional granularity.  Pages which required 
form processing went through the standard MVC pattern, but pages which 
just render data (ie most pages in most webapps) merely require a 
standard JSP with a few invocations of a custom tag - you could add 
pages without touching maverick.xml.


Still, the model wasn't a perfect fit - abusing the Maverick APIs like 
this felt clunky.  So I tinkered some more.


I ultimated ended up starting from scratch, creating Tagonist.  
Tagonist is a *lot* simpler than Maverick.  It's necessarily JSP-only, 
so you can't use Velocity or XSLT.  It doesn't (by itself) handle 
document transformations.  It doesn't have any special switching logic 
for internationalization.


What Tagonist provides is the basic MVC glue in a very compact package:

* No servlets required.  All your URLs point to plain old JSPs.
* No sitemap configuration, XML or otherwise.  In fact, there are no 
config files whatsoever.
* You can build fine-grained Action classes and compose them 
arbitrarily on a page.
* You can use Tagonist on any JSP page, even if the page is already 
part of some other framework, be it Maverick, Struts or some fancy 
portal application.  There are no integration issues.
* Tagonist is, I kid you not, less than 500 lines of code (including 
whitespace!).  The tagonist jar is 8k.


If this sparks your curiosity, look at http://tagonist.tigris.org/

I've been using Tagonist in production for about four months and I'm 
happy enough with the results that I've released the 1.0 version.  The 
tagonist distribution includes a port of the same Friendbook 
ap