[jira] [Commented] (TAP5-2255) Form and BeanEditForm differ in JSR-303 detection

2016-03-10 Thread Jochen Kemnade (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188905#comment-15188905
 ] 

Jochen Kemnade commented on TAP5-2255:
--

[~geoffcallender], is this still an issue? Can you give an example that doesn't 
require additional dependencies?

> Form and BeanEditForm differ in JSR-303 detection
> -
>
> Key: TAP5-2255
> URL: https://issues.apache.org/jira/browse/TAP5-2255
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-beanvalidator, tapestry-core
>Affects Versions: 5.4
>Reporter: Geoff Callender
>
> I have an entity field that the getter and setter convert between types 
> (field is Date, getter and setter convert from/to JodaTime's DateMidnight). 
> Form detects @NotNull on the field, but BeanEditForm doesn't. BeanEditForm 
> detects @NotNull on the getter, but Form doesn't. So I have to provide 
> @NotNull on the field AND the getter. Shouldn't Form and BeanEditForm behave 
> the same?
> For example, a snippet from an entity:
> {code}
> @Entity
> public class DatesExample implements Serializable {
>   // This JSR-303 validation will be picked up by Form.
>   @NotNull
>   private java.sql.Date aDateMidnight;
>   // This JSR-303 validation will be picked up by BeanEditForm.
>   @NotNull
>   public DateMidnight getADateMidnight() {
>   return JodaTimeUtil.toDateMidnight(aDateMidnight);
>   }
>   public void setADateMidnight(DateMidnight dm) {
>   this.aDateMidnight = JodaTimeUtil.toSQLDate(dm);
>   }
> }
> {code}
> I've contributed type coercers in AppModule:
> {code}
> public static void contributeTypeCoercer(Configuration 
> configuration) {
>// From java.util.Date to DateMidnight
> Coercion toDateMidnight = new 
> Coercion() {
> public DateMidnight coerce(java.util.Date input) {
> // TODO - confirm this conversion always works, esp. across 
> timezones
> return JodaTimeUtil.toDateMidnight(input);
> }
> };
> configuration.add(new CoercionTuple<>(java.util.Date.class, 
> DateMidnight.class, toDateMidnight));
> // From DateMidnight to java.util.Date
> Coercion fromDateMidnight = new 
> Coercion() {
> public java.util.Date coerce(DateMidnight input) {
> // TODO - confirm this conversion always works, esp. across 
> timezones
> return JodaTimeUtil.toJavaDate(input);
> }
> };
> configuration.add(new CoercionTuple<>(DateMidnight.class, 
> java.util.Date.class, fromDateMidnight));
> }
> {code}
> and I've contributed an editor:
> {code}
> public static void 
> contributeBeanBlockSource(Configuration configuration) 
> {
> configuration.add(new EditBlockContribution("dateMidnight", 
> "infra/AppPropertyEditBlocks", "dateMidnight"));
> }
> {code}
> Here is the editor:
> {code}
>  xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd";>
> 
> 
>  value="context.propertyValue" label="prop:context.label" 
> format="prop:dateInputFormat" 
> translate="prop:dateMidnightTranslator" validate="prop:dateMidnightValidator" 
> clientId="prop:context.propertyId" annotationProvider="context"/>
> 
> 
> {code}
> {code}
> public class AppPropertyEditBlocks {
> @Property
> @Environmental
> private PropertyEditContext context;
> @Component
> private DateField dateMidnight;
> @Component
> private DateField localDate;
> 
> public DateFormat getDateInputFormat() {
> return new SimpleDateFormat("dd  ");
> }
> 
> public FieldTranslator getDateMidnightTranslator() {
> return context.getTranslator(dateMidnight);
> }
> 
> public FieldValidator getDateMidnightValidator() {
> return context.getValidator(dateMidnight);
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TAP5-1803) URL encoding in ActivationRequestParameter is very strict

2016-03-10 Thread Jochen Kemnade (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1510#comment-1510
 ] 

Jochen Kemnade commented on TAP5-1803:
--

AFAICT, skipping the safe set check when decoding would not affect consistency. 
The encoding would still work in the same way that it does now and decoding of 
Tapestry-encoded strings would not be affected. However, it will allow us to 
use parameters that were not encoded by Tapestry.
I think that we should not change the safe set. That will probably lead to 
inconsistencies between versions. At least it will make newer Tapestry versions 
create URLs that older versions wouldn't be able to decode.

> URL encoding in ActivationRequestParameter is very strict
> -
>
> Key: TAP5-1803
> URL: https://issues.apache.org/jira/browse/TAP5-1803
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.1, 5.4
>Reporter: David Canteros
>  Labels: @ActivationRequestParameter, InvalidaArgumenteException, 
> URLEncoder,
>
> The URLEncoder that perform the URL encoding process does not include the 
> following "unreserved characters" :  
>  !  ~  *  ' (  )   
> (see rfc2396 Uniform Resource Identifiers (URI): Generic Syntax, item 2.3)
>
> Because the fix of TAP5-1768, from v5.3.1 the @ActivationRequestParameter 
> requires this enconding, which becomes incompatible with the standard.
> Thus, any URL which contains those symbols will throw an 
> InvalidaArgumenteException. Tapestry should consider that the 
> ActivationRequestParameter is a standar way of parameter sending, and the 
> parameters sent in this way probably not have the "strict" coding process of 
> the URLEncoder.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)