Originally posted by Jesper de Jong:
Interesting, but why did you write your own MVC framework when there are already a number of high-quality, well-known, well-tested and debugged frameworks out there like Struts, Spring MVC, WebWork, etc.?
Interesting, but why did you write your own MVC framework when there are already a number of ...
1. Is there any particular reason you use an I prefix on your Action interface? I personally find that names work best if they are 100% descriptive of their function, and 0% descriptive of their implementation.
2. defining your own "service" method is usually considered dangerous behaviour. Do you really want your Actions to respond to any old HEAD, PUT or OPTIONS request that appears at the server? Although it's clumsy, the best way is still usually to define one method (with whatever unclaimed name you like) and call it from redefined doGet and doPost methods.
3. I also worry that you have coupled your actions a bit too close to the Servlet API. My preference is to decouple knowledge of servlet API methods from the business logic as it can make unit testing your code immensely easier. This is particularly apparent where you do the request dispatching in the Action.
4. I'm puzzled by the similarity in names between IAction and the Action class which appears later. In my experience things like this quickly act to confuse developers new to the project. Can you think of a more memorable name for one of them?
5. This one is really a personal preference. Can you explain a little why you chose to use XML for your configurations in a very light-weight framework like this? All the overhead of loading and using XML processing code when the same information could easily be represented as something like a simple properties file:
Originally posted by dema rogatkin:
I like your MVC framework. I hope you will start a new project at sourceforge soon, and my company can be your first customer. I'd recommend to provide abstart classes for your interfaces to hide too much implementation details and work with simple call like display(error), display(email), and so on. Actually you have already got this recommendation.
Originally posted by rathi ji:
The reason is, we have coding standard document for our project and there I found that it is easy to identify an interface if it has prefix I.
Could you please explain this a bit "I personally find that names work best if they are 100% descriptive of their function, and 0% descriptive of their implementation" with an example if possible.
But I am not sure how HEAD, PUT or OPTION etc request will come to my server???
You mean, I am passing request and response to my doProcess() method. But I need these objects in action class.
I can think of two options:
1] Get information from request in main controller class and then pass only those infomation (in form of map) to action class instead of request. But every action class needs different informationm, so I think it is not feasible...
2] If I pass a map that has request, response and other things to action class, then also the case will be same. I can't write Junit for my action class, because I can't hardcode that map myself....
Thank a lot again. I am very glad to have such mentors.
I'm not sure I understand this. Putting some information into a Map to pass to some code is something I do every day in JUnit. Here's a short example showing how you could test something like your doProcess code without involving any of the Servlet API
But now it is clear to me, I will pass request parameters map instead of request object. But what is the need of writer object??? I think if I want to display any specific kind of error message then it is useful, I will write that into this writer.
Is this right and only use of this writer??
Originally posted by Frank Carver:
You might not even need it in your application. Or you might need a different way of passing results back from your action handler to the framework. I'm afriad I don't know much about what you want to do with these actions, and what (if any) output values they might produce, so I can't help much beyond this point.
My own framework for this sort of thing (mojasef) does something a bit more complicated, which allows the action handler to write things back into the map of parameters which are then made available to the page that is eventually displayed. Other frameworks may work differently.