OK, this is a serious question (not trolling here).
- Posted by: red letters
- Posted on: December 05 2003 21:43 EST
Total separation of presentation and business logic.
Simple to code.
Looks great, runs fast.
Drive the whole thing using REST.
- Frameworks - there's a better way by Paul Strack on December 06 2003 00:13 EST
- Frameworks - there's a better way by Kris Thompson on December 06 2003 09:02 EST
- OK - Found the answer by red letters on December 06 2003 19:46 EST
I am not sure DHTML and a good server-side framework are incompatible. After all, are you going to crank out all the server-side XML processing logic by hand in servlets? A server-side web framework (Struts, WebWork, whatever) will make that logic much easier.
Some other things to consider:
2) Errors: A server-side framework will provide a better mechanism for handling system errors in a consistent way.
I don't see DHTML vs. Web Framework as an either-or question.
I don't understand what you mean by 'crank out all that server-side process.. etc. by hand'
The REST architecture process maps directly into each business process area. It's a hard concept to grasp but once you do you can see that a lot of what a framework provides is no longer needed once you make a clean break of the client from the server.
Take a look at this:
The choice to use a framework and which one to use depends mainly on the project you are going to build. If the site is a simple brochure site then you can get away with nothing anything more advanced then you are walking in thin ice.
If you and your team are very talented I'm sure you can either build your own framework or just work without one. My ownly concern if I were your boss is, what happens when you leave? My guess is the new team will complain that this code is jacked and they have no clue how to debug, upgrade, and maintain it, but that again depends on the skills on the new comers.
Frameworks can slow one down in while trying to learn it but after you feel comfortable with it I can't see any reason not to use one. Maybe if you have played around with them and they didn't seem to fit your problem you were trying to solve then maybe you choose the wrong framework to use. There are over 34+ J2EE frameworks out there and if the standard one didn't work for you (and one size does not fit all) then I would understand your frustration or lack of interest in using one. That is part of the reason why there are 34+ frameworks out there in the first place.
Actually the code would be easier to maintain because (again) the client code is completely separate from the server side processing.
It also allows the server to act as a living system able to interface with any type of client (VB, VC, Java, browser, PDA). It doesn't matter because the server controls security, access and most importantly bis logic. It has no clue whatsoever what the client is/does/or looks like.
For me thats the central issue that I have with current web frameworks. They all manage the client code directly. A true ee server should not be controlling the client or dictating what it looks like.
OK, I found the answer right here:
They use Flex for the front-end but the concept is the same. Much better client experience.