struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: [Shale] Clay
Date Sun, 09 Apr 2006 01:55:05 GMT
>From: "Gregg Bolinger" <gdboling.shale@gmail.com> 
>
> I am evaluating Shale. I realize it is a work in progress and that nothing 
> is fully finallized/stable and I expect there to be issues. I also expect 
> great things from Shale in the future and want to help track down issues for 
> development. Hence, my eval. I've got some questions about Clay... 
> 
> I have searched the mailing list archives and found psuedo answers to my 
> issues but nothing concrete. I am trying to utalize tapestry like views and 
> full HTML layout. I've read the online doc and downloaded and read the PDF 
> doc. I have also looked at the code for the Use Case Roladex which seemed 
> to just confuse me more. I know people have asked for a simpler example of 
> using Clay already, so I won't. But I would like some clarification. 
> 
> If I want to use tapestry like views and full html layout, do I need the 
> clay-template-suffix context param and do I need to map the servlet to the 
> same extension. Also the documentation shows the clay-template-suffix as 
> .clay and then the servlet mapping as .html. It states both should be the 
> same. Is HTML preferred? 
>

The default suffix for the clay html views is .html.  You can override this if you want using
the context param in the web.xml.  

<context-param>
    <param-name>
             org.apache.shale.clay.HTML_TEMPLATE_SUFFIX
    </param-name>
    <param-value>.clayh</param-value>
 </context-param>


You also need to modify the faces servlet mapping so that the suffix you choose is handled
by the faces servlet.

  <servlet-mapping>
    <servlet-name>faces</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>


> Exactly what file should I place my component declarations in and where 
> should this file reside? 
> 

The component declarations can reside under the context root or within the classpath but both
should be registered in the web.xml.

   <!-- Clay Common Configuration Resources -->
   <context-param>
      <param-name>org.apache.shale.clay.COMMON_CONFIG_FILES</param-name>
      <param-value>/WEB-INF/clay-config.xml, /WEB-INF/clay-symbols-config.xml</param-value>
   </context-param>

We borrowed the prefix of  "classpath*:" from spring to indicate the config file should be
loaded with the class loader.

   <context-param>
      <param-name>org.apache.shale.clay.COMMON_CONFIG_FILES</param-name>
      <param-value>classpath*:org/apache/shale/usecases/symbols/clay-tiles-config.xml</param-value>
   </context-param>

These files will be loaded on startup.  If you are only using full html views, you will need
to add another param
to the web.xml.  The usecase apps shows how to use three types of views in the same app (JSP,
HTML, XML).
This is probably not a normal usecase in the real world.

 <context-param>
  <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
  <param-value>.html</param-value>
 </context-param>


> For full HTML layout, do I need a JSP that pulls in the appropriate template 
> using the clay-shale taglib? 
> 

No, the shale-clay.jar has a self registering view handler that detects the suffix (.html)
defined in the web.xml.  So you don't even have to use a JSP.  There are a couple of the full
HTML rolodex examples that show this option.  The *extreme* HTML rolodex example show that
you don't have to use any XML configs.  The complete page is defined in HTML.

The fun part to the clay is that it is a component and can be used in many ways.  When used
in full html views, the clay component it the only child under the view root.  

> Is there currently any other documentation that I am not aware of concerning 
> Clay? 
> 

None that I'm aware of other than the website and the mailing list.  I think that Manning
was considering a Shale book that had a couple chapters on using Clay but I'm not sure what
the status is on that.  I've been threating to do some more of that but I'd rather contribute
other ways. 

> Thanks a bunch and I look forward to Shale's growth. 
> 

Give it a look.  You might be able to help with that growth as many cool features like symbols
came about the same way.


> Gregg Bolinger 
> 

Gary
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message