JavaScript-less mode in Vaadin

Sergei2 · June 11, 2011, 5:26pm

Hi,

I’m developing a web app that as a side requirement has to generate a static content for old mobile devices running Win Mobile 5 and 6.

When I’m using PocketPC emulators to open the app URL, they display just a blank page.

In Eclipse I created a new Vaadin project Test1 that displays “Hello Vaadin user” at http://localhost:8080/Test1. Firefox displayed the greeting correctly.

When I tried it from the emulator with http://192.168.2.3:8080/Test1 (btw the only way I was able to run something at localhost from the emulator), it displayed a white page.

When I saved the app’s output from my desktop browser, copied it to Test1/WebContent/VAADIN/Test1.htm, and then opened http://192.168.2.3:8080/Test1/VAADIN/Test1.htm in the mobile emulator, it displayed “Hello Vaadin user” as expected.

My guess is that the old mobile’s browsers don’t fully support the JavaScripts generated by Vaadin on the client side, so my question is if it’s ever possible to turn off the JavaScript generation, so that the server side would generate only static HTML + CSS for those old fellows.

You may ask why not use just a CMS/notepad/CustomLayout for the static part, but I like the Vaadin approach of generating HTML under the hood from a composition of Java objects.

Also I would like to have the business logic + main JavaScript-enabled presentaion part implemented within Vaadin.

I was taking a look at the TouchKit, but seems it makes the JavaScript load even heavier. Though looks great on new gadgets.

So my question again is if it’s possible to turn off JS generation?

Kiitos,
Sergei

Johannes · June 12, 2011, 12:53pm

Hi Sergei, unfortunately there is (currently) no possibility to generate static html from vaadin user interface in the server side. I agree that this is something that is needed if one doesn’t want to write static jsp/html version of the existing vaadin ui for the old browsers. Typically, if this kind of old browser support is needed, one writes a text-based version of the core functionality of the web application. After that one could use e.g. servlet filters to automatically redirect all users with ancient browser into text-version of the web application.

However, it might be possible write add-on for vaadin that will do the trick. I’m not entrely sure about this but I would image that using e.g. some gui-less browser like html unit to generate the vaadin client ui in the server side and just send the html of it for the user… Well, I have to think about this more at better time.

Best regards -Johannes

Joonas · June 14, 2011, 3:23pm

Years back we had automated javascrip-less fallback mode. It used XSLT to transform UI component state to simple forms on the server-side from UIDL. The code is still out there in Vaadin 4 (then named IT Mill Toolkit), but would need porting to Vaadin 6. There is probably quite a few aspects that should be taken into account if someone tries to do that. If someone is seriously interested in porting this old feature to Vaadin 6 and releasing it as add-one, please be in touch.

Jorg2 · January 26, 2012, 11:02am

Hi,

Can this effort be resurrected somehow ? Is it something that will be easier to implement on the upcoming Vaadin 7 backend ?

I know that it might seem pointless at first to consider javascript-less mode but there are a lot of government institutions out there for which no-javascript fallback must be implemented for all public facing (i.e. non-intranet) websites. These are typically not websites with a lot of dynamic interactivity, but rather static read-only informational sites. So if we could have a degraded mode that renders plain html only, and for which perhaps even only a limited set of widgets would be available, that would be absolutely fantastic.

Thanks
Jorg

Joonas · January 26, 2012, 11:10am

No one has volunteered for that task and at the moment the core development team does not have any plans for this.

Henri · January 26, 2012, 1:19pm

Some of our projects have had this requirement, and we’ve usually solved it by creating a standalone mobile UI using JSPs. This allows you to redesign the UI to fit better to a small screen and to take into account the differences between mobile and desktop browsers (like different DOM and CSS support).

Generally the functionality required to be available in the mobile version is small subset of the full version, and it shouldn’t be too hard to implement as long as your business logic is properly isolated from the UI.

Jorg2 · January 26, 2012, 3:52pm

Thanks Joonas.

Is the UIDL->XSL approach still feasible you think ? From what i can find on the forums UIDL is Vaadin internal and not a documented xml format for people to build other gui’s with. Is it an ever evolving format or has it pretty much stabilized over the years ?

I looked at the itmil 4.1 sources and found the xsl files you mentioned before. The one below for example transforms a link. It looks as if intimate UIDL knowledge is required, without a spec it’ll be reverse engineering with a lot of trial and error. Not sure if it’s worth the effort. Transforming components might still be doable but what about the layouts?


<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="link">
  <DIV>
    <xsl:if test="@disabled='true'"><xsl:attribute name="DISABLED">true</xsl:attribute></xsl:if>
    <xsl:attribute name="CLASS">link<xsl:if test="./@style">-<xsl:value-of select="./@style"/></xsl:if></xsl:attribute>    
      <xsl:apply-templates select="." mode="core"/>
      <xsl:choose>
        <xsl:when test="$dhtml">
          <xsl:for-each select="./error"><xsl:apply-templates select="." mode="dhtml"/></xsl:for-each>
          <xsl:for-each select="./description"><xsl:apply-templates select="." mode="dhtml"/></xsl:for-each>
        </xsl:when>
        <xsl:otherwise>
          <xsl:for-each select="./error"><xsl:apply-templates select="." mode="inline"/></xsl:for-each>
          <xsl:for-each select="./description"><xsl:apply-templates select="." mode="inline"/></xsl:for-each>
        </xsl:otherwise>
      </xsl:choose>
  </DIV>
</xsl:template>

<xsl:template match="link" mode="core">
  <SPAN>
    <xsl:attribute name="CLASS">link-body<xsl:if test="./@style">-<xsl:value-of select="./@style"/></xsl:if></xsl:attribute>    
	<A>
	  <xsl:if test="not(@disabled='true')">
        <xsl:choose> 
          <xsl:when test="$dhtml and (string-length(@name) &gt; 0)">
            <xsl:attribute name="HREF">javascript:itmill.html.utils.openWindow('<xsl:value-of select="@src"
            />','<xsl:value-of select="@name"
            />',<xsl:choose><xsl:when test="@width"><xsl:value-of select="@width"/></xsl:when><xsl:otherwise>-1</xsl:otherwise></xsl:choose
            >,<xsl:choose><xsl:when test="@height"><xsl:value-of select="@height"/></xsl:when><xsl:otherwise>-1</xsl:otherwise></xsl:choose
            >,'<xsl:value-of select="@border" />');
             </xsl:attribute>
          </xsl:when>
          <xsl:otherwise>
            <xsl:attribute name="HREF"><xsl:value-of select="@src" /></xsl:attribute>
            <xsl:attribute name="TARGET"><xsl:value-of select="@name" /></xsl:attribute>
          </xsl:otherwise>
        </xsl:choose>
      </xsl:if>
      <xsl:if test="@icon"><IMG class="icon" SRC="{@icon}" /></xsl:if>
      <xsl:value-of select="@caption" />
    </A>
    </SPAN>	
</xsl:template>

</xsl:stylesheet>

Joonas · January 26, 2012, 5:07pm

You could probably hack together UIDL->XSL->HTML rendering by adopting the old non-javascript XSL:s fairly quickly. It only include support for half of the components, but one could probably add the rest of the needed components fairly easily.

Challenges would include:

Vaadin 7 will make significant changes to the UIDL rendering pipeline. It is possible that supporting Vaadin 7 might need quite a bit additional work.
Looks and responsiveness of the produced UI would be far from good.

I would consider this approach if:

This is a regulation related requirement and not actually meant to be used regularly
Your application has quite a lot of user interface and thus building and maintaining a JSP-based simplified subset UI would not be feasible
You actually must support “all” functionality of the application with non-javascript browsers even if they are not used that often

So yes, I think that this could be done.

Joonas · January 26, 2012, 5:08pm

If anyone tries to do this, it would be very interesting to hear about the results. Even better if someone could contribute this to as an add-on to directory

Jorg2 · January 27, 2012, 9:15am

Well imagine that an intranet application has a public part open to anyone where a limited set of the use cases are exposed, operating on the same business backend. So it would be regularly and heavily used. Building a jsp frontend for this would be a shame and add to the development cost of the application. We like to keep our technology stack limited (one of the reasons we chose Vaadin in the first place

One example that is often used here as a reference is google or yahoo mail, they work perfectly fine without javascript. But probably they did make the effort to build a completely separate front end.

You already mentioned before that this is not on the roadmap for Vaadin 7. Could a pro account subscriber request for this feature or it would need to be a separate ‘sponsored’ feature request ?

Jorg