Re: Palette and Checklist don't use contributed value encoder?
I'm with you on this and I agree that this might be confusing for newcomers. But how would you solve this? I'm against removing the required flag and only have the user notice when he runs into an exception. It should be clear from the documentation that the parameter is indeed required but a default will be used if found and the parameter is not set. As Howard said, in those cases it is documented in the paramter description. An improvement could be an additional flag, maybe 'defaultprovided', to indicate that a default will be provided if not bound which the user can see directly without going through the description. Uli On 23.08.2011 04:08, Bob Harner wrote: I know what everybody says it means. I'm just saying that it *shouldn't* mean that, because it violates the principle of least surprise. I'll stop now. I know I'm in the minority on this. On Mon, Aug 22, 2011 at 9:59 PM, Howard Lewis Ship hls...@gmail.com wrote: Required means that the value is required for the operation of the component. It does not mean that it must be explicitly bound when the component can provide a default. The parameter description will describe when a default can be provided automatically. On Sun, Aug 21, 2011 at 5:20 AM, Bob Harner bobhar...@gmail.com wrote: Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so completely disregard the common sense meaning of a commonly understood word. So required sometimes means optional if certain conditions are met elsewhere. And users are just supposed to figure that out on their own??? Bob Harner On Aug 21, 2011 7:03 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: The semantics are the parameter is required. If no value is bound, the component will TRY to find a default. The lookup for a default value might be successful or not. For example, imagine you pass a list of Users to AjaxFormLoop and don't bind a ValueEncoder. If no ValueEncoder for User is contributed, no default can be found and the component will complain about missing binding. That makes sense as the parameter is required. If you are using Hibernate or JPA integration, there is a ValueEncoder contributed automatically for every entity. In such a case, the default can be found even though you didn't contribute any ValueEncoder manually. In summary: depending on the configuration of your app, a default ValueEncoder can be found or not. That's why marking the encoder parameter as required makes absolutely sense. On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner bobhar...@gmail.com wrote: my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. -- Best regards, Igor Drobiazko http://tapestry5.de -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
On Sun, Aug 21, 2011 at 2:20 PM, Bob Harner bobhar...@gmail.com wrote: Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so completely disregard the common sense meaning of a commonly understood word. So required sometimes means optional if certain conditions are met elsewhere. And users are just supposed to figure that out on their own??? If you're stunned please stop banging your head against the wall. BTW I find completely usual having a piece of software requiring something and having another piece of software providing it. It seems obvious that the latter could be user's code or another module of the same software or a third party module too. It's certain that you know better than me the English language but from my perspective there's not contradiction here. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
On Mon, 22 Aug 2011 07:36:08 -0300, Massimo Lusetti mluse...@gmail.com wrote: BTW I find completely usual having a piece of software requiring something and having another piece of software providing it. It seems obvious that the latter could be user's code or another module of the same software or a third party module too. I don't think this is unusual. It means the component parameter requires a value, regardless where it comes from. This is not the same as saying the user is required to provide a value. The requirement here is from the component parameter view, not the user (developer) one. (Breaking the threading because I mistakenly sent the message just to Massimo instead of to the list and I already deleted the message, so I cannot reply to it directly). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
I agree with Bob on this point. IMHO a parameter is 'required' if you must provide a value. In case tapestry will provide a default value, we can keep it optional with a comment, Default value will only be used if found/contributed ... But as far as correct English and developers are concerned, we take all sorts of liberties and expect that from frameworks too. Like Howard said in one of his mails what the hell is an Environmental anyway? On Mon, Aug 22, 2011 at 6:17 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Mon, 22 Aug 2011 07:36:08 -0300, Massimo Lusetti mluse...@gmail.com wrote: BTW I find completely usual having a piece of software requiring something and having another piece of software providing it. It seems obvious that the latter could be user's code or another module of the same software or a third party module too. I don't think this is unusual. It means the component parameter requires a value, regardless where it comes from. This is not the same as saying the user is required to provide a value. The requirement here is from the component parameter view, not the user (developer) one. (Breaking the threading because I mistakenly sent the message just to Massimo instead of to the list and I already deleted the message, so I cannot reply to it directly). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Regards Taha Hafeez Siddiqi (tawus) http://tawus.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
We all agree that it is common for one piece of software to require something that another piece of software can provide. This is the whole idea of the concept of defaults. The user can provide something directly, or he/she can let the software figure out the best default value to apply. In those cases, we use the word optional, not the word required. That much is a universal convention, clear and unambiguous to all. In the case of value encoders, if the component needs one and the user doesn't supply one directly via the value parameter, then the component is expected to figure out the best default to apply. Whether the best default is one of Tapestry's coercions or a default value encoder the user has established in some other part of the program is immaterial to the argument. The documentation says that the parameter is required, and yet, it is really only the underlying value encoder that is required, not the parameter. I understand the thinking behind the current usage of the word required in this case. I really do. It was a carefully-made compromise to make a binary value fit what is really a ternary choice. But the usage just doesn't fit with well-established conventions, and it's an obstacle to users in trying to understand how to use the framework. Theoretically, to fix this, I guess we would just need to remove the required clause from those several components that use value encoders, and then improve the exception message that displays when Tapestry can't find a value encoder to use. Anything else? On Mon, Aug 22, 2011 at 8:47 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Mon, 22 Aug 2011 07:36:08 -0300, Massimo Lusetti mluse...@gmail.com wrote: BTW I find completely usual having a piece of software requiring something and having another piece of software providing it. It seems obvious that the latter could be user's code or another module of the same software or a third party module too. I don't think this is unusual. It means the component parameter requires a value, regardless where it comes from. This is not the same as saying the user is required to provide a value. The requirement here is from the component parameter view, not the user (developer) one. (Breaking the threading because I mistakenly sent the message just to Massimo instead of to the list and I already deleted the message, so I cannot reply to it directly). -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
Required means that the value is required for the operation of the component. It does not mean that it must be explicitly bound when the component can provide a default. The parameter description will describe when a default can be provided automatically. On Sun, Aug 21, 2011 at 5:20 AM, Bob Harner bobhar...@gmail.com wrote: Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so completely disregard the common sense meaning of a commonly understood word. So required sometimes means optional if certain conditions are met elsewhere. And users are just supposed to figure that out on their own??? Bob Harner On Aug 21, 2011 7:03 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: The semantics are the parameter is required. If no value is bound, the component will TRY to find a default. The lookup for a default value might be successful or not. For example, imagine you pass a list of Users to AjaxFormLoop and don't bind a ValueEncoder. If no ValueEncoder for User is contributed, no default can be found and the component will complain about missing binding. That makes sense as the parameter is required. If you are using Hibernate or JPA integration, there is a ValueEncoder contributed automatically for every entity. In such a case, the default can be found even though you didn't contribute any ValueEncoder manually. In summary: depending on the configuration of your app, a default ValueEncoder can be found or not. That's why marking the encoder parameter as required makes absolutely sense. On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner bobhar...@gmail.com wrote: my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. -- Best regards, Igor Drobiazko http://tapestry5.de -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
I know what everybody says it means. I'm just saying that it *shouldn't* mean that, because it violates the principle of least surprise. I'll stop now. I know I'm in the minority on this. On Mon, Aug 22, 2011 at 9:59 PM, Howard Lewis Ship hls...@gmail.com wrote: Required means that the value is required for the operation of the component. It does not mean that it must be explicitly bound when the component can provide a default. The parameter description will describe when a default can be provided automatically. On Sun, Aug 21, 2011 at 5:20 AM, Bob Harner bobhar...@gmail.com wrote: Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so completely disregard the common sense meaning of a commonly understood word. So required sometimes means optional if certain conditions are met elsewhere. And users are just supposed to figure that out on their own??? Bob Harner On Aug 21, 2011 7:03 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: The semantics are the parameter is required. If no value is bound, the component will TRY to find a default. The lookup for a default value might be successful or not. For example, imagine you pass a list of Users to AjaxFormLoop and don't bind a ValueEncoder. If no ValueEncoder for User is contributed, no default can be found and the component will complain about missing binding. That makes sense as the parameter is required. If you are using Hibernate or JPA integration, there is a ValueEncoder contributed automatically for every entity. In such a case, the default can be found even though you didn't contribute any ValueEncoder manually. In summary: depending on the configuration of your app, a default ValueEncoder can be found or not. That's why marking the encoder parameter as required makes absolutely sense. On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner bobhar...@gmail.com wrote: my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. -- Best regards, Igor Drobiazko http://tapestry5.de -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
The semantics are the parameter is required. If no value is bound, the component will TRY to find a default. The lookup for a default value might be successful or not. For example, imagine you pass a list of Users to AjaxFormLoop and don't bind a ValueEncoder. If no ValueEncoder for User is contributed, no default can be found and the component will complain about missing binding. That makes sense as the parameter is required. If you are using Hibernate or JPA integration, there is a ValueEncoder contributed automatically for every entity. In such a case, the default can be found even though you didn't contribute any ValueEncoder manually. In summary: depending on the configuration of your app, a default ValueEncoder can be found or not. That's why marking the encoder parameter as required makes absolutely sense. On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner bobhar...@gmail.com wrote: my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Palette and Checklist don't use contributed value encoder?
Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so completely disregard the common sense meaning of a commonly understood word. So required sometimes means optional if certain conditions are met elsewhere. And users are just supposed to figure that out on their own??? Bob Harner On Aug 21, 2011 7:03 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: The semantics are the parameter is required. If no value is bound, the component will TRY to find a default. The lookup for a default value might be successful or not. For example, imagine you pass a list of Users to AjaxFormLoop and don't bind a ValueEncoder. If no ValueEncoder for User is contributed, no default can be found and the component will complain about missing binding. That makes sense as the parameter is required. If you are using Hibernate or JPA integration, there is a ValueEncoder contributed automatically for every entity. In such a case, the default can be found even though you didn't contribute any ValueEncoder manually. In summary: depending on the configuration of your app, a default ValueEncoder can be found or not. That's why marking the encoder parameter as required makes absolutely sense. On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner bobhar...@gmail.com wrote: my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Palette and Checklist don't use contributed value encoder?
Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model parameter were principal. But what if you have different types of objects in the list? On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner bobhar...@gmail.com wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter to be optional: Grid, GridRows, Loop, Select, Upload: But the following make you provide the encoder parameter (even if you have a ValueEncoder configured in your AppModule for the appropriate type): AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup Maybe there's some subtle reason for this? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Palette and Checklist don't use contributed value encoder?
A list with mixed types seem like an edge case well worth ignoring, right? Bob Harner On Aug 20, 2011 7:54 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model parameter were principal. But what if you have different types of objects in the list? On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner bobhar...@gmail.com wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter to be optional: Grid, GridRows, Loop, Select, Upload: But the following make you provide the encoder parameter (even if you have a ValueEncoder configured in your AppModule for the appropriate type): AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup Maybe there's some subtle reason for this? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Palette and Checklist don't use contributed value encoder?
Um... last time I checked, Grid, GridRows, and Loop all operate on lists of objects, so if this is the argument, then the philosophy is inconsistently applied. In fact, Grid makes it's determination based on the row parameter. And AjaxFormLoop /does/ provide a default value encoder (iff you've also bound the value parameter... which is usually). The components take advantage of the fact that if the user has bound the value, whatever type is bound must be universally applicable to all items in the list. Again, AjaxFormLoop already does this. There's no reason Palette couldn't do something like that as well.. supply the defaultEncoder based on the bound type of the value. I haven't looked over Checklist, but I suspect a similar case can be made there. Robert On Aug 20, 2011, at 8/206:54 AM , Igor Drobiazko wrote: Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model parameter were principal. But what if you have different types of objects in the list? On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner bobhar...@gmail.com wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter to be optional: Grid, GridRows, Loop, Select, Upload: But the following make you provide the encoder parameter (even if you have a ValueEncoder configured in your AppModule for the appropriate type): AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup Maybe there's some subtle reason for this? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
Apart from the question of why Palette and Checklist don't yet support a default encoder, my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. On Sat, Aug 20, 2011 at 6:52 PM, Robert Zeigler robert.zeig...@roxanemy.com wrote: Um... last time I checked, Grid, GridRows, and Loop all operate on lists of objects, so if this is the argument, then the philosophy is inconsistently applied. In fact, Grid makes it's determination based on the row parameter. And AjaxFormLoop /does/ provide a default value encoder (iff you've also bound the value parameter... which is usually). The components take advantage of the fact that if the user has bound the value, whatever type is bound must be universally applicable to all items in the list. Again, AjaxFormLoop already does this. There's no reason Palette couldn't do something like that as well.. supply the defaultEncoder based on the bound type of the value. I haven't looked over Checklist, but I suspect a similar case can be made there. Robert On Aug 20, 2011, at 8/206:54 AM , Igor Drobiazko wrote: Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model parameter were principal. But what if you have different types of objects in the list? On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner bobhar...@gmail.com wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter to be optional: Grid, GridRows, Loop, Select, Upload: But the following make you provide the encoder parameter (even if you have a ValueEncoder configured in your AppModule for the appropriate type): AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup Maybe there's some subtle reason for this? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
I remember having the same question when documenting some T4 components way back! Many had required parameters, but if you didn't supply one, Tapestry would supply a default value - so, to the user they really looked as non required parameters. In any case, it was then decided to mark them an required in the docs - sometimes the code that supplied a good default value was added in later versions... perhaps that could be better addressed - what would you suggest? On Sun, Aug 21, 2011 at 04:50, Bob Harner bobhar...@gmail.com wrote: Apart from the question of why Palette and Checklist don't yet support a default encoder, my other question would be why the encoder parameter is marked as required for AjaxFormLoop, Hidden and RadioGroup. After all, as Robert Z. says, those components seem to have the ability to supply the default encoder based on the bound type of value. My brain is a little sleep-deprived, so maybe I'm just not understanding how this really makes sense. On Sat, Aug 20, 2011 at 6:52 PM, Robert Zeigler robert.zeig...@roxanemy.com wrote: Um... last time I checked, Grid, GridRows, and Loop all operate on lists of objects, so if this is the argument, then the philosophy is inconsistently applied. In fact, Grid makes it's determination based on the row parameter. And AjaxFormLoop /does/ provide a default value encoder (iff you've also bound the value parameter... which is usually). The components take advantage of the fact that if the user has bound the value, whatever type is bound must be universally applicable to all items in the list. Again, AjaxFormLoop already does this. There's no reason Palette couldn't do something like that as well.. supply the defaultEncoder based on the bound type of the value. I haven't looked over Checklist, but I suspect a similar case can be made there. Robert On Aug 20, 2011, at 8/206:54 AM , Igor Drobiazko wrote: Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model parameter were principal. But what if you have different types of objects in the list? On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner bobhar...@gmail.com wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter to be optional: Grid, GridRows, Loop, Select, Upload: But the following make you provide the encoder parameter (even if you have a ValueEncoder configured in your AppModule for the appropriate type): AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup Maybe there's some subtle reason for this? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Palette and Checklist don't use contributed value encoder?
On Aug 19, 2011, at 8/198:56 PM , Bob Harner wrote:
Does anyone know why half of the built-in Tapestry 5 components that
take an encoder parameter are NOT set up to be able to use a
contributed ValueEncoder (that is, one configured with
contributeValueEncoderSource() in AppModule class)?
The following components nicely allow the encoder parameter to be optional:
Grid, GridRows, Loop, Select, Upload:
But the following make you provide the encoder parameter (even if you
have a ValueEncoder configured in your AppModule for the appropriate
type):
AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup
Not entirely following... at least in trunk:
From AjaxFormLoop:
ValueEncoder defaultEncoder()
{
return defaultProvider.defaultValueEncoder(value, resources);
}
Hidden:
ValueEncoder defaultEncoder()
{
return defaultProvider.defaultValueEncoder(value, resources);
}
RadioGroup:
final ValueEncoder defaultEncoder()
{
return defaultProvider.defaultValueEncoder(value, resources);
}
And, for the record, Grid (to demonstrate the fact that Grid is default the
same way):
ValueEncoder defaultEncoder()
{
return defaultsProvider.defaultValueEncoder(row, resources);
}
But it does appear that Palette and Checklist are not proving a default
encoder, and the why behind that I don't know.
Robert
Maybe there's some subtle reason for this?
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
