Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tapestry Wiki" for change notification.
The following page has been changed by ErikVullings: http://wiki.apache.org/tapestry/Tapestry41WishList ------------------------------------------------------------------------------ * '''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. + * '''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. + * '''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 bas ed 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. @@ -26, +26 @@ * '''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. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
