[jira] [Commented] (TAP5-2104) Dynamic template parser does not support t:container
[ https://issues.apache.org/jira/browse/TAP5-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431065#comment-15431065 ] Barry Books commented on TAP5-2104: --- I believe this is still a problem but easily solved with a mixin that removes t:container if needed so a fix is not required. > Dynamic template parser does not support t:container > > > Key: TAP5-2104 > URL: https://issues.apache.org/jira/browse/TAP5-2104 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3.4 >Reporter: Barry Books >Priority: Minor > Labels: bulk-close-candidate > > Templates must be valid XML so they must have 1 root element. Sometime it's > not desirable for that root element to be rendered in the final page so > t:container can be used as the root element. This works for pages and > components but not Dynamic component templates. When used in a Dynamic > template t:container is rendered as a component element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2548) Upgrade embedded Jetty and Tomcat versions
[ https://issues.apache.org/jira/browse/TAP5-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376813#comment-15376813 ] Barry Books commented on TAP5-2548: --- I think this would mostly affect test cases and testing and I would prefer not to mess with those when upgrading. I would create new non versioned name, leave the old ones and deprecate them. I suppose you could make the old ones refuse to run unless the correct version if found in the classpath. > Upgrade embedded Jetty and Tomcat versions > -- > > Key: TAP5-2548 > URL: https://issues.apache.org/jira/browse/TAP5-2548 > Project: Tapestry 5 > Issue Type: Dependency upgrade > Components: tapestry-runner >Reporter: Jochen Kemnade >Assignee: Jochen Kemnade > Labels: desired_for_5.5, patch > Fix For: 5.5.0 > > Attachments: > 0001-TAP5-2548-upgrade-embedded-Tomcat-and-Jetty-versions.patch > > > Since we are switching to Servlet 3.0 for Tapestry 5.5, we should upgrade the > embedded server versions. > Unfortunately the runner classes contain the servlet container versions in > their class names (Jetty7Runner and Tomcat6Runner). This means we can either > stay backward compatible and confuse users (e.g. start Jetty 8 from > Jetty7Runner) or rename the classes and break backward compatibility. I > prefer the latter. > Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2534) Add support for webjars
[
https://issues.apache.org/jira/browse/TAP5-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183232#comment-15183232
]
Barry Books commented on TAP5-2534:
---
I did see that JIRA but it's closed without an explanation. All I'm proposing
is adding
public static void contributeClasspathAssetAliasManager(MappedConfiguration
configuration) {
configuration.add("webjars", "META-INF/resources/webjars");
}
to the JavascriptModule so multiple 3rd party modules could use webjars without
a configuration conflict. I'm not proposing any existing code be converted to
webjars.
> Add support for webjars
> ---
>
> Key: TAP5-2534
> URL: https://issues.apache.org/jira/browse/TAP5-2534
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Barry Books
>Priority: Minor
> Labels: feature, improvement, patch
>
> The webjars project (webjars.org) packages javascript/css projects into jar
> files and publishes them to Maven Central so the can be managed like any
> other Java dependency. Supporting this in Tapestry is easy and they even have
> an example.
> Patch to follow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182997#comment-15182997 ] Barry Books commented on TAP5-2327: --- I believe you have to switch to Java 7 to get the servlet 3.0 spec and Jetty 7 in Tapestry test only supports 2.5. Currently setting the httpOnly flag is way more difficult than it should be because the framework does not support it at all. I do it now by overriding the service and always setting the httpOnly flag if I'm in production mode. The works OK if you always want to set the flag. I though about patching the service to log an error if the httponly flag is set but then the logs get filled up and in the end I decided not supporting httponly is a documentation problem. Either way would be fine with me but I think the application should be able to set the httpOnly flag and have the service adapt to whatever the environment is. I'm also assuming this will be in 5.5 anyway. > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch, > 0002-TAP-2327-add-support-for-version-and-comment.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174001#comment-15174001 ] Barry Books commented on TAP5-2099: --- It passed the tapestry ones with one exception. There was a test that check set throws an exception. I changed that test. I'll take your tests and create a new patch with them included. FYI: I dug thru the code last weekend and the value for the field is stored in a local variable in readFromBinding() in ParameterWorker. Also from writeToBinding // An unbound parameter acts like a simple field // with no side effects. so and empty set() method on the binding really does the same thing as a parameter with no binding > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: > 0001-TAP-2099-Add-set-method-that-does-nothing-so-Literal.patch, > TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2536) Create DateRange picker
Barry Books created TAP5-2536: - Summary: Create DateRange picker Key: TAP5-2536 URL: https://issues.apache.org/jira/browse/TAP5-2536 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor Create a DateRanger picker. Patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2535) Create Alternative to DatePicker
Barry Books created TAP5-2535: - Summary: Create Alternative to DatePicker Key: TAP5-2535 URL: https://issues.apache.org/jira/browse/TAP5-2535 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor The current date picker has several issues that are difficult to fix in a backward compatible way. The new Datepicker should just use the existing textfield and convert the appropriate datatype just like Integer, Float etc. It should also fit into the new Bootstrap theme. Patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TAP5-2534) Add support for webjars
Barry Books created TAP5-2534: - Summary: Add support for webjars Key: TAP5-2534 URL: https://issues.apache.org/jira/browse/TAP5-2534 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor The webjars project (webjars.org) packages javascript/css projects into jar files and publishes them to Maven Central so the can be managed like any other Java dependency. Supporting this in Tapestry is easy and they even have an example. Patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2533) Form/BeanEditor Templates
[ https://issues.apache.org/jira/browse/TAP5-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2533: -- Attachment: 0001-TAP-2533-BeanEditTemplate-mixin.patch Patch for BeanEditTemplate mixin and test case > Form/BeanEditor Templates > - > > Key: TAP5-2533 > URL: https://issues.apache.org/jira/browse/TAP5-2533 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Barry Books >Priority: Minor > Labels: features, improvement, patch > Attachments: 0001-TAP-2533-BeanEditTemplate-mixin.patch > > > The current BeanEditor is great for prototyping but needs better formatting > control. > Create a mixin that adds templates to Form/BeadEditor. The mixin takes a > block parameter with property markers. The property components are moved from > the form body into the template. Templates are implemented as a mixin so it's > possible to create different ones for different html frameworks. The included > one is for Bootstrap. > patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2532) Add Object editor to PropertyEditBlocks
[
https://issues.apache.org/jira/browse/TAP5-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Books updated TAP5-2532:
--
Attachment: 0001-TAP-2532-Add-property-editor-for-object.patch
Patch includes object property editor and test cases
> Add Object editor to PropertyEditBlocks
> ---
>
> Key: TAP5-2532
> URL: https://issues.apache.org/jira/browse/TAP5-2532
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Barry Books
>Priority: Minor
> Labels: features, patch
> Attachments: 0001-TAP-2532-Add-property-editor-for-object.patch
>
>
> Create an object edit block in PropertyEditBlocks so BeanEditor can edit an
> Object like
> class Person {
> Name name;
> Address address;
> ...
> }
> by just contributing the following
> public static void
> contributeDefaultDataTypeAnalyzer(@SuppressWarnings("rawtypes")
> MappedConfiguration configuration) {
> configuration.add(Name.class, "name");
> configuration.add(Address.class, "address");
> }
> @Contribute(BeanBlockSource.class)
> public static void
> provideDefaultBeanBlocks(Configuration configuration) {
> configuration.add( new EditBlockContribution("Name",
> "PropertyEditBlocks", "Object"));
> configuration.add( new EditBlockContribution("Address",
> "PropertyEditBlocks", "Object"));
> }
> Patch to follow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2533) Form/BeanEditor Templates
Barry Books created TAP5-2533: - Summary: Form/BeanEditor Templates Key: TAP5-2533 URL: https://issues.apache.org/jira/browse/TAP5-2533 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor The current BeanEditor is great for prototyping but needs better formatting control. Create a mixin that adds templates to Form/BeadEditor. The mixin takes a block parameter with property markers. The property components are moved from the form body into the template. Templates are implemented as a mixin so it's possible to create different ones for different html frameworks. The included one is for Bootstrap. patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2532) Add Object editor to PropertyEditBlocks
[
https://issues.apache.org/jira/browse/TAP5-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Books updated TAP5-2532:
--
Description:
Create an object edit block in PropertyEditBlocks so BeanEditor can edit an
Object like
class Person {
Name name;
Address address;
...
}
by just contributing the following
public static void
contributeDefaultDataTypeAnalyzer(@SuppressWarnings("rawtypes")
MappedConfiguration configuration) {
configuration.add(Name.class, "name");
configuration.add(Address.class, "address");
}
@Contribute(BeanBlockSource.class)
public static void
provideDefaultBeanBlocks(Configuration configuration) {
configuration.add( new EditBlockContribution("Name",
"PropertyEditBlocks", "Object"));
configuration.add( new EditBlockContribution("Address",
"PropertyEditBlocks", "Object"));
}
Patch to follow
was:
Create an object edit block in PropertyEditBlocks so BeanEditor can edit an
Object like
class Person {
Name name;
Address address;
...
}
by just contributing the following
public static void
contributeDefaultDataTypeAnalyzer(@SuppressWarnings("rawtypes")
MappedConfiguration configuration) {
configuration.add(Name.class, "name");
configuration.add(Address.class, "address");
}
@Contribute(BeanBlockSource.class)
public static void
provideDefaultBeanBlocks(Configuration configuration) {
configuration.add( new EditBlockContribution("Name",
"PropertyEditBlocks", "Object"));
configuration.add( new EditBlockContribution("Address",
"PropertyEditBlocks", "Object"));
}
Patch to follow
> Add Object editor to PropertyEditBlocks
> ---
>
> Key: TAP5-2532
> URL: https://issues.apache.org/jira/browse/TAP5-2532
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Barry Books
>Priority: Minor
> Labels: features, patch
>
> Create an object edit block in PropertyEditBlocks so BeanEditor can edit an
> Object like
> class Person {
> Name name;
> Address address;
> ...
> }
> by just contributing the following
> public static void
> contributeDefaultDataTypeAnalyzer(@SuppressWarnings("rawtypes")
> MappedConfiguration configuration) {
> configuration.add(Name.class, "name");
> configuration.add(Address.class, "address");
> }
> @Contribute(BeanBlockSource.class)
> public static void
> provideDefaultBeanBlocks(Configuration configuration) {
> configuration.add( new EditBlockContribution("Name",
> "PropertyEditBlocks", "Object"));
> configuration.add( new EditBlockContribution("Address",
> "PropertyEditBlocks", "Object"));
> }
> Patch to follow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TAP5-2532) Add Object editor to PropertyEditBlocks
Barry Books created TAP5-2532:
-
Summary: Add Object editor to PropertyEditBlocks
Key: TAP5-2532
URL: https://issues.apache.org/jira/browse/TAP5-2532
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.4
Reporter: Barry Books
Priority: Minor
Create an object edit block in PropertyEditBlocks so BeanEditor can edit an
Object like
class Person {
Name name;
Address address;
...
}
by just contributing the following
public static void
contributeDefaultDataTypeAnalyzer(@SuppressWarnings("rawtypes")
MappedConfiguration configuration) {
configuration.add(Name.class, "name");
configuration.add(Address.class, "address");
}
@Contribute(BeanBlockSource.class)
public static void
provideDefaultBeanBlocks(Configuration configuration) {
configuration.add( new EditBlockContribution("Name",
"PropertyEditBlocks", "Object"));
configuration.add( new EditBlockContribution("Address",
"PropertyEditBlocks", "Object"));
}
Patch to follow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2099: -- Attachment: 0001-TAP-2099-Add-set-method-that-does-nothing-so-Literal.patch Override the AbstractBinding set method so Literal/Symbol bindings will not throw a read only exception when a parameter field is updated. This among other things allows a mixin to use BindParameter to override the default value of a component parameter. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: > 0001-TAP-2099-Add-set-method-that-does-nothing-so-Literal.patch, > TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2327: -- Attachment: 0002-TAP-2327-add-support-for-version-and-comment.patch Patch with support for version and comment. Perhaps nice to have but not as important as httpOnly since versions other than 0 are not widely supported. > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch, > 0002-TAP-2327-add-support-for-version-and-comment.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15169284#comment-15169284 ] Barry Books edited comment on TAP5-2327 at 2/26/16 4:40 PM: Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter versions of Java to set httpOnly by overriding the Cookies service was (Author: trsvax): Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the Cookies service > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15169284#comment-15169284 ] Barry Books edited comment on TAP5-2327 at 2/26/16 4:39 PM: Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the Cookies service was (Author: trsvax): Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the Cookie service > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15169284#comment-15169284 ] Barry Books edited comment on TAP5-2327 at 2/26/16 4:39 PM: Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the Cookie service was (Author: trsvax): Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the CookieSource service > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2327: -- Attachment: 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch Patch to add httpOnly method to support Servlet 3.0 spec. This will allow 5.4 apps built with latter version of Java to set httpOnly by overriding the CookieSource service > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7, 5.4 >Reporter: Martin Schneider > Attachments: > 0001-TAP-2327-add-httpOnly-method-to-support-Servlet-3.0.patch > > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166423#comment-15166423 ] Barry Books commented on TAP5-2099: --- I added some logging code to the GitHub project so you can see when get/set is called. it's been 3 years since I looked thru the code and I don't remember how the value is stored either. As far not calling the set method if isInvariant() is true I don't think that the right thing to do. isInvariant means get always returns the same value so the binding can be cached. Suppose I wanted to create an alt: binding to alternate between values as in alt:red,green,blue this binding would return isInvariant() false but the set method would still do nothing. The selector binding I wrote also returned isInvariant() false but the set method does nothing. I downloaded all the 5.4 source so I'll make a change, run the test cases and submit a patch if they pass. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159224#comment-15159224 ] Barry Books commented on TAP5-2099: --- I guess it depends on what you mean by stored. In the case above rowsperpage = 10; I'm guessing the 10 is stored as some final Integer in the JVM. That object is then assigned to the "field" which is not a field at all but the appears to contain an int. Before this assignment the "field" contained an object that appears to be an int but was really a Literal binding. If you look the Symbol binding is really a String provided by SymbolSource but the field in an int so even the type coercer is involved here. The binding is not responsible for storing the object but it can. In the example above the the value is not really the String in ComponentParameterConstants it's calculated on the fly from the expression passed to the factory and the SymbolSource. If you look at the provided LiteralBinding http://tapestry.apache.org/current/apidocs/src-html/org/apache/tapestry5/internal/bindings/LiteralBinding.html#line.27 it does store the value and the SymbolBindingFactory just gets the symbol value and returns a new LiteralBinding. There is quite a bit going on behind the scenes to make it appear that a component field is just a field and I'm not sure I understand it all either. The good news is the Binding interface is pretty simple but the documentation is a little bit too simple. The Binding interface provides two way communication back to the original object storage so that two way binding can be implemented. The get method provides an object that may be transformed from the original storage even calculated on the fly. For example you could create a random: binding that returns a random number. I created a selector: binding that created a JQuery selector to the element that is currently being rendered. The set method allows setting the original storage to a new value. The documentation also says most are readonly and the AbstractBinding which most extend throws and exception on set. I think that should say most bindings are one way. Perhaps some should throw an exception on set but personally I don't think a binding should cause a field to become readonly just because it's not interested in observing the fields changes. Hope that helps > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158978#comment-15158978 ] Barry Books commented on TAP5-2099: --- It's true if you want the object passed to the symbol binding updated to the new value the patch does not do that but I don't think that's possible or desirable. The symbol binding object does not have access to the symbol providers objects since the expression passed to the binding is a String and is not mutable. If it did and that was implemented the next usage of the symbol ComponentParameterConstants.GRID_ROWS_PER_PAGE would return something other than 6 and I think that would be a bug. The symbol bindings should be invariant. The above code does allow setting the field for the current request which is what I wanted to do and what I think the Jira ticket is about. I'll update the Github project tonight using the grid as an example. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[
https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158923#comment-15158923
]
Barry Books edited comment on TAP5-2099 at 2/23/16 2:20 PM:
I'm not sure I understand the scenario you are describing. The example I pasted
above
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
is from the grid. If I create a mixin
@BindParamter
int rowsPerPage;
void BeginRender() {
rowsperpage = 10;
}
The grid will now use 10 as the rows per page. If you mean something else fork
the project and try it. Keep in mind the sample project I posted only works for
literals. The code in this thread works for symbols which is what the grid
uses. I've been running something like the above code for almost 3 years now
and I have not had any problems I think were caused by it.
Ops crossed comments again. The sample code posted on github tests both
and
Both work as expected. I can update the Github project to try it with a grid
but I have to head off to work now so it will take me a while to get to it.
was (Author: trsvax):
I'm not sure I understand the scenario you are describing. The example I pasted
above
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
is from the grid. If I create a mixin
@BindParamter
int rowsPerPage;
void BeginRender() {
rowsperpage = 10;
}
The grid will now use 10 as the rows per page. If you mean something else fork
the project and try it. Keep in mind the sample project I posted only works for
literals. The code in this thread works for symbols which is what the grid
uses. I've been running something like the above code for almost 3 years now
and I have not had any problems I think were caused by it.
Ops crossed comments again. The sample code a posted on github tests both
and
Both work as expected. I can update the Github project to try it with a grid
but I have to head off to work now so it will take me a while to get to it.
> Update parameters bound to literal: or symbol: from a mixin
> ---
>
> Key: TAP5-2099
> URL: https://issues.apache.org/jira/browse/TAP5-2099
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6, 5.4
>Reporter: Lance
> Labels: patch
> Attachments: TAP52099-1.patch
>
>
> Currently, I cannot update a component component parameter that is
> initialized with a literal: or symbol: binding from a mixin. If I try to
> @BindParameter the param and change it's value, I get a "Binding %s is
> read-only" exception (originating from AbstractBinding).
> I propose that literal and symbol bindings are sourced from a PerThreadValue
> that can be updated by a mixin.
> My original need for this was to create a "SinglePage" mixin for the Grid
> component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I
> can't currently do this because by default, the parameter is a symbol:
> binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[
https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158923#comment-15158923
]
Barry Books edited comment on TAP5-2099 at 2/23/16 2:20 PM:
I'm not sure I understand the scenario you are describing. The example I pasted
above
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
is from the grid. If I create a mixin
@BindParamter
int rowsPerPage;
void BeginRender() {
rowsperpage = 10;
}
The grid will now use 10 as the rows per page. If you mean something else fork
the project and try it. Keep in mind the sample project I posted only works for
literals. The code in this thread works for symbols which is what the grid
uses. I've been running something like the above code for almost 3 years now
and I have not had any problems I think were caused by it.
Ops crossed comments again. The sample code a posted on github tests both
and
Both work as expected. I can update the Github project to try it with a grid
but I have to head off to work now so it will take me a while to get to it.
was (Author: trsvax):
I'm not sure I understand the scenario you are describing. The example I pasted
above
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
is from the grid. If I create a mixin
@BindParamter
int rowsPerPage;
void BeginRender() {
rowsperpage = 10;
}
The grid will now use 10 as the rows per page. If you mean something else fork
the project and try it. Keep in mind the sample project I posted only works for
literals. The code in this thread works for symbols which is what the grid
uses. I've been running something like the above code for almost 3 years now
and I have not had any problems I think were caused by it.
> Update parameters bound to literal: or symbol: from a mixin
> ---
>
> Key: TAP5-2099
> URL: https://issues.apache.org/jira/browse/TAP5-2099
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6, 5.4
>Reporter: Lance
> Labels: patch
> Attachments: TAP52099-1.patch
>
>
> Currently, I cannot update a component component parameter that is
> initialized with a literal: or symbol: binding from a mixin. If I try to
> @BindParameter the param and change it's value, I get a "Binding %s is
> read-only" exception (originating from AbstractBinding).
> I propose that literal and symbol bindings are sourced from a PerThreadValue
> that can be updated by a mixin.
> My original need for this was to create a "SinglePage" mixin for the Grid
> component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I
> can't currently do this because by default, the parameter is a symbol:
> binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[
https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158923#comment-15158923
]
Barry Books commented on TAP5-2099:
---
I'm not sure I understand the scenario you are describing. The example I pasted
above
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
is from the grid. If I create a mixin
@BindParamter
int rowsPerPage;
void BeginRender() {
rowsperpage = 10;
}
The grid will now use 10 as the rows per page. If you mean something else fork
the project and try it. Keep in mind the sample project I posted only works for
literals. The code in this thread works for symbols which is what the grid
uses. I've been running something like the above code for almost 3 years now
and I have not had any problems I think were caused by it.
> Update parameters bound to literal: or symbol: from a mixin
> ---
>
> Key: TAP5-2099
> URL: https://issues.apache.org/jira/browse/TAP5-2099
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6, 5.4
>Reporter: Lance
> Labels: patch
> Attachments: TAP52099-1.patch
>
>
> Currently, I cannot update a component component parameter that is
> initialized with a literal: or symbol: binding from a mixin. If I try to
> @BindParameter the param and change it's value, I get a "Binding %s is
> read-only" exception (originating from AbstractBinding).
> I propose that literal and symbol bindings are sourced from a PerThreadValue
> that can be updated by a mixin.
> My original need for this was to create a "SinglePage" mixin for the Grid
> component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I
> can't currently do this because by default, the parameter is a symbol:
> binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158881#comment-15158881 ] Barry Books edited comment on TAP5-2099 at 2/23/16 1:45 PM: There are multiple things at play here. Here is how I think things work. It's true the components are singletons but the fields are not really fields otherwise two concurrent pages would share the same data. The fields are really conduits and in this case the conduit points to a literal binding by default. If code tries to set that field the conduit will point to the new object and the bindings set method will be called to inform the literal binding the field value has changed. This is how two way binding is implemented. Currently for a literal that throws an exception. My thought is the owner of the literal does not want it's value changed and does not care if the field is changed so the set method does nothing but the field is still changed to the new value. If you run the project on Github you will see that the field value is changed by the mixin. I guess to your point what I want to happen is the field is set. Currently the side effect is throw an exception. I want the side effect to do nothing. was (Author: trsvax): There are multiple things at play here. Here is how I think things work. It's true the components are singletons but the fields are not really fields otherwise two concurrent pages would share the same data. The fields are really conduits and in this case the conduit points to a literal binding by default. If code tries to set that field the conduit will point to the new object and the bindings set method will be called to inform the literal binding the field value has changed. This is how two way binding is implemented. Currently for a literal that throws an exception. My thought is the owner of the literal does not want it's value changed and does not care if the field is changed so the set method does nothing but the field is still changed to the new value. If you run the project on Github you will see that the field value is changed by the mixin. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158881#comment-15158881 ] Barry Books commented on TAP5-2099: --- There are multiple things at play here. Here is how I think things work. It's true the components are singletons but the fields are not really fields otherwise two concurrent pages would share the same data. The fields are really conduits and in this case the conduit points to a literal binding by default. If code tries to set that field the conduit will point to the new object and the bindings set method will be called to inform the literal binding the field value has changed. This is how two way binding is implemented. Currently for a literal that throws an exception. My thought is the owner of the literal does not want it's value changed and does not care if the field is changed so the set method does nothing but the field is still changed to the new value. If you run the project on Github you will see that the field value is changed by the mixin. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158858#comment-15158858 ] Barry Books commented on TAP5-2099: --- That test case fails because it calls the set method and then calls the get method and expects it to return what it just set and the code I proposed will not pass that test because the set method does nothing. That test will not pass with the current implementation either. Whether that test is valid depends on what you think setting a literal should do. It's possible to make that test pass by returning false from isInvariant, adding a local variable and using it for the get and set methods but I'm not sure that's the correct functionality for a literal. A literal should be invariant and should always return the same value. The same goes for a Symbol. Personally I think the test should check that the value returned by the get should not change. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158847#comment-15158847 ] Barry Books commented on TAP5-2099: --- Ok it' the patch test case that fails. I'll take a look > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158837#comment-15158837 ] Barry Books commented on TAP5-2099: --- I don't have 5.4 on my machine to build. What test cases fail? > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158816#comment-15158816 ] Barry Books commented on TAP5-2099: --- It's true a call to get on the literal binding will return the old value but it's no longer assigned to the field. Just like String A = "A"; String B = A; B = "B"; A is still "A" but B is now "B" I created a demo of this https://github.com/trsvax/Sandbox > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6, 5.4 >Reporter: Lance > Labels: patch > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158053#comment-15158053 ] Barry Books commented on TAP5-2099: --- My understanding of the binding interface is the set method's purpose is to implement the two way binding not to "store" the value. In other words it sets the value in the caller not the value in the field. The documentation does say "updates the value" but it's not clear what value it's referring to. In the case of literal and symbol the providers for the values are not interesting in the new value because they are not going to do anything with it anyway. The current implementation of AbstractBinding throws an error on set and perhaps that's appropriate but the question is should literal and symbol override that? While it's true you can't update the value provided by @Symbol the question is should that be an error or should it just not do anything. I can see how throwing an error might be technically correct because you can't update the value but the fact is neither binding is interested in the updated value so I think these binding should just ignore the set and allow other things to update the parameter. I'm sure there are other ways to fix this but I've tried the code above and it seems to work and I don't think there is much risk because it does not really do anything other than not throw an error. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6 >Reporter: Lance > Labels: bulk-close-candidate > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157820#comment-15157820 ] Barry Books commented on TAP5-2327: --- It might also be useful to add setComment and setVersion methods since these are now supported in javax.servlet.http.Cookie. Again the current service could just ignore these but it would be possible to override with one that does support them. > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7 >Reporter: Martin Schneider > Labels: bulk-close-candidate > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[
https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157686#comment-15157686
]
Barry Books commented on TAP5-2099:
---
This is still an issue in 5.4. The question is what should happen when a
literal or a symbol is provided to a Component parameter and then something
tries to update it. Currently both literal and symbol extend AbstractBinding
which throws an exception when it's set method is called. I think both of these
bindings should override the default set method with a method that does
nothing. In the case of something like this
@Parameter(BindingConstants.SYMBOL + ":" +
ComponentParameterConstants.GRID_ROWS_PER_PAGE)
private int rowsPerPage;
There is no purpose in informing the symbol provider that something has written
the field it's value is assigned to and the property should not be read only
just because a constant has been assigned to it.
The following code overrides symbol and demonstrates this:
public static void contributeBindingSource(MappedConfiguration configuration,
final SymbolSource symbolSource) {
configuration.override(BindingConstants.SYMBOL, new
BindingFactory() {
@Override
public Binding newBinding(String description,
ComponentResources container, ComponentResources component,
final String expression, final Location
location) {
return new AbstractBinding(location) {
@Override
public void set(Object value) {
}
@Override
public Object get() {
return
symbolSource.valueForSymbol(expression);
}
};
}
});
}
> Update parameters bound to literal: or symbol: from a mixin
> ---
>
> Key: TAP5-2099
> URL: https://issues.apache.org/jira/browse/TAP5-2099
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.3.6
>Reporter: Lance
> Labels: bulk-close-candidate
> Attachments: TAP52099-1.patch
>
>
> Currently, I cannot update a component component parameter that is
> initialized with a literal: or symbol: binding from a mixin. If I try to
> @BindParameter the param and change it's value, I get a "Binding %s is
> read-only" exception (originating from AbstractBinding).
> I propose that literal and symbol bindings are sourced from a PerThreadValue
> that can be updated by a mixin.
> My original need for this was to create a "SinglePage" mixin for the Grid
> component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I
> can't currently do this because by default, the parameter is a symbol:
> binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[
https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157307#comment-15157307
]
Barry Books commented on TAP5-2327:
---
I don't think I can update the version number but this is still a problem in
5.4. To fix this the following should be added to the CookieBuilder class:
protected boolean httpOnly;
public CookieBuilder setHttpOnly(boolean httpOnly) {
this.httpOnly = httpOnly;
return this;
}
The current CookiesImpl service will continue to work as is for servlet 2.5 but
I will be possible to override it with a version for servlet 3.0
> The Cookies interface should provide an option to mark cookies as httpOnly
> --
>
> Key: TAP5-2327
> URL: https://issues.apache.org/jira/browse/TAP5-2327
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
>Affects Versions: 5.3.7
>Reporter: Martin Schneider
> Labels: bulk-close-candidate
>
> Since Servlet 3.0 there is an option to mark cookies as httpOnly via
> javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to
> use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default
> implementation does not set the httpOnly flag.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TAP5-2327) The Cookies interface should provide an option to mark cookies as httpOnly
[ https://issues.apache.org/jira/browse/TAP5-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704812#comment-14704812 ] Barry Books commented on TAP5-2327: --- I needed httpOnly cookies but Tapestry also uses Jetty 7 for testing so I wrote a method that uses reflection to see of the httpOnly method is available and calls it if it's there. This allows you to run in a 2.5 container and use httpOnly if you are in a 3.0 container. > The Cookies interface should provide an option to mark cookies as httpOnly > -- > > Key: TAP5-2327 > URL: https://issues.apache.org/jira/browse/TAP5-2327 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3.7 >Reporter: Martin Schneider > Labels: security > > Since Servlet 3.0 there is an option to mark cookies as httpOnly via > javax.servlet.http.Cookie.setHttpOnly(boolean). There should be an option to > use that in org.apache.tapestry5.services.Cookies. In 5.3.7 the default > implementation does not set the httpOnly flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-2174) Add main method the Jetty7Runner
[
https://issues.apache.org/jira/browse/TAP5-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114177#comment-14114177
]
Barry Books commented on TAP5-2174:
---
public static void main(String[] args) throws Exception {
String webapp = "src/main/webapp";
String context = "/";
Integer httpPort = 8080;
Integer sslPort = 8443;
boolean usage = false;
for ( int i = 0; i < args.length; i++ ) {
if ( "-webapp".equals(args[i])) {
if ( ++i >= args.length ) {
usage = true;
} else {
webapp = args[i];
}
} else if ( "-context".equals(args[i])) {
if ( ++i >= args.length ) {
usage = true;
} else {
context = args[i];
}
} else if ( "-httpPort".equals(args[i])) {
if ( ++i >= args.length ) {
usage = true;
} else {
try {
httpPort = new Integer(args[i]);
} catch (Exception e) {
usage = true;
}
}
} else if ( "-sslPort".equals(args[i])) {
if ( ++i >= args.length ) {
usage = true;
} else {
try {
sslPort = new Integer(args[i]);
} catch (Exception e) {
usage = true;
}
}
} else if ( "-?".equals(args[i])) {
usage = true;
}
}
if ( usage ) {
System.out.println("usage: -webapp src/main/webapp
-context / -httpPort 8080 -sslPort 8443 -?");
} else {
new Jetty7Runner(webapp, context, httpPort, sslPort);
}
}
> Add main method the Jetty7Runner
>
>
> Key: TAP5-2174
> URL: https://issues.apache.org/jira/browse/TAP5-2174
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-test
>Affects Versions: 5.4
>Reporter: Barry Books
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Labels: enhancement
>
> Please add a main method to Jetty7Runner (really in tapestry-runner) so Jetty
> can easily be started from an IDE development environment. Something like
> public static void main(String[] args) throws Exception {
> String webapp = System.getProperty("webapp") == null ?
> "src/main/webapp" : System.getProperty("webapp");
> String context = System.getProperty("context") == null ? "/" :
> System.getProperty("context");
> String httpPort = System.getProperty("httpPort") == null ?
> "8080" : System.getProperty("httpPort");
> String sslPort = System.getProperty("sslPort") == null ? "8443"
> : System.getProperty("sslPort");
> new Jetty7Runner(webapp, context, new Integer(httpPort), new
> Integer(sslPort));
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2174) Add main method the Jetty7Runner
[
https://issues.apache.org/jira/browse/TAP5-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113834#comment-14113834
]
Barry Books commented on TAP5-2174:
---
I'll create a command line patch and post it
> Add main method the Jetty7Runner
>
>
> Key: TAP5-2174
> URL: https://issues.apache.org/jira/browse/TAP5-2174
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-test
>Affects Versions: 5.4
>Reporter: Barry Books
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Labels: enhancement
>
> Please add a main method to Jetty7Runner (really in tapestry-runner) so Jetty
> can easily be started from an IDE development environment. Something like
> public static void main(String[] args) throws Exception {
> String webapp = System.getProperty("webapp") == null ?
> "src/main/webapp" : System.getProperty("webapp");
> String context = System.getProperty("context") == null ? "/" :
> System.getProperty("context");
> String httpPort = System.getProperty("httpPort") == null ?
> "8080" : System.getProperty("httpPort");
> String sslPort = System.getProperty("sslPort") == null ? "8443"
> : System.getProperty("sslPort");
> new Jetty7Runner(webapp, context, new Integer(httpPort), new
> Integer(sslPort));
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2192) Add support for distributed documentation
[ https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058917#comment-14058917 ] Barry Books commented on TAP5-2192: --- Forgot to mention Maven provides MavenXpp3Reader so it's super simple to parse a pom file. > Add support for distributed documentation > - > > Key: TAP5-2192 > URL: https://issues.apache.org/jira/browse/TAP5-2192 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.4 >Reporter: Barry Books >Assignee: Thiago H. de Paula Figueiredo > Labels: documentation, month-of-tapestry > > Please add support for a distributed documentation system. The basic > requirements are: > 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver > supports pages) > 2. Access to a Map of all Configurations. The map would have the > configuration class as the Key and contain an object such a list or map that > contains the configuration. > 3. Access to a list of configured services. > From this it should be possible to build documentation of a running system. > Thanks > Barry -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2192) Add support for distributed documentation
[ https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058895#comment-14058895 ] Barry Books commented on TAP5-2192: --- You can have all the code you need. I have not looked at it in a while but it's here https://github.com/tapestry-modules/tapestry-modules I've you need something else let me know and I'll try and create it. Personally I think it would be best just to say if you want documentation provide a pom file. You would not need to include all the things required to build a project but there is a lot of useful info in this section http://maven.apache.org/pom.html#More_Project_Information This way there is one and only one way to find out information about the module and it's all ready a standard (and documented). > Add support for distributed documentation > - > > Key: TAP5-2192 > URL: https://issues.apache.org/jira/browse/TAP5-2192 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.4 >Reporter: Barry Books >Assignee: Thiago H. de Paula Figueiredo > Labels: documentation, month-of-tapestry > > Please add support for a distributed documentation system. The basic > requirements are: > 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver > supports pages) > 2. Access to a Map of all Configurations. The map would have the > configuration class as the Key and contain an object such a list or map that > contains the configuration. > 3. Access to a list of configured services. > From this it should be possible to build documentation of a running system. > Thanks > Barry -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2192) Add support for distributed documentation
[ https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058854#comment-14058854 ] Barry Books commented on TAP5-2192: --- I like the idea of getting all the info from a pom.xml file if it's in the jar. I already wrote some code that can take a pom file and generate a documentation site and since it's an XML document I'm guessing it's possible to add more elements if needed. This way you don't need the CompoentLibraryInfoSource at all. > Add support for distributed documentation > - > > Key: TAP5-2192 > URL: https://issues.apache.org/jira/browse/TAP5-2192 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.4 >Reporter: Barry Books >Assignee: Thiago H. de Paula Figueiredo > Labels: documentation, month-of-tapestry > > Please add support for a distributed documentation system. The basic > requirements are: > 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver > supports pages) > 2. Access to a Map of all Configurations. The map would have the > configuration class as the Key and contain an object such a list or map that > contains the configuration. > 3. Access to a list of configured services. > From this it should be possible to build documentation of a running system. > Thanks > Barry -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2192) Add support for distributed documentation
[ https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054438#comment-14054438 ] Barry Books commented on TAP5-2192: --- In 2 I was referring to configurations such as Map, Ordered etc. I though you could only have one configuration per service. If that's not the case or you solution provides more data the mechanism does not really matter to me. > Add support for distributed documentation > - > > Key: TAP5-2192 > URL: https://issues.apache.org/jira/browse/TAP5-2192 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.4 >Reporter: Barry Books >Assignee: Thiago H. de Paula Figueiredo > Labels: documentation, month-of-tapestry > > Please add support for a distributed documentation system. The basic > requirements are: > 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver > supports pages) > 2. Access to a Map of all Configurations. The map would have the > configuration class as the Key and contain an object such a list or map that > contains the configuration. > 3. Access to a list of configured services. > From this it should be possible to build documentation of a running system. > Thanks > Barry -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2192) Add support for distributed documentation
[
https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054366#comment-14054366
]
Barry Books commented on TAP5-2192:
---
I created this Jira because I started writing a documentation module and found
that to be impossible because there is no way to get a list of what's
installed. I think it would also be useful to have a documentation mapped
configuration that modules could contribute to if they want to. As Lance said
it would be useful to define these interfaces in Tapestry but I think the code
that shows the documentation should be in a separate module
(tapestry-documentaton?). This way if you include that you get it. Personally I
would want it on my development machine but not in production. This way if a
module cares to it could add something like this to it's module.
@Contribute(ModuleDocumentationService.class)
public static void arbitraryMethodName(MappedConfiguration configuration)
{
configuration.add("ModuleName", new My ComponentLibraryInfo());
}
This way core just needs to define two interfaces. One for the Service and one
for the Documentation. The service one is easy it just needs to return the
configuration map. I think Lance's ComonentLibraryInfo is a good start.
> Add support for distributed documentation
> -
>
> Key: TAP5-2192
> URL: https://issues.apache.org/jira/browse/TAP5-2192
> Project: Tapestry 5
> Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Barry Books
>Assignee: Thiago H. de Paula Figueiredo
> Labels: documentation, month-of-tapestry
>
> Please add support for a distributed documentation system. The basic
> requirements are:
> 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver
> supports pages)
> 2. Access to a Map of all Configurations. The map would have the
> configuration class as the Key and contain an object such a list or map that
> contains the configuration.
> 3. Access to a list of configured services.
> From this it should be possible to build documentation of a running system.
> Thanks
> Barry
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014626#comment-14014626 ] Barry Books commented on TAP5-2211: --- Thiago, I see you picked this up. If you want to use (or start with) the one I wrote https://github.com/trsvax/tapestry-datepicker you are welcome to it. I've been using it for a while without any issues. > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2183) 5.4 Linksubmit does not generate events with Bootstrap glyphicon
[ https://issues.apache.org/jira/browse/TAP5-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945907#comment-13945907 ] Barry Books commented on TAP5-2183: --- Thus was a long time ago. I'll test it again > 5.4 Linksubmit does not generate events with Bootstrap glyphicon > > > Key: TAP5-2183 > URL: https://issues.apache.org/jira/browse/TAP5-2183 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Barry Books > > It appears for some reason the link submit component does not work > correctly if the only thing it contains is a Bootstrap glyphicon. > For example: > Change > calls the changeCart event handler > > does not -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809443#comment-13809443 ] Barry Books commented on TAP5-2211: --- I was going to use this one instead of jQuery but it was not done yet. I'll try and create a mixin with it and add it to my datepicker probject > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809306#comment-13809306 ] Barry Books commented on TAP5-2211: --- I would keep an eye on this project http://angular-ui.github.io/bootstrap/ > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808701#comment-13808701 ] Barry Books commented on TAP5-2211: --- I looked at using modernizer and I don't think it supports that yet, but I think that's a good direction to head. From modernizr docs: "These types can enable native datepickers, colorpickers, URL validation, and so on. If a browser doesn’t support a given type, it will be rendered as a text field. Modernizr cannot detect that date inputs create a datepicker, the color input create a colorpicker, and so on—it will detect that the input values are sanitized based on the spec. In the case of WebKit, we have received confirmation that sanitization will not be added without the UI widgets being in place." There is an issue with the jQuery datepicker and the calendar button. Ideally you could use the Bootstrap calendar icon but the jQuery datepicker does not support that. Any other problems I'd be interesting in hearing about. Just create a github issue. The datepicker I wrote is very different than the one included in Tapestry. It's much better if you want every datepicker on your site to be the same because it's more difficult to add format types. I've found this to be a feature but it's not obvious when you first use it. Oddly enough it does work better with BeanEditForm because you can easily customize it in your AppModule. You can also create datatypes that map to formats which is also a nice feature. The only real drawback is if you want to create date formats at runtime and that problem could be solved if a mixing could override the textfield translator. At this point I think Thiago's suggestion my be the best one. Deprecate the current datepicker and provide recommendations to create your own. I'm not sure it's possible to create a one size fits all datepicker. > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808602#comment-13808602 ] Barry Books commented on TAP5-2211: --- I'm not sure how a subclass would solve the problem. DateFormat is an interface and has no method for getting the format. As far as mapping goes I think some cases would map but I don't think you could create a general purpose mapping function. Also TextField works just fine in BeanEditor https://github.com/trsvax/tapestry-datepicker/blob/master/src/main/java/com/trsvax/datepicker/pages/AppPropertyEditBlocks.java I'm in favor of the jQuery datepicker but I don't think it's possible to build a drop in replacement with it. > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808518#comment-13808518 ] Barry Books commented on TAP5-2211: --- I don't think it's possible to build a datepicker component that uses the jQuery datapicker and is compatible with the current Tapestry datepicker. The current datepicker makes a call back to the java side to validate the date while the jQuery datepicker does this on the client side. The current datepicker takes a DateFormat as a parameter and this causes at least two problems. First is DateFormat does not have a method to get the format string and the second is even if it did the jQuery datapicker does not use the same format as Java. Given that what's the next step? While it seems simple to build a datepicker the reality is it's complicated and even more so if you include localization. How do you get the localized date format string for both Java and jQuery datepicker? If you swap the jQuery datepicker for another one should it still work? From what I can tell different javascript datapickers have different date formats. Should it support input type='date' and work? This introduces other issues since it does not appear the date format is specified by the W3. IMHO the correct way to implement this is with textField and a mixin where the mixin provides the Javascript. The one thing that keeps this from really working is the mixin cannot set the translator in the textfield because it has a default value which makes it read only. If you could set the translator then you could do something like and make it work. I would be a big fan of allowing a mixin to overwrite a default value in a component > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795618#comment-13795618
]
Barry Books commented on TAP5-1611:
---
You are correct. I would be nice if that was fixed. I'm going to go vote on it.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795545#comment-13795545
]
Barry Books commented on TAP5-1611:
---
I'll take a look at that. My problem is I tried to @Bind a mixin parameter to
the textfield translate parameter but when I try and set it from the mixin it's
read only. Perhaps I can use the DefaultProvider to make a default that's not
read only.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795436#comment-13795436
]
Barry Books commented on TAP5-1611:
---
I do think it's easy to fix just declare the components in the tml file.
If the types don't match (such as datafield) I'm not sure overriding the block
would help. I think you would get a class cast exception when using any of the
blocks in the page.
Personally I'd like to override TextField because it sets a default translator
that can't be overridden with a mixin.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795363#comment-13795363
]
Barry Books commented on TAP5-1611:
---
My concern is if you override anything used by propertyEditBlocks
https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=blob;f=tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyEditBlocks.java;h=9ab91e920d5dd5188f651e3ccb4c5a441c3cd24d;hb=HEAD
you will break the entire page and no beanEditForms will work. I would suggest
fixing the Edit/Display blocks pages so they work if the component is
overridden. This would also server and an example for how to do things going
forward
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795260#comment-13795260
]
Barry Books commented on TAP5-1611:
---
I agree about starting fresh and the Datepicker I wrote does exactly that. The
question is what happens if you try and override a component that does not have
a common interface. I think in the case above it cannot cause the page to break
because there is no simple way to fix it. It could just continue to use the
existing Tapestry Component.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795079#comment-13795079
]
Barry Books commented on TAP5-1611:
---
I don't think failure is an option in this case. Typically a module has one
AppPropertyEditBlock page. If one of the blocks is invalid the whole page will
not compile and you would have to provide an override for every block in the
page.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795061#comment-13795061
]
Barry Books commented on TAP5-1611:
---
True (and I think the documentation should reflect that) but you can also do
this
@MixinClasses(value=JQueryDatePicker.class)
@Component(parameters =
{ "value=context.propertyValue", "label=prop:context.label",
"translate=prop:dateTranslator",
"validate=prop:dateValidator",
"clientId=prop:context.propertyId",
"annotationProvider=context" })
private TextField dateField;
which is common in propertyEditBlocks
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795049#comment-13795049
]
Barry Books commented on TAP5-1611:
---
It does seem like you might need to extend the components/mixins to make this
work.
@InjectComponent
private Form form;
is pretty common
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791441#comment-13791441
]
Barry Books commented on TAP5-1611:
---
This would be a really useful feature. Could it work for mixins also? I think
there could be many uses for this. For example I noticed 5.4 uses a mixin to
add the bootstrap markup the EditBlocks. It would be great if I could override
that mixin and replace it with one that supported a different framework.
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: IOC, component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TAP5-2192) Add support for distributed documentation
Barry Books created TAP5-2192: - Summary: Add support for distributed documentation Key: TAP5-2192 URL: https://issues.apache.org/jira/browse/TAP5-2192 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.4 Reporter: Barry Books Please add support for a distributed documentation system. The basic requirements are: 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver supports pages) 2. Access to a Map of all Configurations. The map would have the configuration class as the Key and contain an object such a list or map that contains the configuration. 3. Access to a list of configured services. >From this it should be possible to build documentation of a running system. Thanks Barry -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TAP5-2183) 5.4 Linksubmit does not generate events with Bootstrap glyphicon
Barry Books created TAP5-2183: - Summary: 5.4 Linksubmit does not generate events with Bootstrap glyphicon Key: TAP5-2183 URL: https://issues.apache.org/jira/browse/TAP5-2183 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books It appears for some reason the link submit component does not work correctly if the only thing it contains is a Bootstrap glyphicon. For example: Change calls the changeCart event handler does not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768364#comment-13768364 ] Barry Books commented on TAP5-2182: --- Bootstrap 2.3 supported labels and input on the same line but Bootstrap 3 appears to have dropped this feature. For Bootstrap 2.3 I had a mixin that would output the old format but it no longer works. I suspect this is part of the mobile first direction. Personally I prefer the new way and I would call it a feature but you are correct the input fields will take 100% of the width available. Putting them inside a column fixes this. > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2169) Core stack is not included by default
[ https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764736#comment-13764736 ] Barry Books commented on TAP5-2169: --- I agree things should work out of the box but turning the off the default style sheets was difficult in 5.3 so I'd say if this is implemented it should be easy to turn off via the AppModule. > Core stack is not included by default > - > > Key: TAP5-2169 > URL: https://issues.apache.org/jira/browse/TAP5-2169 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Minor > > For simple applications, "core" stack is not included, which breaks the UI, > because bootstrap.css and other assets are not loaded. > I think "core" stack should be forced to be included (possibly optionally > turned off by config) > but it should be included by default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2174) Add main method the Jetty7Runner
Barry Books created TAP5-2174:
-
Summary: Add main method the Jetty7Runner
Key: TAP5-2174
URL: https://issues.apache.org/jira/browse/TAP5-2174
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-test
Affects Versions: 5.4
Reporter: Barry Books
Priority: Minor
Please add a main method to Jetty7Runner (really in tapestry-runner) so Jetty
can easily be started from an IDE development environment. Something like
public static void main(String[] args) throws Exception {
String webapp = System.getProperty("webapp") == null ?
"src/main/webapp" : System.getProperty("webapp");
String context = System.getProperty("context") == null ? "/" :
System.getProperty("context");
String httpPort = System.getProperty("httpPort") == null ?
"8080" : System.getProperty("httpPort");
String sslPort = System.getProperty("sslPort") == null ? "8443"
: System.getProperty("sslPort");
new Jetty7Runner(webapp, context, new Integer(httpPort), new
Integer(sslPort));
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2173) Tapestry DateField converts invalid dates to valid ones.
Barry Books created TAP5-2173: - Summary: Tapestry DateField converts invalid dates to valid ones. Key: TAP5-2173 URL: https://issues.apache.org/jira/browse/TAP5-2173 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books The combination of the DateField component and the conversion of strings to SimpleDateFormat result in the DateField converting invalid dates to valid ones. There are really two problems. The default for SimpleDateFormat is lenient so strings are converted with lenient set to true. This causes the date conversion to changes dates like 9/32/2013 to Wed Oct 02 00:00:00 CDT 2013. The second problem is DateField allows extra characters after the valid part of the date. For example 9/01/2013 converts to Sun Sep 01 00:00:00 CDT 2013. This is more of a problem with formats such as -MM-dd because a date such as 2013-09-061 is allowed and converted to Thu Oct 31 00:00:00 CDT 2013. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2140) Choose Component
[ https://issues.apache.org/jira/browse/TAP5-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2140: -- Attachment: 0001-Choose-Component.patch Patch for Choose component > Choose Component > > > Key: TAP5-2140 > URL: https://issues.apache.org/jira/browse/TAP5-2140 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Barry Books >Priority: Minor > Labels: features > Attachments: 0001-Choose-Component.patch > > > Add support for Choose component that allows > choose > when test > when test > otherwise > flow control -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2140) Choose Component
Barry Books created TAP5-2140: - Summary: Choose Component Key: TAP5-2140 URL: https://issues.apache.org/jira/browse/TAP5-2140 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor Add support for Choose component that allows choose when test when test otherwise flow control -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2104) Dynamic template parser does not support t:container
[ https://issues.apache.org/jira/browse/TAP5-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2104: -- Description: Templates must be valid XML so they must have 1 root element. Sometime it's not desirable for that root element to be rendered in the final page so t:container can be used as the root element. This works for pages and components but not Dynamic component templates. When used in a Dynamic template t:container is rendered as a component element. (was: Template must be valid XML so they must have 1 root element. Sometime it's not desirable for that root element to be rendered in the final page so t:container can be used as the root element. This works for pages and components but not Dynamic component templates. When used in a Dynamic template t:container is rendered as a component element.) > Dynamic template parser does not support t:container > > > Key: TAP5-2104 > URL: https://issues.apache.org/jira/browse/TAP5-2104 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3.4 >Reporter: Barry Books >Priority: Minor > > Templates must be valid XML so they must have 1 root element. Sometime it's > not desirable for that root element to be rendered in the final page so > t:container can be used as the root element. This works for pages and > components but not Dynamic component templates. When used in a Dynamic > template t:container is rendered as a component element. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2104) Dynamic template parser does not support t:container
[ https://issues.apache.org/jira/browse/TAP5-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2104: -- Issue Type: Improvement (was: Bug) > Dynamic template parser does not support t:container > > > Key: TAP5-2104 > URL: https://issues.apache.org/jira/browse/TAP5-2104 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3.4 >Reporter: Barry Books >Priority: Minor > > Template must be valid XML so they must have 1 root element. Sometime it's > not desirable for that root element to be rendered in the final page so > t:container can be used as the root element. This works for pages and > components but not Dynamic component templates. When used in a Dynamic > template t:container is rendered as a component element. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2104) Dynamic template parser does not support t:container
[ https://issues.apache.org/jira/browse/TAP5-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629127#comment-13629127 ] Barry Books commented on TAP5-2104: --- That does not really work for me in this case but I guess that means this is a feature request not a bug.I'll see if I can fix it with a mixin that deletes the outer element. > Dynamic template parser does not support t:container > > > Key: TAP5-2104 > URL: https://issues.apache.org/jira/browse/TAP5-2104 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.4 >Reporter: Barry Books >Priority: Minor > > Template must be valid XML so they must have 1 root element. Sometime it's > not desirable for that root element to be rendered in the final page so > t:container can be used as the root element. This works for pages and > components but not Dynamic component templates. When used in a Dynamic > template t:container is rendered as a component element. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2104) Dynamic template parser does not support t:container
Barry Books created TAP5-2104: - Summary: Dynamic template parser does not support t:container Key: TAP5-2104 URL: https://issues.apache.org/jira/browse/TAP5-2104 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.4 Reporter: Barry Books Priority: Minor Template must be valid XML so they must have 1 root element. Sometime it's not desirable for that root element to be rendered in the final page so t:container can be used as the root element. This works for pages and components but not Dynamic component templates. When used in a Dynamic template t:container is rendered as a component element. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2099) Update parameters bound to literal: or symbol: from a mixin
[ https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614313#comment-13614313 ] Barry Books commented on TAP5-2099: --- While I'm all for fixing the read only parameter problem this change looks like it allows the value of a literal binding to be updated. I'm not sure I like the idea of a get to literal:1 returning anything other than a 1. > Update parameters bound to literal: or symbol: from a mixin > --- > > Key: TAP5-2099 > URL: https://issues.apache.org/jira/browse/TAP5-2099 > Project: Tapestry 5 > Issue Type: Improvement >Affects Versions: 5.3.6 >Reporter: Lance > Labels: binding, literal-binding, mixin, symbol-binding > Attachments: TAP52099-1.patch > > > Currently, I cannot update a component component parameter that is > initialized with a literal: or symbol: binding from a mixin. If I try to > @BindParameter the param and change it's value, I get a "Binding %s is > read-only" exception (originating from AbstractBinding). > I propose that literal and symbol bindings are sourced from a PerThreadValue > that can be updated by a mixin. > My original need for this was to create a "SinglePage" mixin for the Grid > component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I > can't currently do this because by default, the parameter is a symbol: > binding. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1618) Component events "onValidate / onSuccess / onFailure"
[ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611682#comment-13611682 ] Barry Books commented on TAP5-1618: --- This would be a useful addition. The code needed to be a form field seems complicated and very unTapestry like. Just having events instead of ComponentActions would fix that. > Component events "onValidate / onSuccess / onFailure" > - > > Key: TAP5-1618 > URL: https://issues.apache.org/jira/browse/TAP5-1618 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.3, 5.4 >Reporter: Jens Breitenstein >Priority: Minor > Labels: components, events > > Currently a compont is more or less something which just groups UI elements. > Tapestry should give components a chance to take full responsibility for all > UI elements it contains including setup, validation and storage. On the one > hand we can pre-set values (like setting checkbox aso) via setupRender by > reading a domain model but there is no way to store the values because a > component is not getting events from the form. There are several methods like > custom bindings, ComponentAction or calling component methods from the form > (page class) to come around this issue, but this just looks like workarounds. > In case components would provide optional methods for onValidate / onSuccess > / onFailure (and become part of the form's events) it's possible to write > standalone components which read a domain model and reflect changes to a > domain model and even do cross checks between fields. This would increase > component reusability to my personal opinion and create more solid units. > Furthermore it easily allows handling of data which is not stored as simple > attributes (eg bitfield which is mapped to multiple checkboxes and needs > conversion in setupRender / onSuccess). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2006) File Upload module does not support the multiple attribute
[ https://issues.apache.org/jira/browse/TAP5-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2006: -- Attachment: 0003-TAP-2005.patch 0002-TAP-2006.patch Test case and service > File Upload module does not support the multiple attribute > -- > > Key: TAP5-2006 > URL: https://issues.apache.org/jira/browse/TAP5-2006 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-upload >Affects Versions: 5.4 >Reporter: Barry Books >Priority: Minor > Labels: features, patch > Attachments: 0001-for-TAP-2006.patch, 0002-TAP-2006.patch, > 0003-TAP-2005.patch > > > The file upload component does not support the new HTML5 multiple attribute. > In order to maintain backward compatibility a new component called > UploadMultiple will be created. The new component will support single and > multiple file uploads. > This also requires a modification to the MultipartDecoder service. > Patch will follow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2006) File Upload module does not support the multiple attribute
[ https://issues.apache.org/jira/browse/TAP5-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Books updated TAP5-2006: -- Attachment: 0001-for-TAP-2006.patch Patch to allow multiple attribute on file uploads > File Upload module does not support the multiple attribute > -- > > Key: TAP5-2006 > URL: https://issues.apache.org/jira/browse/TAP5-2006 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-upload >Affects Versions: 5.4 >Reporter: Barry Books >Priority: Minor > Labels: features, patch > Attachments: 0001-for-TAP-2006.patch > > > The file upload component does not support the new HTML5 multiple attribute. > In order to maintain backward compatibility a new component called > UploadMultiple will be created. The new component will support single and > multiple file uploads. > This also requires a modification to the MultipartDecoder service. > Patch will follow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2006) File Upload module does not support the multiple attribute
Barry Books created TAP5-2006: - Summary: File Upload module does not support the multiple attribute Key: TAP5-2006 URL: https://issues.apache.org/jira/browse/TAP5-2006 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-upload Affects Versions: 5.4 Reporter: Barry Books Priority: Minor The file upload component does not support the new HTML5 multiple attribute. In order to maintain backward compatibility a new component called UploadMultiple will be created. The new component will support single and multiple file uploads. This also requires a modification to the MultipartDecoder service. Patch will follow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1998) DateField does not validate dates properly
Barry Books created TAP5-1998: - Summary: DateField does not validate dates properly Key: TAP5-1998 URL: https://issues.apache.org/jira/browse/TAP5-1998 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books Priority: Minor Due to the way the Java DateFormat class works there are 2 cases that allow invalid dates threw the DateField component. 1. By default date parsing is lenient. This means dates such as 00/01/2000 are converted to 12/01/1999 and passed thru. There is no way for the application to know this has happened. 2. The DateFormat class ignores trailing characters. This means an input of 01/01/200- will result in a date of 01/01/200 again there is no way for the application to know this has happened. It's possible to work around both these issues but I think the workarounds are not obvious and in practice difficult to implement. To work around the first problem you can pass a DateFormat with lenient set to false. The service that converts Strings to DateFormat does not do this and it does not seem possible to override it so all the DateFormats much be created in Java code. The second issue can be resolved by providing a regexp expression to validate the date. For some date formats such as MM/dd/ this is pretty easy but other date formats are complex and it's difficult to come up with a correct regular expression. So I would like to propose changing DateField to set lenient to false and use parse(source,pos) instead of paste(source). This change is not strictly backward compatible and a parameter could be added that allows the old behavior. My guess is there are not many people depending on the existing behavior since it really allows invalid dates to be silently input. I have a patch that I can contribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
