tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tapestry-...@jakarta.apache.org
Subject [Jakarta Tapestry Wiki] Updated: WishList
Date Sun, 12 Dec 2004 17:05:47 GMT
   Date: 2004-12-12T09:05:47
   Editor: HowardLewisShip <hlship@apache.org>
   Wiki: Jakarta Tapestry Wiki
   Page: WishList
   URL: http://wiki.apache.org/jakarta-tapestry/WishList

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,13 +1,26 @@
  * 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="id@CopyOf" 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)
+
+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
@@ -18,29 +31,49 @@
 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
+    {{{ 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)
+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.
  * 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
 
 Many of these wishes are already being acted upon, see ["Tapestry31"].
 

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message