Re: RE: Getting ready for Struts 2.1.1

After thinking/coding/reading for a while I think the more interesting  
task is:  Retool Appfuse to be one or more Struts2 plugins based on  
various higher level app patterns.  (Appfuse Facebook, Appfuse  
Employee DB, Appfuse Blog, Appfuse Basic LDAP, Appfuse Basic Crowd)

This all comes from the fact, that I have been wanting to refactor the  
Appfuse web layer for Struts.  One of the interesting aspects of  
Appfuse is that it works pretty much the same across all it's web  
frameworks.  It does so with some lowest common denominator  
abstractions that can be ported and look and work the same across  
frameworks.  I have picked my tool(s): Struts2 and Ruby On Rails when  
I want to pretend I am young again.   I know Spring MVC, JSF, etc but  
I have no desire to build significant apps on those platforms.  Its  
not because they suck and Struts2 rules, it is because I know Struts2  
the best, I am most efficient there and it provides everything I need  
to build great webapps (Lets not devolve to a framework debate).  So,  
I would rather have a more Struts2-specific web stack, that really  
leverages conventions born and raised there.  The nice thing about the  
Struts2 web stack is that it is complemented nicely by Appfuse's data/
service layer, since unlike Grails or Rails, Struts2 has no data or  
service layer.

So in my mind, its time to fork Appfuse for the Struts2 followers and  
try to implement the following:
* Refactored Data/Service layer
    ** Favor GenericDao + basic search functions, Add generic  
DataDictionary for managing lists of values or value/key pairs,  
Manager impl only where necessary for transactions across multiple  
DAOs, no XFire web service included, favor Hibernate
* Refactor User/Role actions to be RESTful style.  Much easier to  
follow a create/update/show/index.... set of actions/views for a User  
resource and another for Profile resource than a single method that  
tries to figure out where it was called from and what it is supposed  
to do...Let the URI and Spring Security handle that
* Basic CRUD and Parent/Child action/view patterns -- "scaffolding"
* Update the Struts2 action testing harness to use a better  
implementation that can do things like execute the interceptor stack  
or just call the method directly.
* Remove a lot of the extra weight and let users add stuff through  
tutorials or generators -- Clickstream, Reload, Cache Flush
* Create a LDAP version with modified User management actions
* Create a Crowd version with modified User management actions
* Create a "generator" so I can do appfuse:gen controller xxx and get  
xxxController (Struts2 action), show(), edit(), index(), etc methods  
and the stub view files (index.jsp, etc) in /WEB-INF/pages/xxx/.

The end result is a Struts2 plugin that provides basic Hibernate/Model  
services as well as basic security/user management infrastructure for  
Struts2-based applications.  If you were at JavaOne you would have  
seen that there is a HUGE interest in Struts2 and this would help a  
lot.  But Struts2 has its warts:  The basic "getting-started-how-to"  
space there is a little lacking.  Also, there is a lot of code churn  
and debate surrounding the REST plugin and Convention vs. Codebehind  
vs. Smart-URLs vs. Whatever Else Someone Wrote configuration  
plugins.    I like the REST plugin but its missing some important  
parts and it depends on the Codebehind plugin which is not really  
favored in the Struts2 community.  What I think all this means is that  
we do what I have done recently...design and implement your Struts2  
app RESTfully, follow conventions for configuration and when the REST  
+ Config plugin dust settles, refactor as necessary.  For example,  
UserController.index() is supposed to produce a JSON result for a  
JQuery table.  Without the plugin our URL would be http://appufse.org/admin/users/index.html 
  and with the plugin it would be {GET}http://appfuse.org/admin/ 
users.  Also, instead of configuring a JSON result in your XML for the  
action you could request a JSON implementation of the action's model,  
in this case a list of users.




On May 24, 2008, at 4:17 AM, Giovanni Azua wrote:



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...