[jira] Closed: (TAP5-742) Add optional component tracing comments to rendered output
[ https://issues.apache.org/jira/browse/TAP5-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams closed TAP5-742. -- Resolution: Fixed > Add optional component tracing comments to rendered output > -- > > Key: TAP5-742 > URL: https://issues.apache.org/jira/browse/TAP5-742 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Howard M. Lewis Ship >Assignee: Dan Adams >Priority: Minor > Fix For: 5.2.5 > > > In complex pages, it can be hard to work backwards from a bit of output HTML > in the browser, back to the component that originated the markup. > This feature adds rendering of comments that provide trace output of which > component is currently currently: > >href="/abstractcomponentdemo">Abstract Component Demo > Note that the BEGIN comment includes both the complete component id in the > page and the location of that in the template. With just the component id it > can still be unclear which component is being referenced without the line > number. > For security purposes, this feature cannot be enabled in production mode. In > non-production mode it can be enabled two ways: > - Setting the symbol "tapestry.component-render-tracing-enabled" to "true" > (default: false) > - Setting the request query parameter "t:component-trace" on the URL to > "true". This allows enabling for a specific request when you need it in > development rather than having it on all the time. > Note that rendering comments are based on the component lifecycle. Thus in > some case where post-render DOM manipulation is performed the markup my not > longer be in the correct rendering comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-742) Add optional component tracing comments to rendered output
[ https://issues.apache.org/jira/browse/TAP5-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams updated TAP5-742: --- Fix Version/s: 5.2.5 Description: In complex pages, it can be hard to work backwards from a bit of output HTML in the browser, back to the component that originated the markup. This feature adds rendering of comments that provide trace output of which component is currently currently: Abstract Component Demo Note that the BEGIN comment includes both the complete component id in the page and the location of that in the template. With just the component id it can still be unclear which component is being referenced without the line number. For security purposes, this feature cannot be enabled in production mode. In non-production mode it can be enabled two ways: - Setting the symbol "tapestry.component-render-tracing-enabled" to "true" (default: false) - Setting the request query parameter "t:component-trace" on the URL to "true". This allows enabling for a specific request when you need it in development rather than having it on all the time. Note that rendering comments are based on the component lifecycle. Thus in some case where post-render DOM manipulation is performed the markup my not longer be in the correct rendering comments. was: In complex pages, it can be hard to work backwards from a bit of output HTML in the browser, back to the component that originated the markup. A special mode could be enabled where components would render a comment before and after rendering: Dashboard This would bloat and clutter the application (a lot!) but would be useful, on occasion. One possibility would be a special query parameter to enable this on a request-by-request basis, i.e., ?t:component-trace=true Affects Version/s: (was: 5.1.0.5) 5.2.4 > Add optional component tracing comments to rendered output > -- > > Key: TAP5-742 > URL: https://issues.apache.org/jira/browse/TAP5-742 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Howard M. Lewis Ship >Assignee: Dan Adams >Priority: Minor > Fix For: 5.2.5 > > > In complex pages, it can be hard to work backwards from a bit of output HTML > in the browser, back to the component that originated the markup. > This feature adds rendering of comments that provide trace output of which > component is currently currently: > >href="/abstractcomponentdemo">Abstract Component Demo > Note that the BEGIN comment includes both the complete component id in the > page and the location of that in the template. With just the component id it > can still be unclear which component is being referenced without the line > number. > For security purposes, this feature cannot be enabled in production mode. In > non-production mode it can be enabled two ways: > - Setting the symbol "tapestry.component-render-tracing-enabled" to "true" > (default: false) > - Setting the request query parameter "t:component-trace" on the URL to > "true". This allows enabling for a specific request when you need it in > development rather than having it on all the time. > Note that rendering comments are based on the component lifecycle. Thus in > some case where post-render DOM manipulation is performed the markup my not > longer be in the correct rendering comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-742) Add optional component tracing comments to rendered output
[ https://issues.apache.org/jira/browse/TAP5-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams reassigned TAP5-742: -- Assignee: Dan Adams > Add optional component tracing comments to rendered output > -- > > Key: TAP5-742 > URL: https://issues.apache.org/jira/browse/TAP5-742 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Howard M. Lewis Ship >Assignee: Dan Adams >Priority: Minor > > In complex pages, it can be hard to work backwards from a bit of output HTML > in the browser, back to the component that originated the markup. > A special mode could be enabled where components would render a comment > before and after rendering: > > Dashboard > > This would bloat and clutter the application (a lot!) but would be useful, on > occasion. One possibility would be a special query parameter to enable this > on a request-by-request basis, i.e., ?t:component-trace=true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1301) Allow changing the ClassLoader Tapestry uses for loading classes and resources
[ https://issues.apache.org/jira/browse/TAP5-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams updated TAP5-1301: Priority: Minor (was: Major) > Allow changing the ClassLoader Tapestry uses for loading classes and resources > -- > > Key: TAP5-1301 > URL: https://issues.apache.org/jira/browse/TAP5-1301 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-ioc >Affects Versions: 5.1.0.4 >Reporter: Dan Adams >Priority: Minor > > I have a situation where we want to extend the classloader used for the > application with additional classes in a non-container-specfic way. > TapestryFilter.provideExtraModuleDefs() appears to support this at first > except that there are many references throughout Tapestry to > Thread.currentThread().getContextClassLoader() which bypasses any classloader > you provide when creating the ModuleDef. Furthermore, there is a constructor > to RegistryBuilder that allows providing your own root classloader but even > if you can get that to work the above call make it's moot as it won't find > any of your page templates and such. This could be quite simple if: > - TapestryFilter and it's related classes allowed extending the ClassLoader > (by wrapping it in a URLClassLoader) for instance > - Using a definitive ClassLoader rather than > Thread.currentThread().getContextClassLoader() to get resources. > May affect more recent versions but I have not checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1378) Allow Delegate component to be used for creating in-template components
[ https://issues.apache.org/jira/browse/TAP5-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams closed TAP5-1378. --- Resolution: Fixed Fix Version/s: 5.2.5 Implemented with support for render variables. I thought about putting it support for autobinding to containing component parameters based on informal parameter name but that could be confusing and it can be put in later. > Allow Delegate component to be used for creating in-template components > --- > > Key: TAP5-1378 > URL: https://issues.apache.org/jira/browse/TAP5-1378 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Dan Adams >Assignee: Dan Adams > Fix For: 5.2.5 > > > Allow the delegate component to accept informal parameters and pass those to > the block being rendered as render variables. This allows creating a > component-with-a-component extremely easily using a block. I've got an > implementation of this that we've used successfully for a while that I can > contribute or use as as base. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1378) Allow Delegate component to be used for creating in-template components
[ https://issues.apache.org/jira/browse/TAP5-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams reassigned TAP5-1378: --- Assignee: Dan Adams > Allow Delegate component to be used for creating in-template components > --- > > Key: TAP5-1378 > URL: https://issues.apache.org/jira/browse/TAP5-1378 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Dan Adams >Assignee: Dan Adams > > Allow the delegate component to accept informal parameters and pass those to > the block being rendered as render variables. This allows creating a > component-with-a-component extremely easily using a block. I've got an > implementation of this that we've used successfully for a while that I can > contribute or use as as base. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1378) Allow Delegate component to be used for creating in-template components
[ https://issues.apache.org/jira/browse/TAP5-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973261#action_12973261 ] Dan Adams commented on TAP5-1378: - What would the advantages of a local macro be? Are there things you could do with lifecycles or mixins or something that you can't do here that would be useful? I really like the idea of this being at the component level and not having to extend the template spec. btw, I'm going to investigate if there is a way to support generics or extended prop expressions beyond what var: supports for this. Although, I've been using an implementation of this for months and months and never needed it. You can always make it a component if you really need to, but the simple support using render variables is really nice to have as an option. > Allow Delegate component to be used for creating in-template components > --- > > Key: TAP5-1378 > URL: https://issues.apache.org/jira/browse/TAP5-1378 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.2.4 >Reporter: Dan Adams > > Allow the delegate component to accept informal parameters and pass those to > the block being rendered as render variables. This allows creating a > component-with-a-component extremely easily using a block. I've got an > implementation of this that we've used successfully for a while that I can > contribute or use as as base. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1378) Allow Delegate component to be used for creating in-template components
Allow Delegate component to be used for creating in-template components --- Key: TAP5-1378 URL: https://issues.apache.org/jira/browse/TAP5-1378 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.4 Reporter: Dan Adams Allow the delegate component to accept informal parameters and pass those to the block being rendered as render variables. This allows creating a component-with-a-component extremely easily using a block. I've got an implementation of this that we've used successfully for a while that I can contribute or use as as base. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1377) Combine CSS files in production mode
Combine CSS files in production mode Key: TAP5-1377 URL: https://issues.apache.org/jira/browse/TAP5-1377 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.2.4 Reporter: Dan Adams When in production mode, combine CSS files into a single file as is done with javascript resources. * Any relative references to urls in the CSS contents should be absolutized based on the URL of the original CSS path so that things like background images continue to function. * @import statements should also be unpacked so that designers have flexibility in how the files are structured. * Any CSS files that have a class on the link element of "nocombine" or that have a non default/non-screen media should not be combined. * Record a comment before each file saying which CSS file it originally came from -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1305) Service decorations can fail if using the conventional naming
Service decorations can fail if using the conventional naming
-
Key: TAP5-1305
URL: https://issues.apache.org/jira/browse/TAP5-1305
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-ioc
Affects Versions: 5.1.0.4
Reporter: Dan Adams
If you have a service FooBar and 2 modules that each have:
public static FooBar decorateFooBar(FooBar delegate, ...)
you will get a logging message like this:
[WARN] com.example.services.BazModule.FooBar Could not add object with
duplicate id 'FooBar'. The duplicate object has been ignored.
which results in one of the contributions (you don't know which one) being
dropped. This is because T5 uses an ordered contribution internally when
collecting the contributions and bases the id of the contribution based on the
method name (drops "decorate").
It should either fail with an exception and a good error or support this
behaviour. The problematic line is RegistryImpl.findDecoratorsForService (line
634).
The work-around is to use @Match("FooBar") on the method and name it something
different such as "decoratingWithMyThingy".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1301) Allow changing the ClassLoader Tapestry uses for loading classes and resources
Allow changing the ClassLoader Tapestry uses for loading classes and resources -- Key: TAP5-1301 URL: https://issues.apache.org/jira/browse/TAP5-1301 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.1.0.4 Reporter: Dan Adams I have a situation where we want to extend the classloader used for the application with additional classes in a non-container-specfic way. TapestryFilter.provideExtraModuleDefs() appears to support this at first except that there are many references throughout Tapestry to Thread.currentThread().getContextClassLoader() which bypasses any classloader you provide when creating the ModuleDef. Furthermore, there is a constructor to RegistryBuilder that allows providing your own root classloader but even if you can get that to work the above call make it's moot as it won't find any of your page templates and such. This could be quite simple if: - TapestryFilter and it's related classes allowed extending the ClassLoader (by wrapping it in a URLClassLoader) for instance - Using a definitive ClassLoader rather than Thread.currentThread().getContextClassLoader() to get resources. May affect more recent versions but I have not checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1241) Automatic gzipping does not allow setting a content length for generated content
Automatic gzipping does not allow setting a content length for generated content Key: TAP5-1241 URL: https://issues.apache.org/jira/browse/TAP5-1241 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.4 Reporter: Dan Adams If if you have Dispatcher (or something else) that generates a response and call response.setContentLength() on a text/* mime type the resulting response content length does not match the length of the actual response. This is due to that you set the content length for the uncompressed content and the response is intercepted and gzipped but the original length is still set. In firefox and IE this doesn't appear to be a problem. Chrome however will simply not load stylesheets where this occurs. If something like GZipFilter is going to automatically gzip the response it should also change the content length to reflect the new response length. The workaround at the moment is simply not setting a content length. This may very well effect future versions; I couldn't find an existing ticket though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1193) tapestry.js prevents using the back/forward browser cache
tapestry.js prevents using the back/forward browser cache
-
Key: TAP5-1193
URL: https://issues.apache.org/jira/browse/TAP5-1193
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.4
Reporter: Dan Adams
At the bottom of tapestry.js is the following:
// Ajax code needs to know to do nothing after the window is unloaded.
Event.observe(window, "beforeunload", function()
{
Tapestry.windowUnloaded = true;
});
Assume you have a page that does this:
- loads in some initial state
- user does something causing a ajax request that changes the DOM
- user clicks a link to go to another page
- user clicks back button
rather than getting the state of the page before they left the user will get
the original state of the page including the DOM and js state and the load
handlers will be run. Using the hash method of maintaining ajax history (or
maybe a cookie) is really not an option in this case because the DOM is out of
date. You'd need to do an extra ajax request to the server to restore the state
and the user experience would be really poor.
There needs to be at least of the option of disabling this for pages that need
this behavior.
See
http://stackoverflow.com/questions/158319/cross-browser-onload-event-and-the-back-button
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-928) Link should support multiple values for a single query parameter
[ https://issues.apache.org/jira/browse/TAP5-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833468#action_12833468 ] Dan Adams commented on TAP5-928: there are legit application scenarios where using query parameters is the most natural fit for maintaining page state / page context. i propose that we change Link.addParameter() to not throw IllegalArgumentException if called multiple times with the same value. this should be backward compatible since we are relaxing restrictions on it. > Link should support multiple values for a single query parameter > > > Key: TAP5-928 > URL: https://issues.apache.org/jira/browse/TAP5-928 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Dan Adams > > You should be able to set multiple values for a query parameter in the same > way that you can get multiple values for a single parameter from Request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-901) Generics return wrong type when subclassing page
[
https://issues.apache.org/jira/browse/TAP5-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Adams updated TAP5-901:
---
Attachment: tap5-901-patch.txt
patch with a test case that reproduces the exception. the property binding
should see the return type as String but it's actually Object thus causing a
big fat exception.
> Generics return wrong type when subclassing page
>
>
> Key: TAP5-901
> URL: https://issues.apache.org/jira/browse/TAP5-901
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.1.0.4
>Reporter: Mike Leonardo
> Attachments: tap5-901-patch.txt
>
>
> I have a custom library that has the following classes:
> {{{
> public abstract class AbstractViewPage, V extends
> StaticPageVersion> {
> private static final Pattern ID = Pattern.compile("^\\d+$");
> @InjectDao(StaticPage.class) private Dao dao;
> @Inject private Response response;
> private T page;
> void onActivate(String key) throws IOException {
> if (ID.matcher(key).matches())
> page = dao.get(Long.parseLong(key));
> else {
> page = dao.get(eq("name", key));
> }
>
> if (page != null && page.getLive() == null)
> page = null;
>
> if (page == null)
> response.sendError(404, "Page not found");
> }
>
> public T getPage() {
> return page;
> }
> public void setPage(T page) {
> this.page = page;
> }
> /** Returns the versioned content to display. */
> public V getContent() {
> if (page == null)
> return null;
>
> return page.getLive();
> }
> }
> }}}
> {{{
> /** Displays a static page */
> @Public
> public class Page extends AbstractViewPage IFPStaticPageVersion> {
>
> @Inject private IAuth auth;
> @Inject private HttpServletRequest request;
> @Inject private HttpServletResponse response;
>
> Object onActivate() {
> IFPStaticPage page = getPage();
> if (page != null && page.isRestricted() &&
> auth.getAccount(request, response) == null)
> return "start";
>
> return null;
> }
>
> public boolean isTopLevel() {
> return getPage() == getPage().getSectionPage();
> }
>
> void onEndElementFromBreadcrumb(Element e) {
> if ("a".equals(e.getName()))
>
> e.getContainer().raw(" › ");
> }
>
> }
> }}}
> As you can see, based on generics the method "getContent" should return a
> IFPStaticPageVersion.
> This works fine when I use this Page.class directly.
> Recently I wanted to extend this Page.class to add a few features specific to
> one project. When I extended this class (no template so that it would use the
> Page.class template) I ended up getting an error on the subclass. The error
> occurred because getContent returned a completely different class instead of
> IFPStaticPageVersion.
> I work around I found to fix this is to override the getContent method so
> that it explicitly defines the return type. But I had to do this in both
> Page.class and the subclass (Page2.class). Here's my addition to both
> classes:
> {{{
> @Override
> public IFPStaticPageVersion getContent() {
> return super.getContent();
> }
> }}}
> Obviously I shouldn't have to do this to get the correct class back
> (especially not to both Page.class AND Page2.class.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-901) Generics return wrong type when subclassing page
[
https://issues.apache.org/jira/browse/TAP5-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806363#action_12806363
]
Dan Adams commented on TAP5-901:
i reproduced this in another case which i think is reproduced in the following:
public abstract BasePage {
public abstract Foo getFoo() ...
}
public abstract MoreSpecificBasePage extends BasePage {
@Override
public abstract SubFoo getFoo() ...
}
public ConcretePage extends MoreSpecificBasePage {
// does NOT override
}
The page template will see Foo as the return type, not SubFoo. Overriding it in
ConcretePage will fix this.
> Generics return wrong type when subclassing page
>
>
> Key: TAP5-901
> URL: https://issues.apache.org/jira/browse/TAP5-901
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.1.0.4
>Reporter: Mike Leonardo
>
> I have a custom library that has the following classes:
> {{{
> public abstract class AbstractViewPage, V extends
> StaticPageVersion> {
> private static final Pattern ID = Pattern.compile("^\\d+$");
> @InjectDao(StaticPage.class) private Dao dao;
> @Inject private Response response;
> private T page;
> void onActivate(String key) throws IOException {
> if (ID.matcher(key).matches())
> page = dao.get(Long.parseLong(key));
> else {
> page = dao.get(eq("name", key));
> }
>
> if (page != null && page.getLive() == null)
> page = null;
>
> if (page == null)
> response.sendError(404, "Page not found");
> }
>
> public T getPage() {
> return page;
> }
> public void setPage(T page) {
> this.page = page;
> }
> /** Returns the versioned content to display. */
> public V getContent() {
> if (page == null)
> return null;
>
> return page.getLive();
> }
> }
> }}}
> {{{
> /** Displays a static page */
> @Public
> public class Page extends AbstractViewPage IFPStaticPageVersion> {
>
> @Inject private IAuth auth;
> @Inject private HttpServletRequest request;
> @Inject private HttpServletResponse response;
>
> Object onActivate() {
> IFPStaticPage page = getPage();
> if (page != null && page.isRestricted() &&
> auth.getAccount(request, response) == null)
> return "start";
>
> return null;
> }
>
> public boolean isTopLevel() {
> return getPage() == getPage().getSectionPage();
> }
>
> void onEndElementFromBreadcrumb(Element e) {
> if ("a".equals(e.getName()))
>
> e.getContainer().raw(" › ");
> }
>
> }
> }}}
> As you can see, based on generics the method "getContent" should return a
> IFPStaticPageVersion.
> This works fine when I use this Page.class directly.
> Recently I wanted to extend this Page.class to add a few features specific to
> one project. When I extended this class (no template so that it would use the
> Page.class template) I ended up getting an error on the subclass. The error
> occurred because getContent returned a completely different class instead of
> IFPStaticPageVersion.
> I work around I found to fix this is to override the getContent method so
> that it explicitly defines the return type. But I had to do this in both
> Page.class and the subclass (Page2.class). Here's my addition to both
> classes:
> {{{
> @Override
> public IFPStaticPageVersion getContent() {
> return super.getContent();
> }
> }}}
> Obviously I shouldn't have to do this to get the correct class back
> (especially not to both Page.class AND Page2.class.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-928) Link should support multiple values for a single query parameter
Link should support multiple values for a single query parameter Key: TAP5-928 URL: https://issues.apache.org/jira/browse/TAP5-928 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Dan Adams You should be able to set multiple values for a query parameter in the same way that you can get multiple values for a single parameter from Request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-902) GridDataSource does not allow performing less than 2 queries if returning results
GridDataSource does not allow performing less than 2 queries if returning results - Key: TAP5-902 URL: https://issues.apache.org/jira/browse/TAP5-902 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Dan Adams By having getAvailableRows() and prepare() separate, any implementation is forced to perform 2 queries. Many systems allow getting the results of a query and the total count in one query so that you don't have to perform 2 queries. Getting around this requires some pretty gross hacks (unless you just don't use grid at all which is unfortunate). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-705) Let a page choose its layout
[
https://issues.apache.org/jira/browse/TAP5-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709864#action_12709864
]
Dan Adams commented on TAP5-705:
We actually have a need for exactly feature on our end in that pages need to be
able to indicate which layout to use or delegate the layout rendering without
knowing a head of time which layout will be used or even allowing swapping out
the implementation to a different layout. I was planning on doing this in our
library somehow but being able to delegate rendering to an implementation of a
component would be great.
> Let a page choose its layout
>
>
> Key: TAP5-705
> URL: https://issues.apache.org/jira/browse/TAP5-705
> Project: Tapestry 5
> Issue Type: Wish
> Components: tapestry-core
>Affects Versions: 5.0.18
>Reporter: Borut Bolcina
>
> It would be great if a page could dynamically choose its layout. In some
> cases the page would use Layout1 component and in some cases Layout2.
> The t:type="${layout}" does not get expanded to whatever I set in Index.java.
> PageWithLayout.tml
> ===
> xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> page with ${layout}
>
> PageWithLayout.java
> ===
> public class PageWithLayout {
> private String layout;
>
> public String getLayout() {
> return layout;
> }
> public void setLayout(String layout) {
> this.layout = layout;
> }
> }
> Index.tml
> ===
> layout1
> layout2
> Index.java
> ===
> public class Index {
> @InjectPage
> private PageWithLayout pageWithLayout;
>
> Object onActionFromPageWithLayout1() {
> pageWithLayout.setLayout("layout1");
> return pageWithLayout;
> }
>
> Object onActionFromPageWithLayout2() {
> pageWithLayout.setLayout("layout2");
> return pageWithLayout;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-675) NPE in Element when removing empty children
NPE in Element when removing empty children
---
Key: TAP5-675
URL: https://issues.apache.org/jira/browse/TAP5-675
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.4
Reporter: Dan Adams
I have a page that renders an XML sitemap:
http://www.sitemaps.org/schemas/sitemap/0.9";
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
${url.url}
${url.changeFrequency}
${url.priority}
class:
void onEndElementFromLoop(Element el) {
if (el.getChildren().isEmpty())
el.remove(); /// NPE HERE
}
An NPE gets thrown at org.apache.tapestry5.dom.Node.remove(Node.java:186).
Appears to be the same issue or related to TAP5-640
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-640) DOM manipulation no longer allowed during rendering
DOM manipulation no longer allowed during rendering --- Key: TAP5-640 URL: https://issues.apache.org/jira/browse/TAP5-640 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Dan Adams We have a number of utilities that do DOM manipulation while the page is rendering. This is often a lot easier than doing it after render and results in more concise code. An example is if you have a list of elements: foo After each LI renders, do something like this: if (element.getChildren().isEmpty()) element.remove(); It will work for the first empty LI and throw a NPE on the second empty LI because the container inside the element is null (which is odd since it just rendered into a container). But if you wait till after the LIs have all rendered you can loop back and do this safely. However, it's much less readable code and is a real bummer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-423) Implement a file-system Asset type
[ https://issues.apache.org/jira/browse/TAP5-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693762#action_12693762 ] Dan Adams commented on TAP5-423: I've implemented something very similar to this in our CMS projects: there is a "fileasset" asset type which provides access to a filesystem-based store that is also accessible via a URL. You can't tell where it is based on the URL, you can only access files within that store so it's secure, and you can't tell where the files are actually located / served from (eg could be on a CDN rather or served through apache statically or something). By and large, this is has been great however one problem I ran into was that requesting an Asset that doesn't exist causes an exception but you may want to require a fileasset that doesn't exist so that you can write to it. But that wasn't hard to work around. This could be extended in the future without a lot of change to support multiple roots or even multiple content stores (eg one root is on a CDN, one is on a filesystem, and one is from a database) . It's a simple implementation right now used by one project (so the API hasn't yet been put through the paces) but I'd be willing to provide it if you'd like it. > Implement a file-system Asset type > -- > > Key: TAP5-423 > URL: https://issues.apache.org/jira/browse/TAP5-423 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.0.18 >Reporter: manuel aldana > > currenty it is built in to retrieve assets from classpath and from webcontext. > a file system asset type which can retrieve stuff directly from the > filesystem (e.g. from /srv/statics/) makes also sense. > something like: > *ResourceFileSystem extends AbstractResource* and *FileSystemAssetFactory > extends AssetFactory* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-492) Unable to deploy Tapestry 5 Web application in Weblogic 9.2
[ https://issues.apache.org/jira/browse/TAP5-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669612#action_12669612 ] Dan Adams commented on TAP5-492: I'm not sure what your specific issue is, but it's worth noting I have a pretty complex t5 app running in WL 9.2 so it does work. > Unable to deploy Tapestry 5 Web application in Weblogic 9.2 > --- > > Key: TAP5-492 > URL: https://issues.apache.org/jira/browse/TAP5-492 > Project: Tapestry 5 > Issue Type: Question >Affects Versions: 5.0.18 >Reporter: Sukrish >Priority: Blocker > > Hello, When I try to deploy my Tapestry 5 application in Weblogic 9.2, I get > the following error > --- > An error occurred during activation of changes, please see the log for > details. > [HTTP:101064][WebAppModule(myapp:eClaimsWW)] Error parsing descriptor in > Web appplication "C:\Tap5\my-app\target\eClaimsWW" > weblogic.application.ModuleException: Unmarshaller failed at > weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.java:781) > at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:272) at > weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176) > at > weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93) > at > weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:360) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:56) > at > weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:46) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191) > at > weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:147) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:189) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:87) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:718) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1185) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:247) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) > at > weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) at > weblogic.work.ExecuteThread.run(ExecuteThread.java:181) Caused by: > weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: > "weblogic.j2ee.descriptor.filterbeani...@6908ff(/Filters[app])" at > weblogic.descriptor.internal.ReferenceManager.registerBean(ReferenceManager.java:207) > at > weblogic.j2ee.descriptor.WebAppBeanImpl.setFilters(WebAppBeanImpl.java:703) > at > jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown > Source) at > java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown > Source) at > com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:48) > at > com.bea.staxb.runtime.internal.RuntimeBindingType$BeanRuntimeProperty.setValue(RuntimeBindingType.java:483) > at > com.bea.staxb.runtime.internal.AttributeRuntimeBindingType$QNameRuntimeProperty.fillCollection(AttributeRuntimeBindingType.java:385) > at > com.bea.staxb.runtime.internal.MultiIntermediary.getFinalValue(MultiIntermediary.java:52) > at > com.bea.staxb.runtime.internal.AttributeRuntimeBindingType.getFinalObjec
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668970#action_12668970 ] Dan Adams commented on TAP5-486: It may be worth noting that my objection has nothing to do with whether or not I like jquery. I actually like it quite a bit. :) > Switch Tapestry's built-in JavaScript support from Prototype to jQuery > -- > > Key: TAP5-486 > URL: https://issues.apache.org/jira/browse/TAP5-486 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.0 >Reporter: Howard M. Lewis Ship > > Like rats deserting a sinking ship ... > This is not a definitive requirement; I've created this issue to promote > discussion. > It's quite likely that a move like this could be accomplished quite smoothly > for users who are meerly consumers of JavaScript components; authors of > JavaScript components would have to make some changes. > Possibly we should code the jQuery stack from the get-go to NOT use the $() > method, but instead use j$(). That extra character to type could make all the > difference is allowing a smooth upgrade, where jQuery becomes the default, > but prototype/scriptaculous can still be used. > Possibly a new annotation, @PrototypeSupport for components to ensure that > the Prototype libraries are available for compatibility? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668912#action_12668912 ] Dan Adams commented on TAP5-486: As a user who just completed a complex project with heavy javascript interaction, a number of new javascript classes, as well as extensions to the existing javascript classes I'm 100% against this. I think this is actually big enough that it breaks T5's promise of backwards compatibility. For applications like the one I'm talking about, javascript is a core part of the application just like the Java APIs and replacing prototype w/ jquery would be like replacing T5 IoC w/ spring. In fact, it's probably would actually be worse since the javascript stuff (especially ajax and anything in IE) is much harder to test than anything in the java layer. This may be a large enough change that it would mean the application could never be upgraded to T5.1 or above which would be a huge bummer and an indication of broken backwards compatibility. > Switch Tapestry's built-in JavaScript support from Prototype to jQuery > -- > > Key: TAP5-486 > URL: https://issues.apache.org/jira/browse/TAP5-486 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.0 >Reporter: Howard M. Lewis Ship > > Like rats deserting a sinking ship ... > This is not a definitive requirement; I've created this issue to promote > discussion. > It's quite likely that a move like this could be accomplished quite smoothly > for users who are meerly consumers of JavaScript components; authors of > JavaScript components would have to make some changes. > Possibly we should code the jQuery stack from the get-go to NOT use the $() > method, but instead use j$(). That extra character to type could make all the > difference is allowing a smooth upgrade, where jQuery becomes the default, > but prototype/scriptaculous can still be used. > Possibly a new annotation, @PrototypeSupport for components to ensure that > the Prototype libraries are available for compatibility? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-298) JS error in Palette for disabled options
[ https://issues.apache.org/jira/browse/TAP5-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams closed TAP5-298. -- Resolution: Fixed Fix Version/s: 5.1.0.0 > JS error in Palette for disabled options > > > Key: TAP5-298 > URL: https://issues.apache.org/jira/browse/TAP5-298 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 >Reporter: Dan Adams >Assignee: Dan Adams > Fix For: 5.1.0.0 > > > * Create a palette with one option in 'selected' that is disabled > * Double click the option > Index or size is negative or greater than the allowed amount" code: "1 at > palette.js Line 181 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-298) JS error in Palette for disabled options
[ https://issues.apache.org/jira/browse/TAP5-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Adams reassigned TAP5-298: -- Assignee: Dan Adams > JS error in Palette for disabled options > > > Key: TAP5-298 > URL: https://issues.apache.org/jira/browse/TAP5-298 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 >Reporter: Dan Adams >Assignee: Dan Adams > > * Create a palette with one option in 'selected' that is disabled > * Double click the option > Index or size is negative or greater than the allowed amount" code: "1 at > palette.js Line 181 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
