WARNING: This is outdated content, kept for historical reasons

Eirik: I'd like to have "web pages" and "controllers" in normal jar projects, so they can be re-used in a number of web applications (war modules) without all that war overlay stuff. That means it must be possible to trigger tapestry loading and request processing (for unit testing) from normal classpath elements without requiring web.xml and the webapp / WEB-INF directories. We write a lot of batch processing stuff in java, deployed as web applications that has web pages for "switches" and "adjustment wheels" only, and it would be really usefull to be able to locate the user interface in the same module as the logic and domain objects it is controlling. Also, it would be simpler to package and deploy http/html-interfaced applications as normal main-method applications with a bundled http library, instead of that awkward appserver integration xml mess.

Toby:

There should be a way in Tapestry5 to create input fields dynamically, e.g. by reading the configuration from a database in order to achieve dynamic input fields.

An example of a data model that would allow this is here:

Category

ID

Name

1

Country

2

Language

Value

|| ID ||Name || Category_fid

1

USA

1

2

UK

1

3

Spain

1

4

English

2

5

Spanish

2

FormElement

ID

NAME

Category_FID

MINOCCURS

MAXOCCURS

1

ResidentCountry

1

1

1

2

CountryOfOrigin

1

1

1

3

TravelDestinatiopns

1

0

10

4

SpokenLanguages

1

1

10

Form

ID

NAME

1

UserRegistration

FormFields

ID

FORM_FID

FORMELEMENT_FID

1

1

1

2

1

2

3

1

3

RichardL:

HenriDupre:

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:

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"); 
   }

HowardLewisShip: Interesting idea, been thinking in terms of how to have many different visits, 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).

HowardLewisShip: The root context is the component (i.e., it is #this) and the page is always accessible as the page property.

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.

HowardLewisShip: I've been thinking that Tapestry should quietly clone a duplicated component, rather than mark it as an error.

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).

SteveGibson: Is this difficult - FrequentlyAskedQuestions/LogoutLink

HenriDupre: It would be really nice to see Spring Web Flow integrated with 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 }}}

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.

HowardLewisShip: See FriendlyUrls

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).

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.

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).

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).

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:

Debug to IDE support:

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.

WishList (last edited 2010-12-31 15:53:17 by BobHarner)