tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Tapestry Wiki] Update of "Tapestry41WishList" by BobHarner
Date Fri, 11 Nov 2016 22:09:18 GMT
Dear wiki user,

You have subscribed to a wiki page "Tapestry Wiki" for change notification.

The page "Tapestry41WishList" has been deleted by BobHarner:

https://wiki.apache.org/tapestry/Tapestry41WishList?action=diff&rev1=38&rev2=39

Comment:
Deleting old content no longer having any value

  
- || NOTE: This is outdated information that applies only to Tapestry 4.1. ||
- 
- == Tapestry 4.1 Wish List ==
- The intent of this document is to list the the features/annoyances that the Tapestry community
cares most about. Once development begins on the followup release to 4.1 alpha this list will
help define the development goals. If you know of a JIRA issue please link to it as well.
- 
- I have already started the list off with my own more obvious wants.
- 
- -----
- 
-  * '''Better Documentation''' This one is pretty obvious. The current documentation covers
a lot, but there are a few places with either stale/missing information that need to be filled
in. It freely mixes deprecated 3.0 features in a way that's quite confusing -- these should
be clearly separated, not littering the path. Furthermore, the material is organized more
from the point of view of the app's architecture than from the point of view of the user:
it is often necessary to skip around between several pages to gather the information for a
single task. (For example: how do I build a validated field with annotations? How does one
integrate Javascript?) Documentation should start by clearly describing the simplest, best
way of accomplishing something, then fan out to the details. (The Hibernate docs do a better
job of this; they're a good place to look for an example.)
-  * '''Easier Testing''' There is a rather large and impressive set of very helpful testing
classes that exist in Tapestry already, the only problem is that they aren't released as a
library that anyone other than the Tapestry devs can use! (besides Creator) A new Tapestry
testing library is already in the works [[http://howardlewisship.com/tapestry-javaforge/tapestry-testng/|here]].
A javascript test base has already been added to 4.1, but it is hoped that a completely seperate
library can be created complete with documentation on how to do common tasks.
-  * '''Default Page/JWC Files and/or Page/JWC Inheritance''' Often there is a need to use
the exact same services/beans/etc one multiple pages.  The current solution is to add them
to all the page/jwc files.  There should be a way to inherit another page/jwc file and/or
simply import another page/jwc file's settings. (Note that this is already possible with annotations.)
- 
-  * '''Switch Default Binding for .html to ognl:''' Having ognl: as the default binding would
be a welcome change (and improve portability from .page -> .html - this makes sense as
.pages seem to be on the way out and consistency/convention is always a +).
-  
-  * '''Programatically set-up pages in service interceptors''' A while ago I (Mike Snare)
logged this as a JIRA issue to handle the fact that I'm using interceptors for security and
need a way to create callbacks.  Logged as TAPESTRY-892.  I hate to put it here, but I do
genuinely *wish* tapestry had that feature. I (Henri Dupre) fully second this one. I wish
to see a "service" level interceptor that would also give access to the page object (to be
able to check for annotations). Different usages of that type of interceptor/filter are: automatic
loading/unloading of hibernate objects in ASO, authentification and synchronization.
- 
-  * '''Rename the template page from *.page to *.xml or *.page.xml''' This feature would
allow the IDE to provide some completion and validate the template
- 
-  * '''Facilitate the authentification issue''' Authentification is a functionality used
by most of the websites. However there is no "standardised" way to deal with it. Furthermore,
an easy to specify in the template an user should be logged to access this template would
be welcomed as well. 
- 
-  * '''A standard @Style component a la TapFX's @Style component''' This would improve including
styling for a component. Having it rendered in the head tag, proper, would rid many a page
of being loaded, then flickering/"popping" into a new style sheet, as the declaration in JS
to dynamically include a style sheet is only reached after other things have been loaded.
Infrastructure would need some slight modifications in the head tag. This would hopefully
be a beefed up Style component, which did things like branching on evaluated values (as you
might with a .script). At it's most useful, it would handle different media types and other,
arbitrary kinds of branches, like ((IE < 6)+quirksmode), or user agents. ASP.NET had/has(?)
agent profiles, whereby components rendered 'upstream' content, and 'downstream' content.
I think the same mechanism is in place for serving WML controls vs. html controls, etc. Dojo
has a conditional package mechanism where certain code is enabled based on the runtime environment
present (common, browser, rhino, etc). So there's definitely precedant for this thing. The
component would hopefully support both a CSS 'spec' (like .script) AND a plain old .css. I
don't like having to create a .script JUST to include a .js. A standard @Style mechanism would
also promote higher quality components that shipped with useful, overridable, defaults, like
the list pallette component.
- 
-  * '''Could we modify @Script to accept a toggle to tell it to include .js OR .script.'''
If it was inserting just a .js, then the parametes would be ignored, i suppose. 
- 
-  
-  * '''An easy way (flag somewhere) to show error pages for developers and for users''' This
avoid the need to do and re-do error pages, this should be as in ASP.NET where throught a
config value in an XML file you can control if you want that the error page is showed with
full debug information on different levels (only web server, local network or publicly) if
the access is from wider context than configured, then shows a default page with the error
and some useful information (not all info that the debug shows). Or maybe could be a flag
if the project is on dev or production to achieve the same effect, I believe this option is
easier to develop.
- 
-  * '''Improve @PropertySelection''' In Tapestry 4, some components like @Foreach was updated
to a much more friendlier version @For with new APIs (IPrimaryKeyConverter) and more flexible
inputs parameters. In its current format, it is akward to use @PropertySelection transparently
with hibernate for instance. 
- 
-  * '''Make the hivedoc easier''' The hivedoc is a key document but for a beginner I find
more than confusing: the format of the documentation needs to be documented. The meaning of
"configuration point" is not obvious, also some hivemind documentation should show how to
use a specific configuration point. Same for service points, the meaning of the "implementation"
there is neither obvious (I'm not sure that showing the implementation is even necessary).
Eventually a easier navigation (like JavaDocs) would be bonus too.
- 
-  * '''Make switching between HTTP & HTTPS easier''' As suggested in a recent thread,
there should be a way in the page spec to mark a page as requiring http or https (http being
the default).  The framework should then make sure all links to that page use the proper scheme.
 This is in contrast to the current Tapestry way, which is for each link to specify the scheme.
- 
-  * '''Make custom Page Not Found easier''' Separate a NotFound.page from Exception.page,
allowing a simple definition of a NotFound.page & NotFound.html in the webapp. Perhaps
also make it configurable for the page to set a HTTP error code.
- 
-  * '''Aggressively reduce verbosity and repetition''' Page templates are very verbose compared
to most other templating languages. (The default 'ognl:' binding might be a good start, but
won't solve the issue by itself.) Many component bindings involve unacceptable repetition:
for example, the common case of a field with a translator and validator declared in an annotation
involves redundant declaration of many things (such as the type of the component) which Tapestry
should be able to infer. In general, Tapestry needs a lot more of the "don't repeat yourself"
attitude.
- 
-  * '''Ad-hoc / undeclared properties''' One of the few features of JSP I miss is the ability
to declare an ad-hoc property for use as the iteration value in a loop. Tapestry requires
the page to declare a property for a For's value, even if that value has no meaning outside
the template.
- 
-  * '''Restart sevice to load Home page''' Rather than load the servlet path, make the Restart
service load the Home page just like Home service does. I makes friendly URLs one bit simpler
to implement.
- 
-  * '''Make components globally accessible''' Make it possible to get rid of component libraries,
allowing easier component inheritance. Components should be identified in a global namespace,
java packages are a logical choice. For example instead of framework:TextField one should
use org.apache.tapestry.form.TextField. Component libraries make a component very difficult
to use in another component library. Suppose that I have a custom mylibrary:CompositePanel
component which references a component of the same library by SomeCustomComponent. Because
SomeCustomComponent has a meaning only in the context of mylibrary, CompositePanel cannot
be used in another library (for example as a base class).
- 
-  * [[Tapestry_4.1_ResponseBuilder_sandbox]]
- 

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


Mime
View raw message