[jira] [Updated] (TAP5-2274) AjaxFormLoop doesn't work well inside a table tag
[ https://issues.apache.org/jira/browse/TAP5-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2274: - Fix Version/s: (was: 5.4) > AjaxFormLoop doesn't work well inside a table tag > - > > Key: TAP5-2274 > URL: https://issues.apache.org/jira/browse/TAP5-2274 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Sven Homburg >Assignee: Howard M. Lewis Ship > Labels: patch > Attachments: > 0003-TAP5-2274-AjaxFormLoop-dont-work-well-inside-a-table.patch > > > if i use AjaxFormLoop inside a table tag, like this: > > > > > Name 1 > Name 2 > > > > encoder="personHolderEncoder" value="personHolder"> > value="personHolder.person.name1"/> > value="personHolder.person.name2"/> > > > > > there is no javascript error thrown. > here the code rendered by tapestry: > id="form"> > value="cYCR+e8VnfSZyMMIKGcs2cKU1F0=:H4sIAFvzloEVAN3OqfcE" > name="t:formdata" type="hidden"> > data-inject-row-url="/tap54test/start.ajaxformloop:injectrow?t:formcomponentid=Start:formt:formid=form" > data-remove-row-url="/tap54test/start.ajaxformloop:triggerremoverow" > data-container-type="core/AjaxFormLoop"> > > > > Add row > > > > > Name 1 > Name 2 > Birthday > > > > data-container-type="core/ajaxformloop-fragment"> > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2520) NullPointerException in CaseInsensitiveMap
[
https://issues.apache.org/jira/browse/TAP5-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2520:
-
Component/s: tapestry-ioc
tapestry-core
> NullPointerException in CaseInsensitiveMap
> --
>
> Key: TAP5-2520
> URL: https://issues.apache.org/jira/browse/TAP5-2520
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core, tapestry-ioc
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$CIMEntry.access$700(CaseInsensitiveMap.java:39)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:476)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:451)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:387)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.assembleJavascriptResourceForStack(JavaScriptStackAssemblerImpl.java:115)
> ~[tapestry-core-5.4.0.jar:na]
> {code}
> This is probably caused by concurrent access to the map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2520) NullPointerException in CaseInsensitiveMap
[
https://issues.apache.org/jira/browse/TAP5-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2520:
-
Description:
{code}
java.lang.NullPointerException: null
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap$CIMEntry.access$700(CaseInsensitiveMap.java:39)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:476)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:451)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:387)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.assembleJavascriptResourceForStack(JavaScriptStackAssemblerImpl.java:115)
~[tapestry-core-5.4.0.jar:na]
{code}
This is probably caused by concurrent access to the map.
was:
{code}
java.lang.NullPointerException: null
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap$CIMEntry.access$700(CaseInsensitiveMap.java:39)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:476)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:451)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:387)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.assembleJavascriptResourceForStack(JavaScriptStackAssemblerImpl.java:115)
~[tapestry-core-5.4.0.jar:na]
{code}
> NullPointerException in CaseInsensitiveMap
> --
>
> Key: TAP5-2520
> URL: https://issues.apache.org/jira/browse/TAP5-2520
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core, tapestry-ioc
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$CIMEntry.access$700(CaseInsensitiveMap.java:39)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:476)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:451)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:387)
> ~[commons-5.4.0.jar:na]
> at
> org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.assembleJavascriptResourceForStack(JavaScriptStackAssemblerImpl.java:115)
> ~[tapestry-core-5.4.0.jar:na]
> {code}
> This is probably caused by concurrent access to the map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2520) NullPointerException in CaseInsensitiveMap
Jochen Kemnade created TAP5-2520:
Summary: NullPointerException in CaseInsensitiveMap
Key: TAP5-2520
URL: https://issues.apache.org/jira/browse/TAP5-2520
Project: Tapestry 5
Issue Type: Improvement
Affects Versions: 5.4
Reporter: Jochen Kemnade
{code}
java.lang.NullPointerException: null
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap$CIMEntry.access$700(CaseInsensitiveMap.java:39)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:476)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:451)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:387)
~[commons-5.4.0.jar:na]
at
org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.assembleJavascriptResourceForStack(JavaScriptStackAssemblerImpl.java:115)
~[tapestry-core-5.4.0.jar:na]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2505) Different behavior of ElementWrapper.visible with jQuery and Prototype
[
https://issues.apache.org/jira/browse/TAP5-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2505:
-
Component/s: tapestry-core
> Different behavior of ElementWrapper.visible with jQuery and Prototype
> --
>
> Key: TAP5-2505
> URL: https://issues.apache.org/jira/browse/TAP5-2505
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Jochen Kemnade
>
> If an element is hidden via a CSS class, {{dom(element).visible()}} will
> return {{false}} with jQuery and {{true}} with Prototype.
> This is because the jQuery implementation checks the display style whereas
> the Prototype implementation uses Element.visible
> {{http://api.prototypejs.org/dom/Element/visible/}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-1377) Combine CSS files in production mode
[
https://issues.apache.org/jira/browse/TAP5-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035511#comment-15035511
]
Jochen Kemnade commented on TAP5-1377:
--
I just had another idea: Stylesheets can be added to JavaScriptStacks. We could
just wrap those stylesheets in some code that creates dynamic stylesheets using
{{document.createElement('style')}}. That way, they could be included in the
stack like a regular JS file.
> 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.3, 5.4, 5.2
>Reporter: Dan Adams
> Labels: patch
> Attachments: 0002-TAP5-1377-Combine-CSS-files-in-production-mode.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-1772) IOC Circular dependency results in StackOverflowError
[ https://issues.apache.org/jira/browse/TAP5-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-1772: - Attachment: 0001-TAP5-1772-add-test.patch I created a test case. > IOC Circular dependency results in StackOverflowError > - > > Key: TAP5-1772 > URL: https://issues.apache.org/jira/browse/TAP5-1772 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-ioc >Affects Versions: 5.3, 5.4 >Reporter: Denis Stepanov > Attachments: 0001-TAP5-1772-add-test.patch > > > ERROR org.apache.tapestry5.ioc.Registry - java.lang.StackOverflowError > ERROR org.apache.tapestry5.ioc.Registry - Operations trace: > ERROR org.apache.tapestry5.ioc.Registry - [ 1] Resolving object of type > org.test.ServiceA using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [ 2] Creating non-proxied instance > of service ServiceA > ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating plan to instantiate > org.test.ServiceA via public org.test.ServiceA() > ERROR org.apache.tapestry5.ioc.Registry - [ 4] Calculating possible injection > value for field org.test.ServiceA.serviceB(org.test.ServiceB) > ERROR org.apache.tapestry5.ioc.Registry - [ 5] Resolving object of type > org.test.ServiceB using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [ 6] Creating non-proxied instance > of service ServiceB > ERROR org.apache.tapestry5.ioc.Registry - [ 7] Creating plan to instantiate > org.test.ServiceB via public org.test.ServiceB() > ERROR org.apache.tapestry5.ioc.Registry - [ 8] Calculating possible injection > value for field org.test.ServiceB.serviceA (org.test.ServiceA) > ERROR org.apache.tapestry5.ioc.Registry - [ 9] Resolving object of type > org.test.ServiceA using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [10] Creating non-proxied instance > of service ServiceA > goto 3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-1772) IOC Circular dependency results in StackOverflowError
[ https://issues.apache.org/jira/browse/TAP5-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-1772: - Affects Version/s: 5.4 > IOC Circular dependency results in StackOverflowError > - > > Key: TAP5-1772 > URL: https://issues.apache.org/jira/browse/TAP5-1772 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-ioc >Affects Versions: 5.3, 5.4 >Reporter: Denis Stepanov > Attachments: 0001-TAP5-1772-add-test.patch > > > ERROR org.apache.tapestry5.ioc.Registry - java.lang.StackOverflowError > ERROR org.apache.tapestry5.ioc.Registry - Operations trace: > ERROR org.apache.tapestry5.ioc.Registry - [ 1] Resolving object of type > org.test.ServiceA using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [ 2] Creating non-proxied instance > of service ServiceA > ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating plan to instantiate > org.test.ServiceA via public org.test.ServiceA() > ERROR org.apache.tapestry5.ioc.Registry - [ 4] Calculating possible injection > value for field org.test.ServiceA.serviceB(org.test.ServiceB) > ERROR org.apache.tapestry5.ioc.Registry - [ 5] Resolving object of type > org.test.ServiceB using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [ 6] Creating non-proxied instance > of service ServiceB > ERROR org.apache.tapestry5.ioc.Registry - [ 7] Creating plan to instantiate > org.test.ServiceB via public org.test.ServiceB() > ERROR org.apache.tapestry5.ioc.Registry - [ 8] Calculating possible injection > value for field org.test.ServiceB.serviceA (org.test.ServiceA) > ERROR org.apache.tapestry5.ioc.Registry - [ 9] Resolving object of type > org.test.ServiceA using MasterObjectProvider > ERROR org.apache.tapestry5.ioc.Registry - [10] Creating non-proxied instance > of service ServiceA > goto 3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2225) Create client-side API to call a component's event handler methods
[ https://issues.apache.org/jira/browse/TAP5-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028331#comment-15028331 ] Jochen Kemnade commented on TAP5-2225: -- That sounds like a more sophisticated approach, but might be a little more complicated to use. Should the module really check which events are handled? We do that server-side anyway and currently, you can also create an eventlink for an event that is not handled. Do you have an idea how you could create an event link for an embedded component? I cannot think of a solution where you wouldn't have to pass the component's id. By "non-nested pages"; I meant those that are not in a "subdirectory". That might work but I haven't tested it so far. > Create client-side API to call a component's event handler methods > -- > > Key: TAP5-2225 > URL: https://issues.apache.org/jira/browse/TAP5-2225 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Jochen Kemnade >Assignee: Thiago H. de Paula Figueiredo > Labels: ajax, event, handler, javascript > > It should be possible to create URLs for components' event handlers on the > client side. > There could be a function that mirrors the behavior of > ComponentResources#createEventLink. It might be passed an event name or an > object with additional information such as a page name, a request context, or > additional request parameters. > The function could either return the URL or a function that makes an XHR and > passes the response to a callback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2225) Create client-side API to call a component's event handler methods
[
https://issues.apache.org/jira/browse/TAP5-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028641#comment-15028641
]
Jochen Kemnade commented on TAP5-2225:
--
{quote}
What do you mean by module?
{quote}
JavaScript module, like in AMD.
{quote}
Creating event links for embedded components, IMHO, is something that should be
avoided.
{quote}
Oh, misunderstanding, I meant components that are embedded in a page. But you
already answered the question: by passing the domElement to the function.
About the signature:
Yes, I can see how you would find the component walking upward from
{{domElement}}. Maybe that parameter could be optional to trigger the event on
the page class? That's what I do currently.
It should be possible to pass request parameters as well as event context (like
in {{page:event/context?param=foo}}).
I'm not sure about successHandler and failureHandler. Do you think they should
be mandatory? I usually try to avoid callbacks and rather use
AjaxResponseRenderer on the server side.
About the subdirectory pages: Sure, that should work, I just haven't tested it
with my quick solution yet.
> Create client-side API to call a component's event handler methods
> --
>
> Key: TAP5-2225
> URL: https://issues.apache.org/jira/browse/TAP5-2225
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Thiago H. de Paula Figueiredo
> Labels: ajax, event, handler, javascript
>
> It should be possible to create URLs for components' event handlers on the
> client side.
> There could be a function that mirrors the behavior of
> ComponentResources#createEventLink. It might be passed an event name or an
> object with additional information such as a page name, a request context, or
> additional request parameters.
> The function could either return the URL or a function that makes an XHR and
> passes the response to a callback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2515) Grid's empty parameter is not used if renderTableIfEmpty is true
Jochen Kemnade created TAP5-2515:
Summary: Grid's empty parameter is not used if renderTableIfEmpty
is true
Key: TAP5-2515
URL: https://issues.apache.org/jira/browse/TAP5-2515
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
{code}
{code}
Will render "There is no data to display." inside the td. We should probably
not delegate to {{block:empty}} in {{Grid.tml:13}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2516) ArrayIndexOutOfBoundsException when trying to report a template parsing error
Jochen Kemnade created TAP5-2516:
Summary: ArrayIndexOutOfBoundsException when trying to report a
template parsing error
Key: TAP5-2516
URL: https://issues.apache.org/jira/browse/TAP5-2516
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
Priority: Minor
{code}
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:418)
~[na:1.8.0_72-internal]
at java.util.ArrayList.get(ArrayList.java:431) ~[na:1.8.0_72-internal]
at
org.apache.tapestry5.internal.services.XMLTokenStream.token(XMLTokenStream.java:433)
~[tapestry-core-5.4-rc-1.jar:na]
at
org.apache.tapestry5.internal.services.XMLTokenStream.getLocation(XMLTokenStream.java:478)
~[tapestry-core-5.4-rc-1.jar:na]
at
org.apache.tapestry5.internal.services.SaxTemplateParser.parse(SaxTemplateParser.java:181)
~[tapestry-core-5.4-rc-1.jar:na]
at
org.apache.tapestry5.internal.services.TemplateParserImpl$1.invoke(TemplateParserImpl.java:61)
~[tapestry-core-5.4-rc-1.jar:na]
at
org.apache.tapestry5.internal.services.TemplateParserImpl$1.invoke(TemplateParserImpl.java:58)
~[tapestry-core-5.4-rc-1.jar:na]
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:82)
~[tapestry-ioc-5.4-rc-1.jar:na]
... 158 common frames omitted
{code}
The exeption that we're trying to report is an IOException:
{code}
java.io.IOException: Cannot open a steam for a resource that references a
directory inside a JAR file
(jar:file:/home/jochen/.gradle/caches/modules-2/files-2.1/org.apache.tapestry/tapestry-core/5.4-rc-1/94f01ef2bc48c66a8927cd814c885d218caab3fe/tapestry-core-5.4-rc-1.jar!/org/apache/tapestry5/corelib/components/Grid.tml).
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2517) Wrong exception reported for duplicate classpath resource
[
https://issues.apache.org/jira/browse/TAP5-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2517.
Resolution: Fixed
Assignee: Jochen Kemnade
Fix Version/s: 5.4
> Wrong exception reported for duplicate classpath resource
> -
>
> Key: TAP5-2517
> URL: https://issues.apache.org/jira/browse/TAP5-2517
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Jochen Kemnade
>Priority: Minor
> Fix For: 5.4
>
>
> Trying to work around a bug in Grid, I copied the Grid.tml file from the
> tapestry-core jar into my project into the same package.
> When Tapestry tries to load the resource, I get an exception that says
> {{java.io.IOException: Cannot open a steam for a resource that references a
> directory inside a JAR file
> (jar:file:/home/jochen/.gradle/caches/modules-2/files-2.1/org.apache.tapestry/tapestry-core/5.4-rc-1/94f01ef2bc48c66a8927cd814c885d218caab3fe/tapestry-core-5.4-rc-1.jar!/org/apache/tapestry5/corelib/components/Grid.tml)}}.
> This is not correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2517) Wrong exception reported for duplicate classpath resource
Jochen Kemnade created TAP5-2517:
Summary: Wrong exception reported for duplicate classpath resource
Key: TAP5-2517
URL: https://issues.apache.org/jira/browse/TAP5-2517
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-ioc
Affects Versions: 5.4
Reporter: Jochen Kemnade
Priority: Minor
Trying to work around a bug in Grid, I copied the Grid.tml file from the
tapestry-core jar into my project into the same package.
When Tapestry tries to load the resource, I get an exception that says
{{java.io.IOException: Cannot open a steam for a resource that references a
directory inside a JAR file
(jar:file:/home/jochen/.gradle/caches/modules-2/files-2.1/org.apache.tapestry/tapestry-core/5.4-rc-1/94f01ef2bc48c66a8927cd814c885d218caab3fe/tapestry-core-5.4-rc-1.jar!/org/apache/tapestry5/corelib/components/Grid.tml)}}.
This is not correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2515) Grid's empty parameter is not used if renderTableIfEmpty is true
[
https://issues.apache.org/jira/browse/TAP5-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2515:
-
Description:
{code}
{code}
will render "There is no data to display." inside the td. We should probably
not delegate to {{block:empty}} in {{Grid.tml:13}}.
was:
{code}
{code}
Will render "There is no data to display." inside the td. We should probably
not delegate to {{block:empty}} in {{Grid.tml:13}}.
> Grid's empty parameter is not used if renderTableIfEmpty is true
>
>
> Key: TAP5-2515
> URL: https://issues.apache.org/jira/browse/TAP5-2515
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> {code}
>
> {code}
> will render "There is no data to display." inside the td. We should probably
> not delegate to {{block:empty}} in {{Grid.tml:13}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2515) Grid's empty parameter is not used if renderTableIfEmpty is true
[
https://issues.apache.org/jira/browse/TAP5-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2515.
Resolution: Fixed
Assignee: Jochen Kemnade
Fix Version/s: 5.4
> Grid's empty parameter is not used if renderTableIfEmpty is true
>
>
> Key: TAP5-2515
> URL: https://issues.apache.org/jira/browse/TAP5-2515
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Jochen Kemnade
> Fix For: 5.4
>
>
> {code}
>
> {code}
> will render "There is no data to display." inside the td. We should probably
> not delegate to {{block:empty}} in {{Grid.tml:13}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2516) ArrayIndexOutOfBoundsException when trying to report a template parsing error
[
https://issues.apache.org/jira/browse/TAP5-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2516.
Resolution: Fixed
Assignee: Jochen Kemnade
Fix Version/s: 5.4
> ArrayIndexOutOfBoundsException when trying to report a template parsing error
> -
>
> Key: TAP5-2516
> URL: https://issues.apache.org/jira/browse/TAP5-2516
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Jochen Kemnade
>Priority: Minor
> Fix For: 5.4
>
>
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at java.util.ArrayList.elementData(ArrayList.java:418)
> ~[na:1.8.0_72-internal]
> at java.util.ArrayList.get(ArrayList.java:431) ~[na:1.8.0_72-internal]
> at
> org.apache.tapestry5.internal.services.XMLTokenStream.token(XMLTokenStream.java:433)
> ~[tapestry-core-5.4-rc-1.jar:na]
> at
> org.apache.tapestry5.internal.services.XMLTokenStream.getLocation(XMLTokenStream.java:478)
> ~[tapestry-core-5.4-rc-1.jar:na]
> at
> org.apache.tapestry5.internal.services.SaxTemplateParser.parse(SaxTemplateParser.java:181)
> ~[tapestry-core-5.4-rc-1.jar:na]
> at
> org.apache.tapestry5.internal.services.TemplateParserImpl$1.invoke(TemplateParserImpl.java:61)
> ~[tapestry-core-5.4-rc-1.jar:na]
> at
> org.apache.tapestry5.internal.services.TemplateParserImpl$1.invoke(TemplateParserImpl.java:58)
> ~[tapestry-core-5.4-rc-1.jar:na]
> at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:82)
> ~[tapestry-ioc-5.4-rc-1.jar:na]
> ... 158 common frames omitted
> {code}
> The exeption that we're trying to report is an IOException:
> {code}
> java.io.IOException: Cannot open a steam for a resource that references a
> directory inside a JAR file
> (jar:file:/home/jochen/.gradle/caches/modules-2/files-2.1/org.apache.tapestry/tapestry-core/5.4-rc-1/94f01ef2bc48c66a8927cd814c885d218caab3fe/tapestry-core-5.4-rc-1.jar!/org/apache/tapestry5/corelib/components/Grid.tml).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2225) Create client-side API to call a component's event handler methods
[
https://issues.apache.org/jira/browse/TAP5-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002426#comment-15002426
]
Jochen Kemnade commented on TAP5-2225:
--
[~thiagohp], do you still intend to work on this?
I've started progress on a simple JS module that works for simple events on
non-nested pages. It uses {{window.location}} and string concatenation and is
still very basic.
> Create client-side API to call a component's event handler methods
> --
>
> Key: TAP5-2225
> URL: https://issues.apache.org/jira/browse/TAP5-2225
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Thiago H. de Paula Figueiredo
> Labels: ajax, event, handler, javascript
>
> It should be possible to create URLs for components' event handlers on the
> client side.
> There could be a function that mirrors the behavior of
> ComponentResources#createEventLink. It might be passed an event name or an
> object with additional information such as a page name, a request context, or
> additional request parameters.
> The function could either return the URL or a function that makes an XHR and
> passes the response to a callback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2514) Bootstrap library dependencies not loaded on Firefox
[
https://issues.apache.org/jira/browse/TAP5-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000671#comment-15000671
]
Jochen Kemnade commented on TAP5-2514:
--
I still cannot reproduce this, maybe it only happens on Windows.
When you open the `popover.js` file in the debugger, is it actually wrapped as
an AMD module, i.e. does it start with
{code}
define(["bootstrap/tooltip"], function(){
{code}
?
> Bootstrap library dependencies not loaded on Firefox
>
>
> Key: TAP5-2514
> URL: https://issues.apache.org/jira/browse/TAP5-2514
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: I D
>
> This issue was introduced by [this
> commit|https://github.com/apache/tapestry-5/commit/af356865f29b721c61f1753b62ea012fd5d6abc4].
> Steps to reproduce:
> 1. Create your own trivial js module (e.g. a no-op module named "no-op").
> 1. In your module, require "bootstrap/popover" by including it in the array
> passed as the first parameter to the define() call.
> 1. Load your module from any page, using JavascriptSupport.require().
> 1. Open the page in firefox. Open the debugger and note that popover.js was
> loaded, while tooltip wasn't. Also note the js exception thrown by
> popover.js: "popover requires tooltip.js".
> This has also been observed on chrome, but sporadically.
> Workaround: add this code to AppModule or any of its submodules (essentially
> reverts the commit that introduced the issue):
> {code:java}
> @Contribute(ModuleManager.class)
> public static void setupBaseModules(MappedConfiguration
> configuration, @Path("${" + SymbolConstants.BOOTSTRAP_ROOT +
> "}/js/transition.js") Resource transition) {
> configuration.override("bootstrap/transition", new
> JavaScriptModuleConfiguration(transition).dependsOn("jquery"));
> for (String name : new String[]{"affix", "alert", "button", "carousel",
> "collapse", "dropdown", "modal", "scrollspy", "tab", "tooltip"}) {
> Resource lib = transition.forFile(name + ".js");
> configuration.override("bootstrap/" + name, new
> JavaScriptModuleConfiguration(lib).dependsOn("bootstrap/transition"));
> }
> Resource popover = transition.forFile("popover.js");
> configuration.override("bootstrap/popover", new
> JavaScriptModuleConfiguration(popover).dependsOn("bootstrap/tooltip"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2514) Bootstrap library dependencies not loaded on Firefox
[
https://issues.apache.org/jira/browse/TAP5-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000706#comment-15000706
]
Jochen Kemnade commented on TAP5-2514:
--
It shouldn't have done that. Why do the old modules stick around? Apparently
it's not a Firefox-only issue since you experienced it in Chrome too.
> Bootstrap library dependencies not loaded on Firefox
>
>
> Key: TAP5-2514
> URL: https://issues.apache.org/jira/browse/TAP5-2514
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: I D
>
> This issue was introduced by [this
> commit|https://github.com/apache/tapestry-5/commit/af356865f29b721c61f1753b62ea012fd5d6abc4].
> Steps to reproduce:
> 1. Create your own trivial js module (e.g. a no-op module named "no-op").
> 1. In your module, require "bootstrap/popover" by including it in the array
> passed as the first parameter to the define() call.
> 1. Load your module from any page, using JavascriptSupport.require().
> 1. Open the page in firefox. Open the debugger and note that popover.js was
> loaded, while tooltip wasn't. Also note the js exception thrown by
> popover.js: "popover requires tooltip.js".
> This has also been observed on chrome, but sporadically.
> Workaround: add this code to AppModule or any of its submodules (essentially
> reverts the commit that introduced the issue):
> {code:java}
> @Contribute(ModuleManager.class)
> public static void setupBaseModules(MappedConfiguration
> configuration, @Path("${" + SymbolConstants.BOOTSTRAP_ROOT +
> "}/js/transition.js") Resource transition) {
> configuration.override("bootstrap/transition", new
> JavaScriptModuleConfiguration(transition).dependsOn("jquery"));
> for (String name : new String[]{"affix", "alert", "button", "carousel",
> "collapse", "dropdown", "modal", "scrollspy", "tab", "tooltip"}) {
> Resource lib = transition.forFile(name + ".js");
> configuration.override("bootstrap/" + name, new
> JavaScriptModuleConfiguration(lib).dependsOn("bootstrap/transition"));
> }
> Resource popover = transition.forFile("popover.js");
> configuration.override("bootstrap/popover", new
> JavaScriptModuleConfiguration(popover).dependsOn("bootstrap/tooltip"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2514) Bootstrap library dependencies not loaded on Firefox
[
https://issues.apache.org/jira/browse/TAP5-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000579#comment-15000579
]
Jochen Kemnade commented on TAP5-2514:
--
I cannot reproduce this issue. Which browser are you experiencing this with,
and in which environment?
> Bootstrap library dependencies not loaded on Firefox
>
>
> Key: TAP5-2514
> URL: https://issues.apache.org/jira/browse/TAP5-2514
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: I D
>
> This issue was introduced by [this
> commit|https://github.com/apache/tapestry-5/commit/af356865f29b721c61f1753b62ea012fd5d6abc4].
> Steps to reproduce:
> 1. Create your own trivial js module (e.g. a no-op module named "no-op").
> 1. In your module, require "bootstrap/popover" by including it in the array
> passed as the first parameter to the define() call.
> 1. Load your module from any page, using JavascriptSupport.require().
> 1. Open the page in firefox. Open the debugger and note that popover.js was
> loaded, while tooltip wasn't. Also note the js exception thrown by
> popover.js: "popover requires tooltip.js".
> This has also been observed on chrome, but sporadically.
> Workaround: add this code to AppModule or any of its submodules (essentially
> reverts the commit that introduced the issue):
> {code:java}
> @Contribute(ModuleManager.class)
> public static void setupBaseModules(MappedConfiguration
> configuration, @Path("${" + SymbolConstants.BOOTSTRAP_ROOT +
> "}/js/transition.js") Resource transition) {
> configuration.override("bootstrap/transition", new
> JavaScriptModuleConfiguration(transition).dependsOn("jquery"));
> for (String name : new String[]{"affix", "alert", "button", "carousel",
> "collapse", "dropdown", "modal", "scrollspy", "tab", "tooltip"}) {
> Resource lib = transition.forFile(name + ".js");
> configuration.override("bootstrap/" + name, new
> JavaScriptModuleConfiguration(lib).dependsOn("bootstrap/transition"));
> }
> Resource popover = transition.forFile("popover.js");
> configuration.override("bootstrap/popover", new
> JavaScriptModuleConfiguration(popover).dependsOn("bootstrap/tooltip"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2513) Specifying a regexp validation rule where the pattern contains a comma breaks
[
https://issues.apache.org/jira/browse/TAP5-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2513:
-
Labels: patch (was: )
> Specifying a regexp validation rule where the pattern contains a comma breaks
> -
>
> Key: TAP5-2513
> URL: https://issues.apache.org/jira/browse/TAP5-2513
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Labels: patch
> Attachments:
> TAP5_2513_Specifying_a_regexp_validation_rule_where_the_pattern_contains_a_comma_breaks.patch
>
>
> I tried to do the following:
> {code}
> @Component( parameters = { "value=value",
> "validate=regexp=[0-9a-fA-F]{3,6}" } )
> private TextField myField;
> {code}
> Tapestry complains about the regexp pattern not being valid (in particular
> that the "6" is unexpected. This is due to the parser in
> (FieldValidatorSourceImpl) expecting that comma only exist to separate
> validator rules.
> Similar issues seem to have already been fixed for the other ways to express
> regexp constraints (TAP5-520).
> It seems that there are several different ways implemented to extract the
> validation rules currently, I tried replacing the code in
> FieldValidatorSourceImpl with the code used in
> (ValidateAnnotationConstraintGenerator / FieldValidatorDefaultSourceImpl ) -
> It seems to produce the correct results at runtime, but will probably require
> some unit test adjustments, as the char-by-char parser have been replaced (it
> looks like a decent error message is still produced when an invalid pattern
> is specified, but it is another place that returns the error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[ https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2490. Resolution: Fixed Assignee: Jochen Kemnade Fix Version/s: 5.4 > Autocomplete and Select context values does not work when context has to pass > through a value encoder > - > > Key: TAP5-2490 > URL: https://issues.apache.org/jira/browse/TAP5-2490 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Dimitris Zenios >Assignee: Jochen Kemnade > Fix For: 5.4 > > Attachments: > 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch > > > Context passed down to select and autocomplete should be send as is > (UrlEventContext) to parent container instead of coercing it to List > context first -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2075) Checkbox doesn't trigger VALIDATE event
[ https://issues.apache.org/jira/browse/TAP5-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2075: - Labels: patch (was: ) > Checkbox doesn't trigger VALIDATE event > --- > > Key: TAP5-2075 > URL: https://issues.apache.org/jira/browse/TAP5-2075 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.6, 5.4 >Reporter: Geoff Callender >Assignee: Thiago H. de Paula Figueiredo > Labels: patch > Attachments: > 0006-TAP5-2075-Checkbox-doesn-t-trigger-VALIDATE-event.patch > > > Imagine a list of entries with a "delete" checkbox on each row. > When submitted, I would like to validate each checked row to decide whether > it is OK to delete. > I can write an event handler, onValidateFromDelete(), but it will never be > called because Checkbox doesn't bubble up the VALIDATE event. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[ https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2509. Resolution: Fixed Assignee: Jochen Kemnade Fix Version/s: 5.4 I changed it to a client-side warning in development mode. > Regression with radiogroup label in 5.4-beta-37 > --- > > Key: TAP5-2509 > URL: https://issues.apache.org/jira/browse/TAP5-2509 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen >Assignee: Jochen Kemnade > Fix For: 5.4 > > Attachments: t54-radiogrouplabel.zip > > > Having a label for a radio group fails in 5.4 beta 37, while it works up > until beta-36. > The error is: > Render queue error in AfterRender[Index:form]: The field has returned a null > client-side ID > See the attached project for an example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2204) Select component fails if SelectModel doesn't exist on submit
[
https://issues.apache.org/jira/browse/TAP5-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2204.
Resolution: Fixed
Assignee: Jochen Kemnade
Fix Version/s: 5.4
> Select component fails if SelectModel doesn't exist on submit
> -
>
> Key: TAP5-2204
> URL: https://issues.apache.org/jira/browse/TAP5-2204
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: George Christman
>Assignee: Jochen Kemnade
> Fix For: 5.4
>
>
> The SelectModel is now being used on form render AND submission whereas it
> used to be used only on render of the form. This is a big deal
> performance-wise because creation of the SelectModel commonly involves a
> database query to populated a list of
> objects.
> This appears to be a regression bug starting in 5.4.21.
> Nabble post
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Re-T5-4-ajax-select-menu-bug-td5724142.html
> Sample code and stack trace.
> Geoff example
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/selectmore1
> or
> http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
> xmlns:p="tapestry:parameter">
>
> t:zone="ajaxZone"/>
>
> t:model="monitorModels"/>
>
>
>
> public class SelectDemo {
> @Property
> private Computer computer;
> @Property
> private Monitor monitor;
> @Property
> private SelectModel computerModels;
> @Property
> private SelectModel monitorModels;
> @Inject
> private SelectModelFactory selectModelFactory;
> @InjectComponent
> private Zone ajaxZone;
> @Inject
> private Session session;
> public void setupRender() {
> List computers =
> session.createCriteria(Computer.class).list();
> computerModels = selectModelFactory.create(computers, "name");
> monitorModels = selectModelFactory.create(new ArrayList<>());
> }
> Object onValueChangedFromComputer(Computer computer) {
> List monitors =
> session.createCriteria(Monitor.class).add(Restrictions.eq("computer",
> computer)).list();
> monitorModels = selectModelFactory.create(monitors, "name");
> return ajaxZone.getBody();
> }
> }
> The full stack trace
>- Application Exception
>-
>-
>Tapestry Version: 5.4-alpha-22
>-
>-
>Application Version: 1.1-SNAPSHOT-DEV
> An exception has occurred processing this request.
> Parameter 'model' of component SelectDemo:computer is bound to null. This
> parameter is not allowed to be null.
> org.apache.tapestry5.ioc.internal.OperationException
> *Parameter 'model' of component SelectDemo:computer is bound to null. This
> parameter is not allowed to be null.*
> locationclasspath:org/company/tapdemo/pages/SelectDemo.tml, line 31 t:type="layout" t:title="Select Demo" xmlns:t="
> http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
> xmlns:p="tapestry:parameter">2 3 t:type="select" t:id="computer" t:model="computerModels" t:zone="ajaxZone"/>
> 4
> 5 6 t:id="monitor" t:model="monitorModels"/>7 8 trace
>- Handling Ajax 'change' component event request for SelectDemo:computer.
>- Triggering event 'change' on SelectDemo:computer
> org.apache.tapestry5.runtime.ComponentEventException
> *Parameter 'model' of component SelectDemo:computer is bound to null. This
> parameter is not allowed to be null.*
> context
> eventTypechangelocationclasspath:org/company/tapdemo/pages/SelectDemo.tml,
> line 3
> org.apache.tapestry5.ioc.internal.util.TapestryException
> *Parameter 'model' of component SelectDemo:computer is bound to null. This
> parameter is not allowed to be null.*
> locationclasspath:org/company/tapdemo/pages/SelectDemo.tml, line 3
> Filter Frames?
> Stack trace:
>-
> org.apache.tapestry5.internal.transform.ParameterWorker$3$1.readFromBinding(ParameterWorker.java:275)
>-
> org.apache.tapestry5.internal.transform.ParameterWorker$3$1.get(ParameterWorker.java:381)
>-
> org.apache.tapestry5.corelib.components.Select.findValueInModel(Select.java:273)
>- org.apache.tapestry5.corelib.components.Select.toValue(Select.java:262)
>- org.apache.tapestry5.corelib.components.Select.onChange(Select.java:238)
>-
> org.apache.tapestry5.corelib.components.Select.dispatchComponentEvent(Select.java)
>-
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:950)
>-
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.processEventTriggering(ComponentPageElementImpl.java:1127)
>-
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$5.invoke(ComponentPageElementImpl.java:1072)
>-
>
[jira] [Closed] (TAP5-1886) DateField is not localized correctly
[ https://issues.apache.org/jira/browse/TAP5-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-1886. Resolution: Fixed Assignee: Jochen Kemnade Fix Version/s: 5.4 > DateField is not localized correctly > > > Key: TAP5-1886 > URL: https://issues.apache.org/jira/browse/TAP5-1886 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2, 5.4 >Reporter: Rural Hunter >Assignee: Jochen Kemnade > Labels: datefield > Fix For: 5.4 > > > My locale is Chinese. The DateField component displays badly with Chinese. > 1. The weekday is cut wrongly > in Chinese, weekday has 3 characters, such as '星期一', '星期二', '星期三'. the > difference is on the 3rd character. But DateField just cut the first > character to display. it means all weekdays in Chinese are displayed as '星'. > 2. The 'Today' and 'None' buttons are fix-labeled and not translated. > I hope DateField will have a language properties file to localize those text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[
https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991903#comment-14991903
]
Jochen Kemnade commented on TAP5-2490:
--
For Select, this turns out to be much more complicated than expected depending
on the types of the context values and whether the {{encoder}} parameter is
bound or not. What if the {{encoder}} and the {{encoder}} have the same type, a
global value encoder is registered for the type and a different value encoder
is passed via the {{encoder}} parameter? Even then, the global encoder should
be used if I'm not mistaken, so my last commit is was probably not the correct
way to fix this. I'll have another look tomorrow.
> Autocomplete and Select context values does not work when context has to pass
> through a value encoder
> -
>
> Key: TAP5-2490
> URL: https://issues.apache.org/jira/browse/TAP5-2490
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Dimitris Zenios
> Attachments:
> 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch
>
>
> Context passed down to select and autocomplete should be send as is
> (UrlEventContext) to parent container instead of coercing it to List
> context first
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[
https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991903#comment-14991903
]
Jochen Kemnade edited comment on TAP5-2490 at 11/5/15 5:09 PM:
---
For Select, this turns out to be much more complicated than expected depending
on the types of the context values and whether the {{encoder}} parameter is
bound or not. What if the {{value}} and the {{context}} have the same type, a
global value encoder is registered for that type and a different value encoder
is passed via the {{encoder}} parameter? Even then, the global encoder should
be used if I'm not mistaken, so my last commit is was probably not the correct
way to fix this. I'll have another look tomorrow.
was (Author: jkemnade):
For Select, this turns out to be much more complicated than expected depending
on the types of the context values and whether the {{encoder}} parameter is
bound or not. What if the {{encoder}} and the {{encoder}} have the same type, a
global value encoder is registered for the type and a different value encoder
is passed via the {{encoder}} parameter? Even then, the global encoder should
be used if I'm not mistaken, so my last commit is was probably not the correct
way to fix this. I'll have another look tomorrow.
> Autocomplete and Select context values does not work when context has to pass
> through a value encoder
> -
>
> Key: TAP5-2490
> URL: https://issues.apache.org/jira/browse/TAP5-2490
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Dimitris Zenios
> Attachments:
> 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch
>
>
> Context passed down to select and autocomplete should be send as is
> (UrlEventContext) to parent container instead of coercing it to List
> context first
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[
https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989520#comment-14989520
]
Jochen Kemnade commented on TAP5-2509:
--
Well, TAP5-2500 did not force the change. I just assumed that the usual use
case for the Label component is to be able to render a label for a field and to
expect the label to have the correct {{for}} attribute. If the client ID is
null, we cannot render a proper {{for}} attribute and instead of producing a
potentially undesired result (label *without* for attribute), we should tell
the user that there is a problem. Maybe we should rather log a warning than
throw an exception.
> Regression with radiogroup label in 5.4-beta-37
> ---
>
> Key: TAP5-2509
> URL: https://issues.apache.org/jira/browse/TAP5-2509
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-radiogrouplabel.zip
>
>
> Having a label for a radio group fails in 5.4 beta 37, while it works up
> until beta-36.
> The error is:
> Render queue error in AfterRender[Index:form]: The field has returned a null
> client-side ID
> See the attached project for an example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2038) Many images in the Tapestry component examples are now very out of date
[
https://issues.apache.org/jira/browse/TAP5-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973929#comment-14973929
]
Jochen Kemnade commented on TAP5-2038:
--
You can always run the app1 test app from the tapestry-core package (run
{{./gradlew tapestry-core:runTestApp1}} from the base directory) to create
up-to-date images.
> Many images in the Tapestry component examples are now very out of date
> ---
>
> Key: TAP5-2038
> URL: https://issues.apache.org/jira/browse/TAP5-2038
> Project: Tapestry 5
> Issue Type: Task
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Howard M. Lewis Ship
> Labels: documentation
>
> It might be nice to create a real test application and keep it around, to
> help with generating these screen grabs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2482) BeanEditForm field name regression introduced with 5.4-beta-31
[
https://issues.apache.org/jira/browse/TAP5-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2482.
Resolution: Fixed
Assignee: Jochen Kemnade
Fix Version/s: 5.4
I rolled back {{22bd2c14b3c7d91ebd97cbc264882552c12044f7}}.
> BeanEditForm field name regression introduced with 5.4-beta-31
> --
>
> Key: TAP5-2482
> URL: https://issues.apache.org/jira/browse/TAP5-2482
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Balázs Palcsó
>Assignee: Jochen Kemnade
> Labels: 54_release_prerequisite
> Fix For: 5.4
>
>
> Issue started with: 5.4-beta-31
> Last working release: 5.4-beta-30
> I have the below BeanEditForm
> {code}
>
> include="username,lastName,firstName,email,phone,password,confirmPassword">
>
>
>
>t:mixins="OverrideFieldFocus" />
>
>
>
>
>
>/>
>
>
>
>
>
>value="user.confirmPassword" />
>
>
>
> {code}
> The {{name}} attribute of the input generated for each included fields were
> matching the field name until 5.4-beta-31.
> With 5.4-beta-31 the above form generates the following name attribute for
> {{}} for
> {{name="textField"}} instead of {{name="lastName"}}
> {{name="textField_0"}} instead of {{name="firstName"}}
> {{name="textField_1"}} instead of {{name="phone"}}
> For username, email, password, confirmPassword correct name attributes are
> generated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2367) Add an "alwaysSubmit" parameter to AjaxFormLoop
[ https://issues.apache.org/jira/browse/TAP5-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2367: - Labels: patch (was: ) > Add an "alwaysSubmit" parameter to AjaxFormLoop > --- > > Key: TAP5-2367 > URL: https://issues.apache.org/jira/browse/TAP5-2367 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Felix Scheffer >Priority: Minor > Labels: patch > Attachments: > 0001-TAP5-2367-Add-an-alwaysSubmit-parameter-to-AjaxFormL.patch > > > Currently an AjaxFormLoop that is hidden (for example in another tab or as > part of a wizard) is not submitted. It would be great to have an alwaysSubmit > parameter similar to the one in FormFragment. > This feature was also suggested on the mailing list some time ago: > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Add-additional-parameter-to-AjaxFormLoop-td5719977.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2255) Form and BeanEditForm differ in JSR-303 detection
[
https://issues.apache.org/jira/browse/TAP5-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14974377#comment-14974377
]
Jochen Kemnade commented on TAP5-2255:
--
I just tried this with a simplified example and at least BeanEditForm seems to
pick up the annotation on the field as well as on the getter.
[~geoffcallender], does this affect custom data-type properties only?
> Form and BeanEditForm differ in JSR-303 detection
> -
>
> Key: TAP5-2255
> URL: https://issues.apache.org/jira/browse/TAP5-2255
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-beanvalidator, tapestry-core
>Affects Versions: 5.4
>Reporter: Geoff Callender
>
> I have an entity field that the getter and setter convert between types
> (field is Date, getter and setter convert from/to JodaTime's DateMidnight).
> Form detects @NotNull on the field, but BeanEditForm doesn't. BeanEditForm
> detects @NotNull on the getter, but Form doesn't. So I have to provide
> @NotNull on the field AND the getter. Shouldn't Form and BeanEditForm behave
> the same?
> For example, a snippet from an entity:
> {code}
> @Entity
> public class DatesExample implements Serializable {
> // This JSR-303 validation will be picked up by Form.
> @NotNull
> private java.sql.Date aDateMidnight;
> // This JSR-303 validation will be picked up by BeanEditForm.
> @NotNull
> public DateMidnight getADateMidnight() {
> return JodaTimeUtil.toDateMidnight(aDateMidnight);
> }
> public void setADateMidnight(DateMidnight dm) {
> this.aDateMidnight = JodaTimeUtil.toSQLDate(dm);
> }
> }
> {code}
> I've contributed type coercers in AppModule:
> {code}
> public static void contributeTypeCoercer(Configuration
> configuration) {
>// From java.util.Date to DateMidnight
> Coercion toDateMidnight = new
> Coercion() {
> public DateMidnight coerce(java.util.Date input) {
> // TODO - confirm this conversion always works, esp. across
> timezones
> return JodaTimeUtil.toDateMidnight(input);
> }
> };
> configuration.add(new CoercionTuple<>(java.util.Date.class,
> DateMidnight.class, toDateMidnight));
> // From DateMidnight to java.util.Date
> Coercion fromDateMidnight = new
> Coercion() {
> public java.util.Date coerce(DateMidnight input) {
> // TODO - confirm this conversion always works, esp. across
> timezones
> return JodaTimeUtil.toJavaDate(input);
> }
> };
> configuration.add(new CoercionTuple<>(DateMidnight.class,
> java.util.Date.class, fromDateMidnight));
> }
> {code}
> and I've contributed an editor:
> {code}
> public static void
> contributeBeanBlockSource(Configuration configuration)
> {
> configuration.add(new EditBlockContribution("dateMidnight",
> "infra/AppPropertyEditBlocks", "dateMidnight"));
> }
> {code}
> Here is the editor:
> {code}
> xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd;>
>
>
> value="context.propertyValue" label="prop:context.label"
> format="prop:dateInputFormat"
> translate="prop:dateMidnightTranslator" validate="prop:dateMidnightValidator"
> clientId="prop:context.propertyId" annotationProvider="context"/>
>
>
> {code}
> {code}
> public class AppPropertyEditBlocks {
> @Property
> @Environmental
> private PropertyEditContext context;
> @Component
> private DateField dateMidnight;
> @Component
> private DateField localDate;
>
> public DateFormat getDateInputFormat() {
> return new SimpleDateFormat("dd ");
> }
>
> public FieldTranslator getDateMidnightTranslator() {
> return context.getTranslator(dateMidnight);
> }
>
> public FieldValidator getDateMidnightValidator() {
> return context.getValidator(dateMidnight);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-1237) DateField is missing finnish and swedish error messages
[ https://issues.apache.org/jira/browse/TAP5-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-1237. Resolution: Incomplete I've added the two strings but there are still a lot of missing translations: https://github.com/apache/tapestry-5/tree/master/tapestry-core/src/main/resources/org/apache/tapestry5 Everyone is encouraged to reopen the issue and provide the necessary strings. > DateField is missing finnish and swedish error messages > --- > > Key: TAP5-1237 > URL: https://issues.apache.org/jira/browse/TAP5-1237 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4, 5.2 >Reporter: Ville Virtanen > Attachments: DateField_fi_FI.properties, DateField_sv_SE.properties > > > DateField missing finnish and swedish error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[ https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970658#comment-14970658 ] Jochen Kemnade edited comment on TAP5-2490 at 10/23/15 8:48 AM: I think I'm able to reproduce the issue now. I've tried the approach you suggested (using an aggregated event context) but haven't succeeded so far. The patch shows what I've tried so far. was (Author: jkemnade): I think I' able to reproduce the issue now. I've tried the approach you suggested (using an aggregated event context) but haven't succeeded so far. The patch shows what I've tried so far. > Autocomplete and Select context values does not work when context has to pass > through a value encoder > - > > Key: TAP5-2490 > URL: https://issues.apache.org/jira/browse/TAP5-2490 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Dimitris Zenios > Attachments: > 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch > > > Context passed down to select and autocomplete should be send as is > (UrlEventContext) to parent container instead of coercing it to List > context first -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[ https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970664#comment-14970664 ] Jochen Kemnade commented on TAP5-2490: -- I guess that fix would work only work in connection with a globally contributed ValueEncoder. > Autocomplete and Select context values does not work when context has to pass > through a value encoder > - > > Key: TAP5-2490 > URL: https://issues.apache.org/jira/browse/TAP5-2490 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Dimitris Zenios > Attachments: > 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch > > > Context passed down to select and autocomplete should be send as is > (UrlEventContext) to parent container instead of coercing it to List > context first -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2036) Localized filenames not found if locale contains variant
[ https://issues.apache.org/jira/browse/TAP5-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2036: - Affects Version/s: 5.4 > Localized filenames not found if locale contains variant > > > Key: TAP5-2036 > URL: https://issues.apache.org/jira/browse/TAP5-2036 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-ioc >Affects Versions: 5.3, 5.4, 5.2, 5.1 >Reporter: Nourredine K. >Priority: Minor > Labels: locale, localizedNameGenerator, patch, properties, > variant > Attachments: LocalizedNameGenerator.patch, > LocalizedNameGeneratorSpec.patch > > > The generated filenames by the "LocalizedNameGenerator" class is incorrect > for LV and V cases. > For instance, for "foo.properties" and locale "en_US_WIN", the generated > names are "foo_en_US_WIN.properties", "foo_en_US.properties", > "foo__WIN.properties", "foo_en.properties" and "foo.properties". > "foo__WIN.properties" should be "foo_en__WIN.properties" and it misses > "foo___WIN.properties" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2036) Localized filenames not found if locale contains variant
[
https://issues.apache.org/jira/browse/TAP5-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970935#comment-14970935
]
Jochen Kemnade commented on TAP5-2036:
--
I'm not sure about {{foo__WIN.properties}}. Should we really support that?
> Localized filenames not found if locale contains variant
>
>
> Key: TAP5-2036
> URL: https://issues.apache.org/jira/browse/TAP5-2036
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
>Affects Versions: 5.3, 5.2, 5.1
>Reporter: Nourredine K.
>Priority: Minor
> Labels: locale, localizedNameGenerator, patch, properties,
> variant
> Attachments: LocalizedNameGenerator.patch,
> LocalizedNameGeneratorSpec.patch
>
>
> The generated filenames by the "LocalizedNameGenerator" class is incorrect
> for LV and V cases.
> For instance, for "foo.properties" and locale "en_US_WIN", the generated
> names are "foo_en_US_WIN.properties", "foo_en_US.properties",
> "foo__WIN.properties", "foo_en.properties" and "foo.properties".
> "foo__WIN.properties" should be "foo_en__WIN.properties" and it misses
> "foo___WIN.properties"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2512) 5.4 breaks CSS that works unchanged in 5.3.x
[ https://issues.apache.org/jira/browse/TAP5-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970797#comment-14970797 ] Jochen Kemnade commented on TAP5-2512: -- Can you please add more information about how the CSS is broken? What does it contain and what should it contain? > 5.4 breaks CSS that works unchanged in 5.3.x > > > Key: TAP5-2512 > URL: https://issues.apache.org/jira/browse/TAP5-2512 > Project: Tapestry 5 > Issue Type: Bug > Components: quickstart >Affects Versions: 5.4 >Reporter: Adam Zimowski > Labels: CSS > > A simple app with a custom template that renders perfectly in 5.3.x renders > incorrectly with pom updated to use T5.4-beta. > Demo project available at: https://github.com/mrazjava/tapcssbug > Steps to re-create the issue: > 1) Clone above repo and execute the app (jetty:run) > 2) Navigate to localhost:8080 and observe how template renders correctly > 3) Stop the app. Change line 142 pom.xml T-version from 5.3.8 to 5.4-beta-35 > 4) Run the app again and observe broken template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2504) FormTests.datefield_leniency() fails with Prototype
[ https://issues.apache.org/jira/browse/TAP5-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2504. Resolution: Fixed Fix Version/s: 5.4 The issue is fixed, the question remains. > FormTests.datefield_leniency() fails with Prototype > --- > > Key: TAP5-2504 > URL: https://issues.apache.org/jira/browse/TAP5-2504 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Jochen Kemnade > Fix For: 5.4 > > > The form cannot be submitted because the form validation fails with "You must > provide a value for Birthday." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2397) AjaxFormLoop / DateField not operable if added by addRow event
[ https://issues.apache.org/jira/browse/TAP5-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2397. Resolution: Fixed > AjaxFormLoop / DateField not operable if added by addRow event > -- > > Key: TAP5-2397 > URL: https://issues.apache.org/jira/browse/TAP5-2397 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Sven Homburg >Assignee: Jochen Kemnade > Labels: 54_release_prerequisite > > After i add a new row to the ajaxformloop, the datefield-component is not > operable. > No action if i click the calander-button but also no javascript error in > console. > All other rows, that injected by the source parameter of ajaxformloop work as > expected with the datefield component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[ https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2490: - Attachment: 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch I think I' able to reproduce the issue now. I've tried the approach you suggested (using an aggregated event context) but haven't succeeded so far. The patch shows what I've tried so far. > Autocomplete and Select context values does not work when context has to pass > through a value encoder > - > > Key: TAP5-2490 > URL: https://issues.apache.org/jira/browse/TAP5-2490 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Dimitris Zenios > Attachments: > 0001-TAP5-2490-use-UrlEventContext-instead-of-ArrayEventC.patch > > > Context passed down to select and autocomplete should be send as is > (UrlEventContext) to parent container instead of coercing it to List > context first -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2487) t:extension-point declaration in tapestry_*.xsd's have never been correct
[ https://issues.apache.org/jira/browse/TAP5-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2487: - Labels: 54_release_prerequisite (was: ) > t:extension-point declaration in tapestry_*.xsd's have never been correct > - > > Key: TAP5-2487 > URL: https://issues.apache.org/jira/browse/TAP5-2487 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.3, 5.4, 5.2, 5.1 >Reporter: Chris Poulsen > Labels: 54_release_prerequisite > > JetBrains has just improved their tapestry plugin to use the specfied > tapestry_x_x.xsd when indicating errors in .tml files. > is flagged with a missing required attribute > name (according to the xsd), however the ExtensionPointToken / > SaxTemplateParser seems to expect an attribute called "id" being specified, > using "name" results in a tapestry exception: > ... > Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Element > does not support an attribute named 'name'. The only > allowed attribute name is 'id'. > I guess the easiest fix is to alter the xsd's to match the actual parser code > to prevent breaking existing tapestry applications. > This is a trivial fix and could be a nice thing to have in place before > releasing 5.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2487) t:extension-point declaration in tapestry_*.xsd's have never been correct
[ https://issues.apache.org/jira/browse/TAP5-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14964916#comment-14964916 ] Jochen Kemnade commented on TAP5-2487: -- We should come to a decision for 5.4. > t:extension-point declaration in tapestry_*.xsd's have never been correct > - > > Key: TAP5-2487 > URL: https://issues.apache.org/jira/browse/TAP5-2487 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.3, 5.4, 5.2, 5.1 >Reporter: Chris Poulsen > Labels: 54_release_prerequisite > > JetBrains has just improved their tapestry plugin to use the specfied > tapestry_x_x.xsd when indicating errors in .tml files. > is flagged with a missing required attribute > name (according to the xsd), however the ExtensionPointToken / > SaxTemplateParser seems to expect an attribute called "id" being specified, > using "name" results in a tapestry exception: > ... > Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Element > does not support an attribute named 'name'. The only > allowed attribute name is 'id'. > I guess the easiest fix is to alter the xsd's to match the actual parser code > to prevent breaking existing tapestry applications. > This is a trivial fix and could be a nice thing to have in place before > releasing 5.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2511) Named AMD modules cannot be added to JavaScript stack
[
https://issues.apache.org/jira/browse/TAP5-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965132#comment-14965132
]
Jochen Kemnade commented on TAP5-2511:
--
I wonder what we should do if we find a define call with a name that does not
match the module name, e.g. if the jquery module defined "jQuery" or "$"
instead of "jquery"? Use the module name, use the original name in the define
call? Fail?
By the way, there could be files that define multiple named modules at once,
like our stacks do. What should happen if a module named "core" defines
"t5/core/dom"?
> Named AMD modules cannot be added to JavaScript stack
> -
>
> Key: TAP5-2511
> URL: https://issues.apache.org/jira/browse/TAP5-2511
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> The {{define}} statement rewriting logic in
> {{org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.ModuleReader}}
> breaks stacks with named modules. For example, jquery 3.0-alpha1
> (https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.js) uses
> {noformat}
> define( "jquery", [], function() {
> return jQuery;
> });
> {noformat}
> The ModuleReader turns that into
> {noformat}
> define("jquery", "jquery", [], function() {
> return jQuery;
> });
> {noformat} which will not work. We should probably not rewrite named define
> calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2487) t:extension-point declaration in tapestry_*.xsd's have never been correct
[
https://issues.apache.org/jira/browse/TAP5-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965141#comment-14965141
]
Jochen Kemnade commented on TAP5-2487:
--
{{ t:extension-point declaration in tapestry_*.xsd's have never been correct
> -
>
> Key: TAP5-2487
> URL: https://issues.apache.org/jira/browse/TAP5-2487
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.3, 5.4, 5.2, 5.1
>Reporter: Chris Poulsen
> Labels: 54_release_prerequisite
>
> JetBrains has just improved their tapestry plugin to use the specfied
> tapestry_x_x.xsd when indicating errors in .tml files.
> is flagged with a missing required attribute
> name (according to the xsd), however the ExtensionPointToken /
> SaxTemplateParser seems to expect an attribute called "id" being specified,
> using "name" results in a tapestry exception:
> ...
> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Element
> does not support an attribute named 'name'. The only
> allowed attribute name is 'id'.
> I guess the easiest fix is to alter the xsd's to match the actual parser code
> to prevent breaking existing tapestry applications.
> This is a trivial fix and could be a nice thing to have in place before
> releasing 5.4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2487) t:extension-point declaration in tapestry_*.xsd's have never been correct
[ https://issues.apache.org/jira/browse/TAP5-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965000#comment-14965000 ] Jochen Kemnade commented on TAP5-2487: -- Yes, I think that would be the best option. > t:extension-point declaration in tapestry_*.xsd's have never been correct > - > > Key: TAP5-2487 > URL: https://issues.apache.org/jira/browse/TAP5-2487 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.3, 5.4, 5.2, 5.1 >Reporter: Chris Poulsen > Labels: 54_release_prerequisite > > JetBrains has just improved their tapestry plugin to use the specfied > tapestry_x_x.xsd when indicating errors in .tml files. > is flagged with a missing required attribute > name (according to the xsd), however the ExtensionPointToken / > SaxTemplateParser seems to expect an attribute called "id" being specified, > using "name" results in a tapestry exception: > ... > Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Element > does not support an attribute named 'name'. The only > allowed attribute name is 'id'. > I guess the easiest fix is to alter the xsd's to match the actual parser code > to prevent breaking existing tapestry applications. > This is a trivial fix and could be a nice thing to have in place before > releasing 5.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2487) t:extension-point declaration in tapestry_*.xsd's have never been correct
[ https://issues.apache.org/jira/browse/TAP5-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2487. Resolution: Fixed Assignee: Jochen Kemnade Fix Version/s: 5.4 > t:extension-point declaration in tapestry_*.xsd's have never been correct > - > > Key: TAP5-2487 > URL: https://issues.apache.org/jira/browse/TAP5-2487 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.3, 5.4, 5.2, 5.1 >Reporter: Chris Poulsen >Assignee: Jochen Kemnade > Labels: 54_release_prerequisite > Fix For: 5.4 > > > JetBrains has just improved their tapestry plugin to use the specfied > tapestry_x_x.xsd when indicating errors in .tml files. > is flagged with a missing required attribute > name (according to the xsd), however the ExtensionPointToken / > SaxTemplateParser seems to expect an attribute called "id" being specified, > using "name" results in a tapestry exception: > ... > Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: Element > does not support an attribute named 'name'. The only > allowed attribute name is 'id'. > I guess the easiest fix is to alter the xsd's to match the actual parser code > to prevent breaking existing tapestry applications. > This is a trivial fix and could be a nice thing to have in place before > releasing 5.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2511) Named AMD modules cannot be added to JavaScript stack
Jochen Kemnade created TAP5-2511:
Summary: Named AMD modules cannot be added to JavaScript stack
Key: TAP5-2511
URL: https://issues.apache.org/jira/browse/TAP5-2511
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
The {{define}} statement rewriting logic in
{{org.apache.tapestry5.internal.services.assets.JavaScriptStackAssemblerImpl.ModuleReader}}
breaks stacks with named modules. For example, jquery 3.0-alpha1
(https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.js) uses
{noformat}
define( "jquery", [], function() {
return jQuery;
});
{noformat}
The ModuleReader turns that into
{noformat}
define("jquery", "jquery", [], function() {
return jQuery;
});
{noformat} which will not work. We should probably not rewrite named define
calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2508. Resolution: Fixed Assignee: Jochen Kemnade Fix Version/s: 5.4 > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen >Assignee: Jochen Kemnade > Labels: 54_release_prerequisite, patch > Fix For: 5.4 > > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[
https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954504#comment-14954504
]
Jochen Kemnade edited comment on TAP5-2509 at 10/13/15 6:56 AM:
Yes it is. I assumed that a Label can only be used with a component that
renders a client-side element/ID because the {{for}} parameter is required.
Maybe that assumption was wrong. But I'd say you should use a regular HTML
{{label}} element here.
was (Author: jkemnade):
Yes it is. I assumed that a Label can only be used with a component that
renders a client-side element/ID because the {{for}} parameter is required.
Maybe that assumption was wrong.
> Regression with radiogroup label in 5.4-beta-37
> ---
>
> Key: TAP5-2509
> URL: https://issues.apache.org/jira/browse/TAP5-2509
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-radiogrouplabel.zip
>
>
> Having a label for a radio group fails in 5.4 beta 37, while it works up
> until beta-36.
> The error is:
> Render queue error in AfterRender[Index:form]: The field has returned a null
> client-side ID
> See the attached project for an example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[
https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954504#comment-14954504
]
Jochen Kemnade commented on TAP5-2509:
--
Yes it is. I assumed that a Label can only be used with a component that
renders a client-side element/ID because the {{for}} parameter is required.
Maybe that assumption was wrong.
> Regression with radiogroup label in 5.4-beta-37
> ---
>
> Key: TAP5-2509
> URL: https://issues.apache.org/jira/browse/TAP5-2509
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-radiogrouplabel.zip
>
>
> Having a label for a radio group fails in 5.4 beta 37, while it works up
> until beta-36.
> The error is:
> Render queue error in AfterRender[Index:form]: The field has returned a null
> client-side ID
> See the attached project for an example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2509) Regression with radiogroup label in 5.4-beta-37
[ https://issues.apache.org/jira/browse/TAP5-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953431#comment-14953431 ] Jochen Kemnade commented on TAP5-2509: -- That's probably caused by https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commitdiff;h=c4202982a11925b656e595cce4a276530e9c47d7;hp=33f9e65b933654b32d4a67ef6dcbc6b357eb7393 > Regression with radiogroup label in 5.4-beta-37 > --- > > Key: TAP5-2509 > URL: https://issues.apache.org/jira/browse/TAP5-2509 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-radiogrouplabel.zip > > > Having a label for a radio group fails in 5.4 beta 37, while it works up > until beta-36. > The error is: > Render queue error in AfterRender[Index:form]: The field has returned a null > client-side ID > See the attached project for an example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[
https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950069#comment-14950069
]
Jochen Kemnade commented on TAP5-2508:
--
The test suite runs fine. I'm a bit worried about
{{InheritanceData.isImplemented(String, String)}}. I wonder if I'm
misunderstanding what this method does. The original JavaDoc says "Returns true
if a transformed parent class contains an implementation of, or abstract
placeholder for, the method." But I think that it "Returns true if this class
or a transformed parent class contains an implementation of, or abstract
placeholder for, the method." You can see I changed that in my patch.
But then I wonder if the InheritanceData should actually represent the
inheritable method of the PlasticClass it is assigned from or the one it is
derived from. That's the point where my head usually starts to ache.
> Page activation method not always called since t54-beta33
> -
>
> Key: TAP5-2508
> URL: https://issues.apache.org/jira/browse/TAP5-2508
> Project: Tapestry 5
> Issue Type: Bug
> Components: plastic, tapestry-core
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Labels: 54_release_prerequisite, patch
> Attachments:
> 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch,
> t54-activate.zip
>
>
> Hi,
> I decided to try upgrading an app from t54-beta-26 to the latest public beta.
> Most things seem to work, but I noticed changed behavior with onActivate
> methods in some of our classes.
> We have a base page with the following:
> @OnEvent( ACTIVATE )
> void activate( EventContext ec)
> and an extending page with:
> @OnEvent( ACTIVATE )
> Object activate( EventContext ec )
> In beta-26 (and before) the methods are called in the following order:
> 1) Base activate
> 2) Extending page activate
> In beta-33 and newer only the Base activate is called.
> I'm attaching a sample project where one can play with the versions and see
> the differences in the console when requesting the index page.
> Also when creating the sample project i noticed that PageLink (to login in
> Layout.tml) fails if Login page is missing in beta-33 while it has no problem
> with pointing to a deleted page in beta-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946495#comment-14946495 ] Jochen Kemnade commented on TAP5-2508: -- Just for the record: this issues is caused by a mix of TAP5-1736 and TAP5-2268. I'm not overly familiar with plastic myself so I'm hesitant to commit this. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Labels: 54_release_prerequisite, patch > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2238) When require-ing a module that is part of a JavaScript Stack, the entire stack should be imported
[ https://issues.apache.org/jira/browse/TAP5-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2238. Resolution: Fixed > When require-ing a module that is part of a JavaScript Stack, the entire > stack should be imported > - > > Key: TAP5-2238 > URL: https://issues.apache.org/jira/browse/TAP5-2238 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Howard M. Lewis Ship >Assignee: Howard M. Lewis Ship > Labels: patch > Fix For: 5.4 > > Attachments: > 0001-TAP5-2238-if-a-module-is-requested-that-is-part-of-a.patch > > > This is parallel to existing logic w.r.t. to libraries and stacks. > Without this, it may be necessary to import the stack, and require the > desired module, for efficient behavior in both development and production > (with aggregation enabled). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2508: - Labels: 54_release_prerequisite patch (was: patch) > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Labels: 54_release_prerequisite, patch > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2238) When require-ing a module that is part of a JavaScript Stack, the entire stack should be imported
[ https://issues.apache.org/jira/browse/TAP5-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2238: - Labels: patch (was: ) > When require-ing a module that is part of a JavaScript Stack, the entire > stack should be imported > - > > Key: TAP5-2238 > URL: https://issues.apache.org/jira/browse/TAP5-2238 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Howard M. Lewis Ship >Assignee: Howard M. Lewis Ship > Labels: patch > Fix For: 5.4 > > Attachments: > 0001-TAP5-2238-if-a-module-is-requested-that-is-part-of-a.patch > > > This is parallel to existing logic w.r.t. to libraries and stacks. > Without this, it may be necessary to import the stack, and require the > desired module, for efficient behavior in both development and production > (with aggregation enabled). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2508: - Labels: has-patch (was: ) > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Labels: patch > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2508: - Labels: patch (was: has-patch) > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Labels: patch > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2508: - Component/s: tapestry-core plastic > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2508: - Attachment: 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch The patch should fix that issue but I'd appreciate if someone else could have a look. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic, tapestry-core >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: > 0001-TAP5-2508-methods-with-default-visibility-cannot-be-.patch, > t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[
https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941021#comment-14941021
]
Jochen Kemnade commented on TAP5-2508:
--
Yes, me too.
I've traced it down to {{OnEventWorker:406}}, {{isOverride}} returns true now
for the first case. InheritanceData does not know anything of packages and
visibility so that's expected (but incorrect IMO).
I'm still trying to reproduce this in a test, but haven't succeeded yet.
> Page activation method not always called since t54-beta33
> -
>
> Key: TAP5-2508
> URL: https://issues.apache.org/jira/browse/TAP5-2508
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-activate.zip
>
>
> Hi,
> I decided to try upgrading an app from t54-beta-26 to the latest public beta.
> Most things seem to work, but I noticed changed behavior with onActivate
> methods in some of our classes.
> We have a base page with the following:
> @OnEvent( ACTIVATE )
> void activate( EventContext ec)
> and an extending page with:
> @OnEvent( ACTIVATE )
> Object activate( EventContext ec )
> In beta-26 (and before) the methods are called in the following order:
> 1) Base activate
> 2) Extending page activate
> In beta-33 and newer only the Base activate is called.
> I'm attaching a sample project where one can play with the versions and see
> the differences in the console when requesting the index page.
> Also when creating the sample project i noticed that PageLink (to login in
> Layout.tml) fails if Login page is missing in beta-33 while it has no problem
> with pointing to a deleted page in beta-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[
https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940875#comment-14940875
]
Jochen Kemnade commented on TAP5-2508:
--
Alright, got it. It's really 6c7c090eafa1c59972f9e28536ba9c2991fd701e
(TAP5-2268). I couldn't reproduce it first, because I used a {{void}} method in
the extending class. So this boils down to
||activate methods||-beta-28||-beta-29||
|void + Object, same name |base+index|base|
|void + void, same name |base|base|
|void + Object, different names |base+index|base+index|
|void + void, different names |base+index|base+index|
I wonder which behavior we actually want. I think that base+index should always
be called.
> Page activation method not always called since t54-beta33
> -
>
> Key: TAP5-2508
> URL: https://issues.apache.org/jira/browse/TAP5-2508
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-activate.zip
>
>
> Hi,
> I decided to try upgrading an app from t54-beta-26 to the latest public beta.
> Most things seem to work, but I noticed changed behavior with onActivate
> methods in some of our classes.
> We have a base page with the following:
> @OnEvent( ACTIVATE )
> void activate( EventContext ec)
> and an extending page with:
> @OnEvent( ACTIVATE )
> Object activate( EventContext ec )
> In beta-26 (and before) the methods are called in the following order:
> 1) Base activate
> 2) Extending page activate
> In beta-33 and newer only the Base activate is called.
> I'm attaching a sample project where one can play with the versions and see
> the differences in the console when requesting the index page.
> Also when creating the sample project i noticed that PageLink (to login in
> Layout.tml) fails if Login page is missing in beta-33 while it has no problem
> with pointing to a deleted page in beta-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939581#comment-14939581 ] Jochen Kemnade commented on TAP5-2508: -- I don't think it has something to do with dependency handling. I'm just having a hard time reproducing the difference in behavior with Gradle. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[
https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939518#comment-14939518
]
Jochen Kemnade commented on TAP5-2508:
--
I'm trying to debug this. [~chrispoulsen], are both methods really named
{{activate}} in your case? If I try it like that with beta-26, only the method
in the base class is called. If I rename one of them, both methods are called
(again with beta-26).
> Page activation method not always called since t54-beta33
> -
>
> Key: TAP5-2508
> URL: https://issues.apache.org/jira/browse/TAP5-2508
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-activate.zip
>
>
> Hi,
> I decided to try upgrading an app from t54-beta-26 to the latest public beta.
> Most things seem to work, but I noticed changed behavior with onActivate
> methods in some of our classes.
> We have a base page with the following:
> @OnEvent( ACTIVATE )
> void activate( EventContext ec)
> and an extending page with:
> @OnEvent( ACTIVATE )
> Object activate( EventContext ec )
> In beta-26 (and before) the methods are called in the following order:
> 1) Base activate
> 2) Extending page activate
> In beta-33 and newer only the Base activate is called.
> I'm attaching a sample project where one can play with the versions and see
> the differences in the console when requesting the index page.
> Also when creating the sample project i noticed that PageLink (to login in
> Layout.tml) fails if Login page is missing in beta-33 while it has no problem
> with pointing to a deleted page in beta-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939542#comment-14939542 ] Jochen Kemnade commented on TAP5-2508: -- Yes, I saw the same behavior when I tried this yesterday. But today, I'm trying to reproduce it within the Tapestry App1 test project and it seems to behave differently. I wonder who's doing something wrong, Maven, Gradle or me. Probably the latter... > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939565#comment-14939565 ] Jochen Kemnade commented on TAP5-2508: -- Same behavior if I import the module in Eclipse and run it with the Eclipse Jetty plugin. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2508) Page activation method not always called since t54-beta33
[
https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939518#comment-14939518
]
Jochen Kemnade edited comment on TAP5-2508 at 10/1/15 8:50 AM:
---
I'm trying to debug this. [~chrispoulsen], are both methods really named
{{activate}} in your case? If I try it like that with beta-26, only the method
in the base class is called. If I rename one of them, both methods are called
(with beta-26 as well as with current master).
And, if both methods are really called {{activate}} and have default
visibility, what packages are your base and extended class in?
was (Author: jkemnade):
I'm trying to debug this. [~chrispoulsen], are both methods really named
{{activate}} in your case? If I try it like that with beta-26, only the method
in the base class is called. If I rename one of them, both methods are called
(again with beta-26).
> Page activation method not always called since t54-beta33
> -
>
> Key: TAP5-2508
> URL: https://issues.apache.org/jira/browse/TAP5-2508
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Chris Poulsen
> Attachments: t54-activate.zip
>
>
> Hi,
> I decided to try upgrading an app from t54-beta-26 to the latest public beta.
> Most things seem to work, but I noticed changed behavior with onActivate
> methods in some of our classes.
> We have a base page with the following:
> @OnEvent( ACTIVATE )
> void activate( EventContext ec)
> and an extending page with:
> @OnEvent( ACTIVATE )
> Object activate( EventContext ec )
> In beta-26 (and before) the methods are called in the following order:
> 1) Base activate
> 2) Extending page activate
> In beta-33 and newer only the Base activate is called.
> I'm attaching a sample project where one can play with the versions and see
> the differences in the console when requesting the index page.
> Also when creating the sample project i noticed that PageLink (to login in
> Layout.tml) fails if Login page is missing in beta-33 while it has no problem
> with pointing to a deleted page in beta-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939557#comment-14939557 ] Jochen Kemnade commented on TAP5-2508: -- Funny. If I run your project with Gradle, only the method from the base class is called with beta-26. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939565#comment-14939565 ] Jochen Kemnade edited comment on TAP5-2508 at 10/1/15 9:26 AM: --- Same behavior if I import the Maven project in Eclipse and run it with the Eclipse Jetty plugin. was (Author: jkemnade): Same behavior if I import the module in Eclipse and run it with the Eclipse Jetty plugin. > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936735#comment-14936735 ] Jochen Kemnade commented on TAP5-2508: -- Apparently this changed between betas 28 and 29. I had a quick glance at the relevant commits but found nothing obvious. https://github.com/apache/tapestry-5/compare/5.4-beta-28...5.4-beta-29 > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2508) Page activation method not always called since t54-beta33
[ https://issues.apache.org/jira/browse/TAP5-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936781#comment-14936781 ] Jochen Kemnade commented on TAP5-2508: -- Yes, that commit message seemed slightly suspicious to me too. [~fscheffer], do you think there might be a relation? > Page activation method not always called since t54-beta33 > - > > Key: TAP5-2508 > URL: https://issues.apache.org/jira/browse/TAP5-2508 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.4 >Reporter: Chris Poulsen > Attachments: t54-activate.zip > > > Hi, > I decided to try upgrading an app from t54-beta-26 to the latest public beta. > Most things seem to work, but I noticed changed behavior with onActivate > methods in some of our classes. > We have a base page with the following: > @OnEvent( ACTIVATE ) > void activate( EventContext ec) > and an extending page with: > @OnEvent( ACTIVATE ) > Object activate( EventContext ec ) > In beta-26 (and before) the methods are called in the following order: > 1) Base activate > 2) Extending page activate > In beta-33 and newer only the Base activate is called. > I'm attaching a sample project where one can play with the versions and see > the differences in the console when requesting the index page. > Also when creating the sample project i noticed that PageLink (to login in > Layout.tml) fails if Login page is missing in beta-33 while it has no problem > with pointing to a deleted page in beta-36. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2489) Palette component parameter availableLabel and selectedLabel should have required = false
[
https://issues.apache.org/jira/browse/TAP5-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805090#comment-14805090
]
Jochen Kemnade commented on TAP5-2489:
--
I guess that's a bug in IntelliJ or some plugin that tries to be smart but
fails to interpret the {{@Parameter}} annotation correctly.
> Palette component parameter availableLabel and selectedLabel should have
> required = false
> --
>
> Key: TAP5-2489
> URL: https://issues.apache.org/jira/browse/TAP5-2489
> Project: Tapestry 5
> Issue Type: Wish
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Svein
>Priority: Minor
> Labels: component
>
> Having value = "message:core-palette-available-label" and value =
> "message:core-palette-selected-label" then @Parameter(required = false) is
> better! My IDE gives me error when selectedLabel or availableLabel is skipped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2194) Declare SubmitNotifier event names as constants to avoid typos
[
https://issues.apache.org/jira/browse/TAP5-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2194.
Resolution: Fixed
Fix Version/s: 5.4
The new constants are {{SubmitNotifier.BEGIN_SUBMIT_EVENT}} and
{{SubmitNotifier.AFTER_SUBMIT_EVENT}}.
> Declare SubmitNotifier event names as constants to avoid typos
> --
>
> Key: TAP5-2194
> URL: https://issues.apache.org/jira/browse/TAP5-2194
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.3.7, 5.4
>Reporter: Alex Lumpov
>Priority: Minor
> Fix For: 5.4
>
>
> declare
> public static final String BEGIN_SUBMIT = "BeginSubmit";
> public static final String AFTER_SUBMIT = "AfterSubmit";
> in class EventConstants
> or in class SubmitNotifier
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2238) When require-ing a module that is part of a JavaScript Stack, the entire stack should be imported
[ https://issues.apache.org/jira/browse/TAP5-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-2238: - Attachment: 0001-TAP5-2238-if-a-module-is-requested-that-is-part-of-a.patch This patch fixes the issue. Thoughts? > When require-ing a module that is part of a JavaScript Stack, the entire > stack should be imported > - > > Key: TAP5-2238 > URL: https://issues.apache.org/jira/browse/TAP5-2238 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Howard M. Lewis Ship >Assignee: Howard M. Lewis Ship > Fix For: 5.4 > > Attachments: > 0001-TAP5-2238-if-a-module-is-requested-that-is-part-of-a.patch > > > This is parallel to existing logic w.r.t. to libraries and stacks. > Without this, it may be necessary to import the stack, and require the > desired module, for efficient behavior in both development and production > (with aggregation enabled). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2489) Palette component parameter availableLabel and selectedLabel should have required = false
[
https://issues.apache.org/jira/browse/TAP5-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805109#comment-14805109
]
Jochen Kemnade commented on TAP5-2489:
--
No, I don't. The JavaDoc of {{Parameter.value()}} says: "The default value for
the parameter if not bound", so if you don't specify the parameter, the value
returned from {{value()}} is used.
That's how Tapestry interprets the annotation, and after all, the Palette
component does work if you don't specify those parameters.
> Palette component parameter availableLabel and selectedLabel should have
> required = false
> --
>
> Key: TAP5-2489
> URL: https://issues.apache.org/jira/browse/TAP5-2489
> Project: Tapestry 5
> Issue Type: Wish
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Svein
>Priority: Minor
> Labels: component
>
> Having value = "message:core-palette-available-label" and value =
> "message:core-palette-selected-label" then @Parameter(required = false) is
> better! My IDE gives me error when selectedLabel or availableLabel is skipped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2454) Checklist and Palette should support a default encoder like Select
[
https://issues.apache.org/jira/browse/TAP5-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805335#comment-14805335
]
Jochen Kemnade commented on TAP5-2454:
--
This could be done using {{ComponentResources#getBoundGenericType(String)}},
see for example
https://github.com/eddyson-de/tapestry-extensions/commit/7d4e9900492136e71a77d62fd473d8448d1a252f.
> Checklist and Palette should support a default encoder like Select
> --
>
> Key: TAP5-2454
> URL: https://issues.apache.org/jira/browse/TAP5-2454
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Chris Poulsen
>Priority: Minor
>
> As the three components are so closely related it would make sense to have
> them work in the same way.
> Currently one is forced to supply an encoder when converting a select into
> one of the multi-select components (palette/checklist) - That is not
> necessary if the select worked without an explicit encoder, the other two
> components should as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2350) JavaScript library with module shim config is loaded twice if module is added to a stack
[ https://issues.apache.org/jira/browse/TAP5-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805268#comment-14805268 ] Jochen Kemnade commented on TAP5-2350: -- We might be able to solve this with a similar approach to what I tried for TAP5-2238. > JavaScript library with module shim config is loaded twice if module is added > to a stack > > > Key: TAP5-2350 > URL: https://issues.apache.org/jira/browse/TAP5-2350 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Jochen Kemnade > Labels: javascript, stack > > When a shim config is defined for a JavaScript library and the resulting > "module" is added to a JavaScript stack, the raw library will be added to the > stack resource (without a define statement). But under normal circumstances, > it will never be used as it is added without any module wrapper code. > When the library is required (via the shim module) from another module, > requirejs loads it again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TAP5-2463) ResponseWrapper dont work correctly in dom,js
[
https://issues.apache.org/jira/browse/TAP5-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2463.
Resolution: Fixed
Fixed in {{a260fa25e76cf408bcf5645a8d43e171f3a27d77}} (5.4-beta-36).
> ResponseWrapper dont work correctly in dom,js
> -
>
> Key: TAP5-2463
> URL: https://issues.apache.org/jira/browse/TAP5-2463
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Sven Homburg
>Assignee: François Facon
> Labels: patch
> Fix For: 5.4
>
> Attachments: patch.diff
>
>
> since beta-29
> if javascript calls instantiate the ResponseWrapper class
> there is thrown an exception, that "jqxhr" is unknown
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2506) Report conflicting BeanBlockOverrideSource configuration
[
https://issues.apache.org/jira/browse/TAP5-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2506.
Resolution: Fixed
Fix Version/s: 5.4
> Report conflicting BeanBlockOverrideSource configuration
>
>
> Key: TAP5-2506
> URL: https://issues.apache.org/jira/browse/TAP5-2506
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
> Fix For: 5.4
>
>
> If multiple BeanBlockContributions with the same configuration for {{edit}}
> and {{dataType}} are contributed to BeanBlockOverrideSource, there should be
> a warning at least, probably even an exception, because Configuration is
> unordered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2506) Report conflicting BeanBlockOverrideSource configuration
Jochen Kemnade created TAP5-2506:
Summary: Report conflicting BeanBlockOverrideSource configuration
Key: TAP5-2506
URL: https://issues.apache.org/jira/browse/TAP5-2506
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
If multiple BeanBlockContributions with the same configuration for {{edit}} and
{{dataType}} are contributed to BeanBlockOverrideSource, there should be a
warning at least, probably even an exception, because Configuration is
unordered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2490) Autocomplete and Select context values does not work when context has to pass through a value encoder
[ https://issues.apache.org/jira/browse/TAP5-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802677#comment-14802677 ] Jochen Kemnade commented on TAP5-2490: -- [~zenios], could you please create a simple page that demonstrates the problem, preferably one that does not need special domain classes? > Autocomplete and Select context values does not work when context has to pass > through a value encoder > - > > Key: TAP5-2490 > URL: https://issues.apache.org/jira/browse/TAP5-2490 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Dimitris Zenios > > Context passed down to select and autocomplete should be send as is > (UrlEventContext) to parent container instead of coercing it to List > context first -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2506) Report conflicting BeanBlockOverrideSource configuration
[
https://issues.apache.org/jira/browse/TAP5-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2506:
-
Issue Type: Improvement (was: Bug)
> Report conflicting BeanBlockOverrideSource configuration
>
>
> Key: TAP5-2506
> URL: https://issues.apache.org/jira/browse/TAP5-2506
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> If multiple BeanBlockContributions with the same configuration for {{edit}}
> and {{dataType}} are contributed to BeanBlockOverrideSource, there should be
> a warning at least, probably even an exception, because Configuration is
> unordered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2492) No change event when datePicker updates t:datefield
[
https://issues.apache.org/jira/browse/TAP5-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802904#comment-14802904
]
Jochen Kemnade commented on TAP5-2492:
--
This was already requested: TAP5-2145
> No change event when datePicker updates t:datefield
>
>
> Key: TAP5-2492
> URL: https://issues.apache.org/jira/browse/TAP5-2492
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Svein
>
> When fields in my side panel are updated, I call submit on the change event.
> If datePicker is used no change event are fired.
> One line added by me: _this.field.$.change();
> Controller.prototype.onSelect = function() {
> var date;
> date = this.datePicker.getDate();
> if (date === null) {
> this.hidePopup();
> this.clearFieldError();
> this.field.value("");
> return;
> }
> this.field.addClass("ajax-wait");
> return ajax(this.container.attr("data-format-url"), {
> data: {
> input: date.getTime()
> },
> failure: (function(_this) {
> return function(response, message) {
> _this.field.removeClass("ajax-wait");
> return _this.fieldError(message);
> };
> })(this),
> success: (function(_this) {
> return function(response) {
> _this.field.removeClass("ajax-wait");
> _this.clearFieldError();
> _this.field.value(response.json.result);
> //trigger change event on field
> _this.field.$.change();
> return _this.hidePopup();
> };
> })(this)
> });
> };
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2492) No change event when datePicker updates t:datefield
[
https://issues.apache.org/jira/browse/TAP5-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2492.
Resolution: Duplicate
> No change event when datePicker updates t:datefield
>
>
> Key: TAP5-2492
> URL: https://issues.apache.org/jira/browse/TAP5-2492
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Svein
>
> When fields in my side panel are updated, I call submit on the change event.
> If datePicker is used no change event are fired.
> One line added by me: _this.field.$.change();
> Controller.prototype.onSelect = function() {
> var date;
> date = this.datePicker.getDate();
> if (date === null) {
> this.hidePopup();
> this.clearFieldError();
> this.field.value("");
> return;
> }
> this.field.addClass("ajax-wait");
> return ajax(this.container.attr("data-format-url"), {
> data: {
> input: date.getTime()
> },
> failure: (function(_this) {
> return function(response, message) {
> _this.field.removeClass("ajax-wait");
> return _this.fieldError(message);
> };
> })(this),
> success: (function(_this) {
> return function(response) {
> _this.field.removeClass("ajax-wait");
> _this.clearFieldError();
> _this.field.value(response.json.result);
> //trigger change event on field
> _this.field.$.change();
> return _this.hidePopup();
> };
> })(this)
> });
> };
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2503) Confirm Mixin does not with with Prototype
Jochen Kemnade created TAP5-2503:
Summary: Confirm Mixin does not with with Prototype
Key: TAP5-2503
URL: https://issues.apache.org/jira/browse/TAP5-2503
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Jochen Kemnade
The Confirm Mixin does not work if the JavaScript infrastructure provider is
set to prototype:
* Confirming the dialog does not let the action continue
* Right-clicking a button with the confirm mixin does not show the dialog but
lets the action continue immediately.
Can be tested by using {{gradle
-Dtapestry.javascript-infrastructure-provider=prototype
tapestry-core:runTestApp1}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2503) Confirm Mixin does not work with Prototype
[
https://issues.apache.org/jira/browse/TAP5-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2503:
-
Summary: Confirm Mixin does not work with Prototype (was: Confirm Mixin
does not with with Prototype)
> Confirm Mixin does not work with Prototype
> --
>
> Key: TAP5-2503
> URL: https://issues.apache.org/jira/browse/TAP5-2503
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> The Confirm Mixin does not work if the JavaScript infrastructure provider is
> set to prototype:
> * Confirming the dialog does not let the action continue
> * Right-clicking a button with the confirm mixin does not show the dialog but
> lets the action continue immediately.
> Can be tested by using {{gradle
> -Dtapestry.javascript-infrastructure-provider=prototype
> tapestry-core:runTestApp1}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2503) Confirm Mixin does not work with Prototype
[
https://issues.apache.org/jira/browse/TAP5-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-2503:
-
Description:
The Confirm Mixin does not work if the JavaScript infrastructure provider is
set to prototype:
* Confirming the dialog does not let the action continue
* Right-clicking a button with the confirm mixin does not show the dialog but
lets the action continue immediately.
Can be tested by adding
{{systemProperties."tapestry.javascript-infrastructure-provider" =
"prototype"}} to the {{runTestApp1}} task in {{tapestry-core}} amd running
{{tapestry-core:runTestApp1}}
was:
The Confirm Mixin does not work if the JavaScript infrastructure provider is
set to prototype:
* Confirming the dialog does not let the action continue
* Right-clicking a button with the confirm mixin does not show the dialog but
lets the action continue immediately.
Can be tested by using {{gradle
-Dtapestry.javascript-infrastructure-provider=prototype
tapestry-core:runTestApp1}}
> Confirm Mixin does not work with Prototype
> --
>
> Key: TAP5-2503
> URL: https://issues.apache.org/jira/browse/TAP5-2503
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> The Confirm Mixin does not work if the JavaScript infrastructure provider is
> set to prototype:
> * Confirming the dialog does not let the action continue
> * Right-clicking a button with the confirm mixin does not show the dialog but
> lets the action continue immediately.
> Can be tested by adding
> {{systemProperties."tapestry.javascript-infrastructure-provider" =
> "prototype"}} to the {{runTestApp1}} task in {{tapestry-core}} amd running
> {{tapestry-core:runTestApp1}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2504) FormTests.datefield_leniency() fails with Prototype
Jochen Kemnade created TAP5-2504: Summary: FormTests.datefield_leniency() fails with Prototype Key: TAP5-2504 URL: https://issues.apache.org/jira/browse/TAP5-2504 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Jochen Kemnade The form cannot be submitted because the form validation fails with "You must provide a value for Birthday." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2505) Different behavior of ElementWrapper.visible with jQuery and Prototype
Jochen Kemnade created TAP5-2505:
Summary: Different behavior of ElementWrapper.visible with jQuery
and Prototype
Key: TAP5-2505
URL: https://issues.apache.org/jira/browse/TAP5-2505
Project: Tapestry 5
Issue Type: Bug
Reporter: Jochen Kemnade
If an element is hidden via a CSS class, {{dom(element).visible()}} will return
{{false}} with jQuery and {{true}} with Prototype.
This is because the jQuery implementation checks the display style whereas the
Prototype implementation uses Element.visible
{{http://api.prototypejs.org/dom/Element/visible/}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2505) Different behavior of ElementWrapper.visible with jQuery and Prototype
[
https://issues.apache.org/jira/browse/TAP5-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14768961#comment-14768961
]
Jochen Kemnade commented on TAP5-2505:
--
I wonder if we need that method anyway. We're only using it in
{{datefield.coffee:82}}, but we could probably use {{deepVisible()}} there
instead.
> Different behavior of ElementWrapper.visible with jQuery and Prototype
> --
>
> Key: TAP5-2505
> URL: https://issues.apache.org/jira/browse/TAP5-2505
> Project: Tapestry 5
> Issue Type: Bug
>Reporter: Jochen Kemnade
>
> If an element is hidden via a CSS class, {{dom(element).visible()}} will
> return {{false}} with jQuery and {{true}} with Prototype.
> This is because the jQuery implementation checks the display style whereas
> the Prototype implementation uses Element.visible
> {{http://api.prototypejs.org/dom/Element/visible/}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2504) FormTests.datefield_leniency() fails with Prototype
[
https://issues.apache.org/jira/browse/TAP5-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14768906#comment-14768906
]
Jochen Kemnade commented on TAP5-2504:
--
The test was added for TAP5-1998.
There's no client-side validation of the {{birthday}} field when jQuery is
used, because the associated hidden field is not {{deepVisible()}} (see
{{fields.coffee:106}}). I wonder if that's what we want.
> FormTests.datefield_leniency() fails with Prototype
> ---
>
> Key: TAP5-2504
> URL: https://issues.apache.org/jira/browse/TAP5-2504
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> The form cannot be submitted because the form validation fails with "You must
> provide a value for Birthday."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2504) FormTests.datefield_leniency() fails with Prototype
[
https://issues.apache.org/jira/browse/TAP5-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14768963#comment-14768963
]
Jochen Kemnade commented on TAP5-2504:
--
I've changed {{deepVisible()}} to use vanilla JS, now the test works with both
providers. I still wonder if we should skip the datefield's text field during
the client-side validation.
> FormTests.datefield_leniency() fails with Prototype
> ---
>
> Key: TAP5-2504
> URL: https://issues.apache.org/jira/browse/TAP5-2504
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>
> The form cannot be submitted because the form validation fails with "You must
> provide a value for Birthday."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2502) Tapestry5: jQuery.dialog not work with DataTables
[
https://issues.apache.org/jira/browse/TAP5-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-2502.
Resolution: Invalid
> Tapestry5: jQuery.dialog not work with DataTables
> -
>
> Key: TAP5-2502
> URL: https://issues.apache.org/jira/browse/TAP5-2502
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.3.8
>Reporter: Mai
>
> Now we are using DataTable for showing the finder result. In one cell there
> is a Actionlink delete-button. But if we click on the delete button, no
> jQuery.dialog is displayed. The code for that I have posted at below.
> Thanks for analyzing...
> Template:
> t:source="finderCallback.finderGridDataSource"
> t:rowsPerPage="prop:rowsPerPageInitial"
> t:include="prop:colsToInclude" t:exclude="prop:colsToExclude"
> t:model="finderResultGridModel"
> t:options="finderResultGridOptions"
> t:mode="false" t:row="finderResultRow"
> t:tableInformation="finderResultGridInformation" t:add="action">
>
> --
> Code behind the delete button:
> jQuery(document).ready(function($) { $('#delete_mtmmtm').click(function (e) {
> e.preventDefault();$('#form_delete_popup').dialog('open');$(
> '#delete_pkTargetField' ).val('bXRtbXRt');$( '#delete_pkTargetField_hash'
> ).val('974AF96FBBCCD2FF103DABF6EB5CF3D5F66EB8179CFF73A2AA629633F5B2B425');});});
> --
> Calling function:
>
> // due to use of jQuery data table we have to add the class
> "k-actions"
> // to each last td of each tr in table with id "finderResultGrid"
>
> jQuery(document).ready(function() {
> jQuery( "#finderResultGrid tr td:last-of-type"
> ).addClass( "k-actions" );
>
> $(function() {
>var dialog1 = $("#form_delete_popup").dialog({
> autoOpen: false,
> height: 150,
> width: 350,
> modal: true,
> title: 'Delete user',
>});
> });
> });
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2502) Tapestry5: jQuery.dialog not work with DataTables
[
https://issues.apache.org/jira/browse/TAP5-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14745223#comment-14745223
]
Jochen Kemnade commented on TAP5-2502:
--
The DataTable and Dialog components belong to the {{tapestry5-jquery}}
component library and are not part of the core distribution. Please report your
problem at https://github.com/got5/tapestry5-jquery instead.
> Tapestry5: jQuery.dialog not work with DataTables
> -
>
> Key: TAP5-2502
> URL: https://issues.apache.org/jira/browse/TAP5-2502
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.3.8
>Reporter: Mai
>
> Now we are using DataTable for showing the finder result. In one cell there
> is a Actionlink delete-button. But if we click on the delete button, no
> jQuery.dialog is displayed. The code for that I have posted at below.
> Thanks for analyzing...
> Template:
> t:source="finderCallback.finderGridDataSource"
> t:rowsPerPage="prop:rowsPerPageInitial"
> t:include="prop:colsToInclude" t:exclude="prop:colsToExclude"
> t:model="finderResultGridModel"
> t:options="finderResultGridOptions"
> t:mode="false" t:row="finderResultRow"
> t:tableInformation="finderResultGridInformation" t:add="action">
>
> --
> Code behind the delete button:
> jQuery(document).ready(function($) { $('#delete_mtmmtm').click(function (e) {
> e.preventDefault();$('#form_delete_popup').dialog('open');$(
> '#delete_pkTargetField' ).val('bXRtbXRt');$( '#delete_pkTargetField_hash'
> ).val('974AF96FBBCCD2FF103DABF6EB5CF3D5F66EB8179CFF73A2AA629633F5B2B425');});});
> --
> Calling function:
>
> // due to use of jQuery data table we have to add the class
> "k-actions"
> // to each last td of each tr in table with id "finderResultGrid"
>
> jQuery(document).ready(function() {
> jQuery( "#finderResultGrid tr td:last-of-type"
> ).addClass( "k-actions" );
>
> $(function() {
>var dialog1 = $("#form_delete_popup").dialog({
> autoOpen: false,
> height: 150,
> width: 350,
> modal: true,
> title: 'Delete user',
>});
> });
> });
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TAP5-2501) AjaxFormLoop doesn't work well inside a table tag
[ https://issues.apache.org/jira/browse/TAP5-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade closed TAP5-2501. Resolution: Duplicate > AjaxFormLoop doesn't work well inside a table tag > - > > Key: TAP5-2501 > URL: https://issues.apache.org/jira/browse/TAP5-2501 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Sven Homburg > > this issue still exists in 5.4-beta36 > description look [here|https://issues.apache.org/jira/browse/TAP5-2274] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TAP5-2274) AjaxFormLoop doesn't work well inside a table tag
[ https://issues.apache.org/jira/browse/TAP5-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade reopened TAP5-2274: -- According to [~homburgs], the issue still exists. > AjaxFormLoop doesn't work well inside a table tag > - > > Key: TAP5-2274 > URL: https://issues.apache.org/jira/browse/TAP5-2274 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Sven Homburg >Assignee: Howard M. Lewis Ship > Labels: patch > Fix For: 5.4 > > Attachments: > 0003-TAP5-2274-AjaxFormLoop-dont-work-well-inside-a-table.patch > > > if i use AjaxFormLoop inside a table tag, like this: > > > > > Name 1 > Name 2 > > > > encoder="personHolderEncoder" value="personHolder"> > value="personHolder.person.name1"/> > value="personHolder.person.name2"/> > > > > > there is no javascript error thrown. > here the code rendered by tapestry: > id="form"> > value="cYCR+e8VnfSZyMMIKGcs2cKU1F0=:H4sIAFvzloEVAN3OqfcE" > name="t:formdata" type="hidden"> > data-inject-row-url="/tap54test/start.ajaxformloop:injectrow?t:formcomponentid=Start:formt:formid=form" > data-remove-row-url="/tap54test/start.ajaxformloop:triggerremoverow" > data-container-type="core/AjaxFormLoop"> > > > > Add row > > > > > Name 1 > Name 2 > Birthday > > > > data-container-type="core/ajaxformloop-fragment"> > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2500) Label broken when inside zone and attached to a Field after that zone
[
https://issues.apache.org/jira/browse/TAP5-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738380#comment-14738380
]
Jochen Kemnade commented on TAP5-2500:
--
If we only have a single Heartbeat, we need another way to defer rendering
tasks to the end of an iteration of a containing rendering task, e.g.
{code}
{code}
We cannot write the {{for}} parameter until after we have assigned a client id
to the textfield, but we don't want to defer that to the end of the
MarkupRendererFilter, because if we ded, all labels would get the id of the
textfield in the last iteration of the loop component.
I recently fixed the TriggerFragment/FormFragment issue by allocation the
client id on first access
(https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commitdiff;h=4a9b171531f9fa271cb540555ead87d6b7242cca)
and resetting it in the AfterRender phase
(https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commitdiff;h=33f9e65b933654b32d4a67ef6dcbc6b357eb7393).
If we did the same for AbstractField, that would probably solve your issue.
I'll also add a check for a {{null}} fieldId to the Label component, so this
error doesn't go unnoticed at least.
> Label broken when inside zone and attached to a Field after that zone
> -
>
> Key: TAP5-2500
> URL: https://issues.apache.org/jira/browse/TAP5-2500
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: I D
>
> This is just one example, since the same problem is observed for
> TriggerFrament inside a zone when used in conjunction with a FormFragment
> outside the zone (and after it).
> {code:xml}
>
> Label
>
>
> {code}
> The reason this doesn't work is because Label.updateAttributes() uses
> @HeartbeatDeferred and assumes this invocation will be deferred until the end
> of the *page* render. Alas, since the label is inside a zone, which for some
> reason starts and ends its own heartbeat (nested within, and occluding, the
> page heartbeat), the invocation is deferred only until the end of the *zone*
> render, i.e. - too early.
> Apparently this bug was introduced in [this
> commit|https://github.com/apache/tapestry-5/commit/cc6fe5f3f85001eca4e0aa6a79c3bedc3e36b82c],
> which in turn was addressing
> [TAP5-940|https://issues.apache.org/jira/browse/TAP5-940].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
