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/WishList

------------------------------------------------------------------------------
+  * 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.
+ 
+  * Also it would be helpfull if OGNL-expression had access to the currently 
executing page (and component) through the OgnlContext (#page and #component)
+ 
+  * 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
+ 
+  * 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!
+   ^^ 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)
+  * 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
+  * 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 Hivemind you 
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)
+  * 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"]
   * 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.
+  * For component beans, add a set-static-property type of capability, instead 
of shoehorning in a string using an expression setter.
+  * 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.
+  * 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. 
+  * 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.
+  * 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)
  
  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.)
+ 
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to