Very interesting stuff, Adam. Very interesting! I do not see the filter as determining what the view would be but merely as providing data that would become part of the workflow as kept in the View Stores. The view would decide on what it wanted to do about this information in terms of presentation, if anything.
I think that the "switch" has to be in the controller. The determination of how to respond to user input is with the controller. However, the view still would have the request for the "switch". The controller has to keep control of this because there may be things affecting the "switch" such as system capabilities that are beyond the view's knowledge. There would be no good reason I can think of to leave the choice of the "switch" as opposed to the request for a "switch" in the hands of the view. I am not well-versed in the differing browser response issues. Can you expand on what the standard wisdom would be? Very interesting stuff! Jack On Tue, 16 Nov 2004 17:00:48 +0000, Adam Hardy <[EMAIL PROTECTED]> wrote: > Using filters and different modules for delivering different HTML for > different browsers is known in the HTML/CSS world as browser sniffing, > and is frowned on by the HTML designer purists, but in the real world > such modules could definitely be a highly attractive. > > 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] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
