Tapestry 4.1 Wish List
The intent of this document is to list the the features/annoyances that the Tapestry community cares most about. Once development begins on the followup release to 4.1 alpha this list will help define the development goals. If you know of a JIRA issue please link to it as well.
I have already started the list off with my own more obvious wants.
Better Documentation This one is pretty obvious. The current documentation covers a lot, but there are a few places with either stale/missing information that need to be filled in. It freely mixes deprecated 3.0 features in a way that's quite confusing -- these should be clearly separated, not littering the path. Furthermore, the material is organized more from the point of view of the app's architecture than from the point of view of the user: it is often necessary to skip around between several pages to gather the information for a single task. (For example: how do I build a validated field with annotations? How does one integrate Javascript?) Documentation should start by clearly describing the simplest, best way of accomplishing something, then fan out to the details. (The Hibernate docs do a better job of this; they're a good place to look for an example.)
Easier Testing There is a rather large and impressive set of very helpful testing classes that exist in Tapestry already, the only problem is that they aren't released as a library that anyone other than the Tapestry devs can use! (besides Creator) A new Tapestry testing library is already in the works here. A javascript test base has already been added to 4.1, but it is hoped that a completely seperate library can be created complete with documentation on how to do common tasks.
Default Page/JWC Files and/or Page/JWC Inheritance Often there is a need to use the exact same services/beans/etc one multiple pages. The current solution is to add them to all the page/jwc files. There should be a way to inherit another page/jwc file and/or simply import another page/jwc file's settings. (Note that this is already possible with annotations.)
Switch Default Binding for .html to ognl: Having ognl: as the default binding would be a welcome change (and improve portability from .page -> .html - this makes sense as .pages seem to be on the way out and consistency/convention is always a +).
Programatically set-up pages in service interceptors A while ago I (Mike Snare) logged this as a JIRA issue to handle the fact that I'm using interceptors for security and need a way to create callbacks. Logged as TAPESTRY-892. I hate to put it here, but I do genuinely *wish* tapestry had that feature. I (Henri Dupre) fully second this one. I wish to see a "service" level interceptor that would also give access to the page object (to be able to check for annotations). Different usages of that type of interceptor/filter are: automatic loading/unloading of hibernate objects in ASO, authentification and synchronization.
Rename the template page from *.page to *.xml or *.page.xml This feature would allow the IDE to provide some completion and validate the template
Facilitate the authentification issue Authentification is a functionality used by most of the websites. However there is no "standardised" way to deal with it. Furthermore, an easy to specify in the template an user should be logged to access this template would be welcomed as well.
A standard @Style component a la TapFX's @Style component This would improve including styling for a component. Having it rendered in the head tag, proper, would rid many a page of being loaded, then flickering/"popping" into a new style sheet, as the declaration in JS to dynamically include a style sheet is only reached after other things have been loaded. Infrastructure would need some slight modifications in the head tag. This would hopefully be a beefed up Style component, which did things like branching on evaluated values (as you might with a .script). At it's most useful, it would handle different media types and other, arbitrary kinds of branches, like ((IE < 6)+quirksmode), or user agents. ASP.NET had/has(?) agent profiles, whereby components rendered 'upstream' content, and 'downstream' content. I think the same mechanism is in place for serving WML controls vs. html controls, etc. Dojo has a conditional package mechanism where certain code is enabled based on the runtime environment present (common, browser, rhino, etc). So there's definitely precedant for this thing. The component would hopefully support both a CSS 'spec' (like .script) AND a plain old .css. I don't like having to create a .script JUST to include a .js. A standard @Style mechanism would also promote higher quality components that shipped with useful, overridable, defaults, like the list pallette component.
Could we modify @Script to accept a toggle to tell it to include .js OR .script. If it was inserting just a .js, then the parametes would be ignored, i suppose.
An easy way (flag somewhere) to show error pages for developers and for users This avoid the need to do and re-do error pages, this should be as in ASP.NET where throught a config value in an XML file you can control if you want that the error page is showed with full debug information on different levels (only web server, local network or publicly) if the access is from wider context than configured, then shows a default page with the error and some useful information (not all info that the debug shows). Or maybe could be a flag if the project is on dev or production to achieve the same effect, I believe this option is easier to develop.
Improve @PropertySelection In Tapestry 4, some components like @Foreach was updated to a much more friendlier version @For with new APIs (IPrimaryKeyConverter) and more flexible inputs parameters. In its current format, it is akward to use @PropertySelection transparently with hibernate for instance.
Make the hivedoc easier The hivedoc is a key document but for a beginner I find more than confusing: the format of the documentation needs to be documented. The meaning of "configuration point" is not obvious, also some hivemind documentation should show how to use a specific configuration point. Same for service points, the meaning of the "implementation" there is neither obvious (I'm not sure that showing the implementation is even necessary). Eventually a easier navigation (like JavaDocs) would be bonus too.
Make switching between HTTP & HTTPS easier As suggested in a recent thread, there should be a way in the page spec to mark a page as requiring http or https (http being the default). The framework should then make sure all links to that page use the proper scheme. This is in contrast to the current Tapestry way, which is for each link to specify the scheme.
Make custom Page Not Found easier Separate a NotFound.page from Exception.page, allowing a simple definition of a NotFound.page & NotFound.html in the webapp. Perhaps also make it configurable for the page to set a HTTP error code.
Aggressively reduce verbosity and repetition Page templates are very verbose compared to most other templating languages. (The default 'ognl:' binding might be a good start, but won't solve the issue by itself.) Many component bindings involve unacceptable repetition: for example, the common case of a field with a translator and validator declared in an annotation involves redundant declaration of many things (such as the type of the component) which Tapestry should be able to infer. In general, Tapestry needs a lot more of the "don't repeat yourself" attitude.
Ad-hoc / undeclared properties One of the few features of JSP I miss is the ability to declare an ad-hoc property for use as the iteration value in a loop. Tapestry requires the page to declare a property for a For's value, even if that value has no meaning outside the template.
Restart sevice to load Home page Rather than load the servlet path, make the Restart service load the Home page just like Home service does. I makes friendly URLs one bit simpler to implement.
Make components globally accessible Make it possible to get rid of component libraries, allowing easier component inheritance. Components should be identified in a global namespace, java packages are a logical choice. For example instead of framework:TextField one should use org.apache.tapestry.form.TextField. Component libraries make a component very difficult to use in another component library. Suppose that I have a custom mylibrary:CompositePanel component which references a component of the same library by SomeCustomComponent. Because SomeCustomComponent has a meaning only in the context of mylibrary, CompositePanel cannot be used in another library (for example as a base class).