Announcement Announcement Module
Collapse
No announcement yet.
JSP Renderer + Java DeclarativeWebScript Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JSP Renderer + Java DeclarativeWebScript

    I have a working JSP Renderer as per THIS earlier post to this forum. I also have a working Java DeclarativeWebScript modeled after the org.springframework.extensions.webeditor.webscript s.WEFApplicationGet class by Gavin Cornwell.

    What I need now is to COMBINE a JSP Renderer with a Java DeclarativeWebScript. I'm encountering a problem when I try to provide the <package> value for the DeclarativeWebScript bean declaration. Let me explain...

    The <component-type> definition for the JSP Renderer declares the path to the JSP file. This bypasses the need for any artifacts in the "webscripts" directory. Example from spring-surf-application-spring-travel:


    Code:
    <component-type>
    	<id>logout-success</id>
    	<title>Logout Success Component Type</title>
    	<description>Logout Success Component Type</description>
    
    	<!-- Define the rendering processors for this component type -->	
    	<processor mode="view">
    		<id>jsp</id>
    		<jsp-path>/WEB-INF/jsp/logout-success.jsp</jsp-path>
    	</processor>
    
    </component-type>
    The <component> element in the page definition then references the component-type-id (e.g. "logout-success"):

    Code:
    <page>
       <id>logoutSuccess</id>
       <title>logout success</title>
       <template-instance>standard</template-instance>
       <authentication>none</authentication>
       <components>
          <component>
             <region-id>body</region-id>
             <component-type-id>logout-success</component-type-id>
          </component>   
       </components>   
    </page>
    This is different from a "normal" component element in a page definition where a url to the Web Script (in the "webscript") directory is required. The logout-success component works without a reference to a Web Script. You can hit the logoutSuccess page and it runs the logout-success.jsp as expected.

    The problem surfaces when you try to associate a Java DeclarativeWebScript with the JSP Renderer (e.g. logout-success). The DeclarativeWebScript bean definition requires an "id" attribute:

    id="webscript.<packageId>.<serviceId>.<httpMethod> "

    What value do you provide for the <packageId> token? The <packageId> appears to reference within the "webscripts" directory. But the JSP Renderer (logout-success) has no artifacts under "webscripts".

    I am hoping that there is a way to combine a JSP Renderers with a Java DeclarativeWebScript. Perhaps there is a <packageId> for the JSP Renderer that I am unaware of? Or, a way to define a JSP Renderer such that it is a first class Web Script (i.e. has artifacts under the "webscripts" directory).

    Thanks,

    Bob
    Last edited by BoJo; Sep 12th, 2010, 07:54 PM.

  • #2
    proposed implementation?

    Here are my thoughts after trying to combine a JSP Renderer and a Java DeclarativeWebScript. Hopefully, there is already an easy solution (that I am not aware of) in place. If not, then here is how I am thinking I should be able to combine the two:

    A) Ideally, I'd like to simply place a JSP Renderer (.jsp file) in the directory for the webscript just as I can with the Freemarker (.ftl) file.

    B) If JSPs must be linked in via the <processor> element, then I think what is needed is the ability to declare the processor for the view in the <component> declaration, not just the <component-type>. The proposition is that if you declare both:

    1) the <processor mode="view">
    2) the <url> of the webscript

    The webscripts extension would use the Renderer declared in #1 when executing the webscript in #2. Specifically, it would not look for Freemarker (.ftl) file in the webscript directory.

    Example:
    Code:
    <page>
       <id>logoutSuccess</id>
       <title>logout success</title>
       <template-instance>standard</template-instance>
       <authentication>none</authentication>
       <components>
          <component>
             <region-id>body</region-id>
             <!-- #2) = define webscript URL
            <url>scripts/logout</url>
      	<!-- #)1 = Define the rendering processors for this component -->	
    	<processor mode="view">
    		<id>jsp</id>
    		<jsp-path>/WEB-INF/jsp/logout-success.jsp</jsp-path>
    	</processor>
          </component>   
       </components>   
    </page>

    Given either A or B, I could then bind (via the bean declaration) a DeclarativeWebScript to the path to the "logout" implementation under /webscripts?

    Thanks,

    Bob
    Last edited by BoJo; Sep 12th, 2010, 07:55 PM.

    Comment


    • #3
      Hi Bob,

      I just want to clarify what you're requesting as I don't believe that it's actually possible. I think you're asking that you'd like to change the WebScript rendering engine from using FreeMarker to using JSP ? If so, then that is not actually possible.

      When specifying a component type you have the choice of 3 provided processors which you select using the "id" element, you can choose "jsp", "webtemplate" (which uses the Freemarker processor) or "webscript".

      If you choose "webscript" then the web script processor will be invoked which always uses Freemarker to render its output.

      Currently it's not possible to change the processing engine that WebScript provides.

      Of course it is possible to provide your own component processor... if you register a Spring bean with the id "webframework.rendition.processor.<my processor>" and then use "<my processor>" as the value of the "id" element in the <processor> element then you can extend the existing code to provide a processor that does whatever you'd like.

      It's possible that cause of this confusion is that for the "webtemplate" and "jsp" processors you also need to register the path to the .ftl and .jsp files, whereas when using the "webscript" processor it just looks up the registered "webscript" and uses its URL (which does not map to a real resource).

      I hope that makes sense,

      Regards,
      Dave

      Comment


      • #4
        Acknowledge JSP not supported

        Dave,

        Thanks for the reply. We will adjust our implementation accordingly.

        To clarify the point, I am not asking to "change the WebScript rendering engine from using FreeMarker to using JSP" Rather to abstract the WebScript rendering engine to dynamically allow for plug-in implementations of the rendering software. FreeMarker would be the default. JSP and other can be configured.

        I thought this was possible after reading a couple statements on this point:

        From http://www.springsurf.org/sites/1.0....eginning.html:

        A Surf page object has a required field for template instance therefore the Surf dispatcher knows which template to use to render view for the page. Other types of templates that Surf supports are JSP and Webscript.
        From http://wiki.alfresco.com/wiki/Surf:

        Develop views using best-of-breed scripting technologies including Freemarker, Groovy, PHP and server-side Javascript.
        By "template" above, I was thinking "template engine", such as FreeMarker. The idea being that we are simply creating a model and passing it to a template technology for rendering. in the case of JSP, you could simply put the "model" Map object in request scope.

        I misunderstood. However, it would be nice if multiple rendering technologies were supported.

        Regards,

        Bob

        Comment


        • #5
          Hi Bob,

          Extending WebScript to support other rendering engines could be something worth investigating... out of interest, what particular features of JSP would you be hoping to leverage that aren't available in FreeMarker?

          Regarding the quotes... both relate to Surf, rather than WebScript. Surf does support multiple rendering technologies (of which WebScript is one) but WebScript just supports FreeMarker.

          Regards,
          Dave

          Comment


          • #6
            Yes what David says is correct - WebScripts can be considering "just another rendering mechanism" for Surf. And Surf supports the following to render component output; WebScripts, plain FreeMarker, Java POJO and JSP. Adding JSP as a templating mechanism for WebScripts could in theory be done, but hasn't yet.

            Thanks,

            Kev

            Comment

            Working...
            X