A recent check in allows page templates to be stored in the web application root, much like they are in Tapestry 4.
To do this required a very ugly hack. Tapestry 5 acts as a servlet filter (not a servlet, as in Tapestry 4). Normally, requests for real resources are simply passed through to the default handler. I had to explicity check for a ".html" extension, and pass that on through to the rest of Tapestry's code path, because templates have a ".html" extension. This causes a couple of issues; for instance, eventually I want to have the template extension be configurable (this is possible in T4) which makes sense if some "pages" are really SVG or CSS or something else. It also causes a problem for static HTML files; they are now treated as if they were Tapestry pages, and an error ensues when the page class is not found. Perhaps these could be addessed by adding more kludges. I propose moving page templates to WEB-INF. So they can be on the class path, with the corresponding Java class, or in WEB-INF. This causes an issue with WYSIWYG preview, because the path to static assets will be somewhat off. However, for any page that makes use of onPassivate/onActivate (a mechanism where by additional information, typically entity object primary keys, can be encoded as additional path information), the page's base href will also be off. In other words, paths to static resources should be complete (leading slash and context name) to be assured that they work correctly. Anyway, how do people feel about this? -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
