Raible's Wiki

Raible Designs
Wiki Home
News
Recent Changes

AppFuse

Homepage
  - Korean
  - Chinese
  - Italian
  - Japanese

QuickStart Guide
  - Chinese
  - French
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish
  - Japanese

User Guide
  - Korean
  - Chinese

Tutorials
  - Chinese
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish

FAQ
  - Korean

Latest Downloads

Other Applications

Struts Resume
Security Example
Struts Menu

Set your name in
UserPreferences


Referenced by
AppFuse
AppFuse_it
AppFuse_jp
AppFuse_ko
AppFuse_zh




JSPWiki v2.2.33

[RSS]


Hide Menu

AppFuseRoadmap


This is version 9. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]


This page is designed to document the things I want to do with AppFuse in 2004. Feel free to add suggestions as you see fit.

Spring 2004

  • Implement Charle's persistent cookie strategy
  • Migrate to Ant 1.6 and Tomcat 5.x as primary testing targets, but don't go to JSP 2.0 (yet).
  • Tie Managers to ManagerImpls using Spring. Possibly use Spring for some Hibernate enhancements and to tie DAOs to Impls as well.
  • Re-arrange directory structure to be more inline with a 3-tiered architecture. Read More...
  • Add support for iBatis as a database layer choice.

Summer/Fall 2004

  • Add WebWork as a web framework choice
  • Add Tapestry as a web framework choice
  • Figure out how to use Mocks to create faster unit tests, rather than just integrations tests (which is what exists now)
  • (Possibly) Add JSF as a web framework choice
  • (Possibly) Add a Swing client that can talk to at least one of the above frameworks (if not all)

Thinking Out Loud: The hard part about adding "choices" for the user is that the CVS checkout becomes bloated and there are two many decisions. I'd like to figure out a way (hopefully using CVS) to allow a "default" version of AppFuse and then an AppFuse-WW, AppFuse-iBatis, etc. That's going to be tough to do because a lot of classpath's are going to change based on the implementation. It might be easier to simply start a new branch, but there's probably going to be a LOT of duplication between build files libraries. Maybe I can just split off the "lib" directory into another branch, and allow that to be download separately based on dependencies needed. Who knows. Is this something that Maven could make easier? I'd hate to get away from Ant, especially since I'm very comfortable with how everything works now.

Proposed Solution: I think the easiest way to handle the various "options" is to have them as a separate download and CVS module. Then I'll use ant in these modules to rip out and replace the core stuff with the module-specific stuff.



Go to top   More info...   Attach file...
This particular version was published on 06-Nov-2006 13:52:25 MST by MattRaible.