even if you have clients which uses different flavours of html/scripting language to present the content to a user this does not necesarily mean that the generated markup remains strictly under the least common denominator of markup/script capability of the client.
You might create different views for different clients. At least I understand the hide-when for mobile clients options in R6 that way.
Other option is to generate only xml views and process that with different xslt based on client type (cocoon way, afaik). But this might be slow.
@Jeff: Afaik do modern J2EE component frameworks like JSF or tapestry rely heavily on JavaScript, too. Also Websphere has its strength more as an integration plattform than as a engine for dynamic websites. If you stick with pure dynamic webpages you might get happy with Tomcat, Notes, PHP, ruby-on-rails, whatever but not necesarily Websphere.
Jake,
even if you have clients which uses different flavours of html/scripting language to present the content to a user this does not necesarily mean that the generated markup remains strictly under the least common denominator of markup/script capability of the client.
You might create different views for different clients. At least I understand the hide-when for mobile clients options in R6 that way.
Other option is to generate only xml views and process that with different xslt based on client type (cocoon way, afaik). But this might be slow.
@Jeff: Afaik do modern J2EE component frameworks like JSF or tapestry rely heavily on JavaScript, too. Also Websphere has its strength more as an integration plattform than as a engine for dynamic websites. If you stick with pure dynamic webpages you might get happy with Tomcat, Notes, PHP, ruby-on-rails, whatever but not necesarily Websphere.