tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-tapestry Wiki] Update of "WishList" by HenriDupre
Date Wed, 06 Apr 2005 18:23:11 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-tapestry Wiki" for change

The following page has been changed by HenriDupre:

+ HenriDupre: 
+  * A little detail I'd like to see changed in Tapestry 3.1 (now 4 it seems) 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!
@@ -54, +58 @@

   * 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).
@@ -61, +67 @@

  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
@@ -106, +114 @@

   * 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
   * 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
View raw message