Alot would depend on what you want and how you decide to do it. I'm not sure that it's even worthwhile at this stage in the evolution of the web to generalise.
One issue that I'm looking at as a problem is where to switch between modules, e.g. one for state-of-art HTML with accessibility for the blind and one for 20th Century browsers. I mean, would you want both to have the same URL for the sake of search engines and reference?
It's a big question. You would keep the switch mechanism in the view, right? Perhaps with a filter, or with switches in tiles layout JSPs or definitions?
On 11/16/2004 02:57 PM Dakota Jack wrote:
Hello, Adam,
You are definitely right that this is a crucial part of any web application, and not only for browsers but also for flash, javascript, etc. versions. This is so important in the overall picture for web programming that perhaps a whole separate set of interfaces amounting to a separate "module" or "component" should be developed in a pluggable way. This sort of functionality would seem to be best utilized in something like a filter. What do you think? Even though my emphasis is on functionality and separation of concerns, I am definitely putting this on the TODO list. Thanks.
Jack
On Tue, 16 Nov 2004 10:17:23 +0000, Adam Hardy <[EMAIL PROTECTED]> wrote:
Jack, one thing you missed off the diagram is the HTML reader. A public website often has to cater for:
- old browsers like Netscape 4 - text only browsers like lynx - PDA browsers with no javascript etc - spiders which ignore sessions - screen readers for the blind
all of which make strong demands on the view and often require extra output from the model.
Adam
On 11/15/2004 07:46 PM Dakota Jack wrote:
The whole discussion about MVC and web frameworks is important, I think, because not many cash it out when to do so (cash it out) would be helpful for discussion. We might try some way of refering to this such as WEBMVC. Anyway, the MVC pattern, taken literally, is impossible in a web framework. What is possible is something like the following where the arrows indicate where there is a coupling:
View <==> Controller <==> Model
Here the Model and the View are completely decoupled. But, even this is almost a total representation of what is really going on. What is really going on is that the response object is ultimately HTML and that the JSP pages are part of creating the response object, so that JSP pages inherently provide a smart-serverside View. This all is not simple to cash out. I have a sample beginning of cashing this out at http://131.191.32.112:8080/ , which, if others want to provide alternative way of viewing this I will show them all. The most important thing, I think, is to distinguish between the View data and the Model data. That is the distinction, I think, that Craig makes in JSTL between iteration and sql statements in JSP.
Jack
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
