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 ------------------------------------------------------------------------------ * '''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 to 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 r untime 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. + * '''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. * '''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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
