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 NickWestgate: http://wiki.apache.org/tapestry/WishList ------------------------------------------------------------------------------ + RichardL: + Is there any chance that a dynamic block component similar to the one at http://www.behindthesite.com/blog/C1931765677/E1630021481/ could added to the contrib library in Picasso please? Dynamic blocks add a huge amount of power and flexibility to Tapestry because far more complex page logic can be expressed more clearly and efficiently with OGNL (or, indeed with Java via an OGNL call) than with the built in blocks, render blocks and conditional components. I have a dynamic block component implementation that I could probably donate (subject to clearance from my employer) that is a bit more functional than the one mentioned above (it's a similar implementation but it supports default parameter values in dynamic components and allows dynamic components to be referenced by direct links along with some other enhancements). Unfortunately, because dynamic blocks need to use the internals of Tapestry to function, the implementation is quite sensitive to changes to the Tapestr y framework so it would be much better if a dynamic block could become a part of Tapestry, along with an associated set of unit tests. + + HenriDupre: + * A little detail I'd like to see changed in Tapestry Picasso (will be 3.1 or 4.0) is the order of DataSqueezers registration in the framework. To integrate hibernate objects into the squeezer today, you need to create a superclass for all the hibernate objects (because the defaults types are registered before user types) and this makes impossible to use an interface for all the hibernate objects instead of a superclass. + * Something that is really bugging me with Tapestry 3 is the callback methods on the page for loading data. If you have a property in a page that needs data to be loaded into it, today the most obvious place is to write that at pageBeginRender. But this gets really weird with the rewinding because pageBeginRender gets called twice, so you have to add somekind of check if (getMyProperty() == null) then { //load data }. Also with the rewinding, you must be careful not to rely on any properties because they won't be loaded at the first run. That was really difficult to understand when I started with Tapestry. I think it would be much better to have specific interfaces: for instance, "initProperties(IRequestCycle cycle)" called once for every page after the @Hidden fields in a form are processed. + + ThijsSuijten: Wouldn't it be nice to once and forever get rid of "back" "forward" and "refresh" hell while developing a web application? + + I've been reading the following article that provides an easy but effective solution for the back/foward/refresh problem. It would be VERY nice if this solution could be implemented in Tapestry Framework to get rid of the back/foward/refresh problem forever! + + http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost + + I already use the "form submit synchronization token", sure it solves the unsynchronized state of my application but it doesn't work intuitively for our users. I even (who build the web application) sometimes accidentally press the back button... + + I think the there are two options: + + * Redirect immediately: in the RedirectService (something like DirectService) a redirect immediately takes place and all parameters must be copied into the session Object, the service which is redirected to must read and discard these session parameters and rewind the request. + + * Redirect formSubmit: The rewind cycle takes place as usual, at the end of the rewind phase a redirect is triggered. No parameters have to be stored in the session Object because the rewind phase was responsible for processing/persisting the parameters. + + The second option can already be used manually to realize the PRG pattern. For example: + + {{{ + public void submitForm(IRequestCycle cycle) { + PageService s = new PageService(); + String redirect = s.getLink(cycle, this, new Object[]{"GetPage1"}).getURL(); + throw new RedirectException(redirect); + } + }}} + + Instead of: + + {{{ + public void submitForm(IRequestCycle cycle) { + cycle.activate("GetPage1"); + } + }}} + + * Add support for components that use XMLHttpRequest. XMLHttpRequest (or something similar) is supported by Microsoft, Mozilla, Safari, and Opera. Basically, Javascript can request information from the server and update a portion of a page rather then refreshing the whole page. An example of a component that could benefit from this would be a derivative of the DatePicker component that could be used for scheduling appointments. As the user selects a month, the "already reserved slots" could be retrieved from the server to update the component. While it is not strictly necessary for Tapestry to govern the conversation between the component and the server, there are many benefits in doing so. For example, if the client's browser does not support XMLHttpRequest it will be necessary to refresh the entire page, and Tapestry would definitely handle that task. + + * How about a Tapestry Context? I've built one for our projects, it sets the Visit into ThreadLocal. This way, helper classes don't have to pass around the Visit. The extended BasePage implements IPageListener and sets (and unsets) the Visit. Classes that control web flow can grab it themselves. You could also put HttpRequest in it for implementing Portal support (this was mentioned in HLS's post as problematic). Probably all of a 30 minute job. + + HowardLewisShip: Interesting idea, been thinking in terms of how to have many different ''visit''s, with varying names, scopes, lifecycles, creation strategies, and have ways to ''inject'' them effeciently into Tapestry pages and components (and perhaps even into HiveMind services). + + * Also it would be helpfull if OGNL-expression had access to the currently executing page (and component) through the OgnlContext (#page and #component) + + HowardLewisShip: The root context is the component (i.e., it is #this) and the page is always accessible as the page property. + + * Imply java.lang and java.util for 'type' in 'property-specification' elements in *.page. eg: if i use 'String' for type, i'd expect it to assume i mean 'java.lang.String' - ps + + HowardLewisShip: How about dropping the type attribute from <property-specification> entirely? That's what's happened (its also now called <property>). The type matches the type defined by abstract accessor methods, or simply java.lang.Object if not accessors. + + * A supported tag in the html, jwcid="[EMAIL PROTECTED]" would be nice. We put all component definitions in our .page files (as everyone should) to separate HTML development from Java development. However, we typically need at least a couple of copies of links etc., and having such a tag would be much cleaner than all the alias components that blindly make more ids with a number tacked on the end! + + HowardLewisShip: I've been thinking that Tapestry should quietly clone a duplicated component, rather than mark it as an error. + + ^^ my vote goes here. the restriction of not being able to reuse component instances encourages people to define components in the html - ps + + * Make Tapestry pages somehow "compileable", adding support for this for ANT and so on. I'm going to make Ognl 3.0 generate java code (Dmitriy Kiriy, KiriyDmitriy at yandex.ru) + + HenriDupre: I don't think code generation is not a good idea for Ognl 3.0. This would make the whole process of deploying any ognl based application quite complex. Can't you achieve the same goals using bytecode generation? + + HowardLewisShip: Is runtime performance an issue? I would like to see an Ant task that can do better build-time checking, in the same way that Spindle does build-time checking. + In terms of overall performance ... I just don't know that that is an issue. First, OGNL is getting faster. Second, Tapestry 3.1 is providing non-OGNL ways to do things that require OGNL today (such as asset:foo instead of ognl:components.foo, listener:foo instead of ognl:listeners.foo) ... these new binding prefixes don't rely on reflection. Third, the new bytecode enhancement for component parameters is not only easier, but more efficient than 3.0. I try to give back when taking away ... for all that Tapestry 3.1 is more complex under the covers than 3.0, I think applications ported from 3.0 to 3.1 will be at least as fast, if not faster (if they take advantage of the new features). + + * Better/easier support for invalidating session commonly needed for log out action. Or at least some method for reinstantiation of visit object and forgetting all pages. + SteveGibson: Is this difficult - ["FrequentlyAskedQuestions/LogoutLink"] + * Add a way to prevent double click similar to Struts token + * Support web flows + HenriDupre: It would be really nice to see Spring Web Flow integrated with Tapestry. + + * Support web continuations + {{{I don't see this as a feature of Tapestry. + Once 3.1 comes along with Hivemind services you could create a service that + enabled continations by using one of the libraries out there that support this. + Like rife, pico threads, or ATCT (commercial)- Geoff }}} + {{{Are you sure? I guess it isn't possible without a complete support by Tapestry framework}}} + {{{ The cool thing is that once Tapestry is integrated with HiveMindyou can add services with all kinds + of interesting functionality, like continuations or Spring-like transaction support. + In fact I believe that the current Tapestry services themselves (like Asset, Action, Page, etc) are + going to become Hivemind services. }}} + + (- Why not Spring support as well - Joel) + + HowardLewisShip: HiveMind will be able to treat Spring beans as HiveMind services easy enough; you will be able to implement these things in Spring, but you'll be hampered unless the Spring team provides some better integration with HiveMind. Basically, engine services need to be ''injected'' with other services to control error reporting, page rendering, and link generation. About continuations: that would be very cool, but I'm not sure what it would look like. + + * Add runtime exception logging through commons-logging *along* with displaying them on Exception page. Exception page is nice during development, but insufficient for deployment since I cannot go through let's say file logs and see what happened badly yesterday. This additional logging should not be performed inside default exception page class, since user could specify his own exception page and forget to implement logging inside new class. + (Note by Joel: We used a production page with a hidden link to reveal the error message, Tapestry doesn't need to be extended for this) + * Add skinning functionality (add skin string to html search, i.e. file_skin_EN_US.html) + (- This was discussed on the forum, skinning would be great (and relatively easy to add I would think), but this probably isn't the best way to go about it. - Joel) * Listener methods that take actual typed parameters rather than having to pull them from service parameters * Cleaner URL's, to really help with ["J2EESecurity"] + + HowardLewisShip: See FriendlyUrls + * Easier testability of Tapestry pages/components + - Static validation would be nice. * Fix for security hole in asset service * Allow simpler validation - for example, bypass invoking listener method and return to same page if validation errors occur * Better support for hot deploy, allowing new page and component templates/specifications to be picked up at runtime. WebOGNL has a timestamp dependency check, which would be nice to borrow from. * Let the component user be able to set the template for the component just as easily as set a paramemter. + + HowardLewisShip: Not likely soon, because of how page and component templates get integrated together. This represents a dramatic change to Tapestry and introduces some complex issue. Further, a component's template is part of its ''implementation'', which should be kept private (and therefore, not easy to override from outside the component). + * For component beans, add a set-static-property type of capability, instead of shoehorning in a string using an expression setter. + + HowardLewisShip: This is coming; basically, you'll use binding prefixes when setting properties of beans, so you'll be able to use ognl:, message:, component:, asset:, etc. + * Unified the way to process validation, make all form components support displayName property and be able to support validator. Let the FieldLabel highlight the label automatically when the field is required. * It would be great if there was a way to carry through form parameters. Say I have pages A and B. B is a general purpose page used to lookup information. It should be possible to navigate from A to B back to A and keep the form parameters of that were set in A. At the moment you would need to make B record the values in hidden fields then submit them back to A or use persistent properties. It would be great to be able to automatically pass these parameters along without making B explicitly aware of A's parameters since B might be used in other contexts. Hope that makes sense. It's hard to explain. + HowardLewisShip: If those properties editted on page A are persistent, then they will be the defaults when you return. Or, you can store (or compute) the defaults in some other way, and simply set those properties before activating the page (i.e., the "back to previous page" link should be a !DirectLink, not a !PageLink, and you should restore the properties inside the listener method). + + * Allow use of "id" attribute instead of "jwcid", so that templates are truly pure HTML. Perhaps even make the scheme for tagging the binding name flexible. + {{{ This would be problematic for template designers using CSS I would think. -- Kevin}}} + * The biggest issue I have had (and have seen a lot others have) is with pleasing the rewind cycle. The rewind has to be completely transparent which means we should by default make all form elements serialize their state in hidden fields and allow the user to opt out. + HenriDupre: I think that all the form components (e.g. ListEdit and others) do quite well the job. I have pages where I don't want all the state to be serialized (I have large select lists). + * Get ride of page specifications - I've got 13 pages, all listed in App.application, all with Page.page files with just one line: <page-specification class="app.Page"/>. Perhaps I use anonymous components too much, and page-specifications would be needed for more complex pages, but it'd be great for trivial pages not to have to jump through these hoops and instead get auto-looked up by package (e.g. put app.pages.* in App.application as an auto-lookup package) + + HowardLewisShip: The page specification is optional, any HTML template in the context is considered a page, and uses org.apache.tapestry.!BasePage. You can override the default page class + with the org.apache.tapestry.default-page-class configuration property, see http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/configuration.search-path.html + + JacobRobertson: How about instead, allow us to put the class information into the application file. For example + <page name="Home" page-specification-class="com.package.!HomePage"/>. I could see this being confusing to beginners, but it would avoid maintaining unneeded files. + Many of these wishes are already being acted upon, see ["Tapestry31"]. + Web Services: + * Make Tapestry a Service End Point for Web Services (implement ServletEndpointContext). Mimic the WSDP's JAXRPCServlet? + + Debug to IDE support: + *Have been doing some experimentation with generating exception pages that link back to Spindle in Eclipse. The approach is generic and not tied to Eclipse. Success has been had with linking stack trace entries to java editors. The Wish is: Rework the exception page with two (overridable) components. One that renders stack traces and one that renders ILocations. That way a debug friendly Exception page can be created that will render the info above as links. + + + John Hyland-- + + I wrote on the old wiki TapestryAsRAD page and was told to contribute something here so I chose this wishlist: + + Tapestry (with other framework components) as a UI framework component I think is furthest along towards making a RAD. Even a web based wizard RAD tool given that Tapestry has such standard widgets. An XML application definition file is a good idea. You *could* also use a special schema in the database as a "application definition dictionary". This would afford some niceties as well. I think a basic "CRUD" database editing, intuitive application creating RAD is a good first step towards possibly some more "applicationesque" additions like menus, role-privilege access and "flows". Perhaps a scheduler service and a way to interact with it in the RAD later on would be really nice. + + Basically, my wish is for Tapestry to have a kind of RAD war application so that simple database editing applications can be created very quickly. (getting rid of excessive specifications like the page specification is a good simplification that can be used.) + + ChrisNelson: The Trails project, http://trails.dev.java.net is doing something quite similar to this. Trails will provide a web application to interact with RDBMS persisted objects automagically using Tapestry, Hibernate, and Spring. + + * I didn't know where else to put this - but why doesn't Tapestry have an "official" forum? It would be nice to be able to have one place on the web to go and ask questions, read through other people's questions and answers, etc. A wiki isn't a forum, and it shouldn't try to be one. Loook how nice (for example), the official spring forum is - http://forum.springframework.org + -- JacobRobertson + + * Allow us to put our html pages in directory structures instead of the root. If you have a large application, you might want to organize them, or at the very least keep them in a parallel folder to your pages. For example, under WEB-INF you might have components, pages, and templates directories. -- JacobRobertson + + * Skinning, and swapping out component template are mentioned above, and I want to add my vote for allowing a complete decoupling of the layout for pages and components. We have customers that want our application "branded" to a very precise look and feel. This means that when two different users hit the application, a completely different page layout is used to render the exact same content. This can be taken down to the component level. We are currently using a home-grown Web UI framework to do this, and it is important functionality for us. -- JacobRobertson + + * The ability to set a parameter such as "location" for <include-script>. It would default to "body" but you could set it to "head". That way when you need to have javascript called in the header and not in the body you dont have to go the whole shell delegate route. Also this would make components that use the javascript work without having to create a Shell delegate for the page. - ChrisYates + + * Some JavaScripts rely on relative positioning. For example it will insert a DHTML menu into the page where the <script src="menu.js"> is called. Currently any <include-script> calls put the <script> tag's just below <body>. It would be better if they were inserted the same place the Script component is called. - ChrisYates + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
