Originally posted by Frank Carver:
That looks pretty straightforward.
Remember that servlets are usually instantiated by the container, not by client code. You are creating servlet instances, but never calling init(...) to set the context. So, of course, when you try and retrieve the context, it's still null. My worry is that you are never calling any of the other "lifecycle" methods, either.
I can't see any real reason for your actions to be servlets at all, though, if all you are doing is creating them and calling methods in your own code. I reckon your action class should just be a regular abstract class with a ServletContext protected member, a ServletContext constructor parameter, and an abstract process(HttpRequest, HttpResponse method). You never call the doGet and doPost methods, so you don't need them.
Does that make any sense?
I reckon your action class should just be a regular abstract class with a ServletContext protected member, a ServletContext constructor parameter,...
Originally posted by Frank Carver:
Gregg, all of your code seems a bit overcomplicated to me. What I meant by the remark about the constructor parameter was something like:
Then in the ControllerServlet:
That way you don't need any iterators or other extra code. Or have I missed what you are trying to do?
Originally posted by Kenneth Robinson:
If you don't mind me asking, why are you writing all of this code to call an Action based on a URL? Your Action class looks exactly like a Servlet with the processRequest having the Req/Res pair and you have had to write an init like method.
Originally posted by Kenneth Robinson:
If what you are trying to do is map a URL to a thing (Action), that is exactly what you get with servlets and the J2EE/war spec.
Althought it is never really advertised as a Front Controller or MVC type of 'framework', if you think about how a web container works in the J2EE world, it already takes a URL and determines which Servlet to utilize. It's 'out of the box' FC and MVC.
For Front Controller, the container is the controller that does common work (Request, Response, Context) and forwards to the correct resource (Servlet/JSP).
For MVC, use Servlets as your controller (logic only, no display) and JSP as your View (display only, no logic). Use the ServletRequest (or HttpServletRequest) and the Session and ServletContext objects as the three ways to communicate data between the Controller and View.
The main difference between STRUTS' Action and a Servlet's doGet/doPost is that STURTS Action method signature also contains an ActionForm and ActionMapping. If you don't need those, just use a Servlet.
Originally posted by Kenneth Robinson:
I guess I just disagree that Servlet's should be controllers that hand off to other non servlet classes.
When I first read Java Servlet Programming, one of the big deals about servlets was the automatic ability of the container to create one class that lived for the life of the app and handled all request for that URL. It seems that back then this was a great idea and now it is somehow regarded as wrong. I always hear the phrase 'why reinvent the wheel', but that seems like what many servlet front controllers do when it comes to mapping the 'helper classes' to a URL. I've just always believed that the Servlet was the helper class and that the determination of what servlet to call, the creation of the ServletRequest/ServletResponse pair and so on was the job of the web container, acting as the controller.
Most complex applications utilize an other layer to do the majority of the work anyway (EJBs, Business Objects, DAOs, etc...). The web portion of an app should only be a bridge to the real app.
Don't get me started about those stupid light bulbs. |