Does this help at all?

        
http://jumpstart.doublenegative.com.au/jumpstart/examples/select/varied/$N/$N/$N/$N

Cheers,

Geoff

On 14/05/2010, at 12:11 AM, Benny Law wrote:

> We are talking about subclassing a Tapestry component here. To give you an
> example, I wanted to subclass the Select component to override how
> BlankOption.AUTO is interpreted. I wanted the logic to not just look at the
> required property but also to consider how many options are available and
> whether there is a current value. (I find the current logic lacking because,
> for example, the first option will always be selected as default if required
> is true, but there may not be a meaningful default for the field.) All I
> needed to do was to override the showBlankOption() method, but I couldn't
> because it's a private method. I ended up making a duplicate of the Select
> component with a modified showBlankOption() method. It just didn't feel
> right. I don't think all this talk about capturing common logic in a base
> class or creating a service for it applies here.
> 
> In my opinion, a good framework should provide the option for extending its
> components easily. I believe that with proper design and careful
> consideration, inheritance can still be very useful. Developers should
> understand any potential risks involved in subclassing, but closing the door
> to subclassing for the sake of backward-compatibility may be an overkill
> IMHO. Everything has pros and cons, and the developer is ultimately
> responsible for weighing them and choosing what's best for their situation.
> 
> BTW, if anyone can think of a clean way to solve my problem with the Select
> component, please let me know. Thanks.
> 
> Benny
> 
> 
> On Thu, May 13, 2010 at 8:58 AM, Christian Riedel
> <cr.ml...@googlemail.com>wrote:
> 
>> Why should you have the same rendering code in two different components?
>> When I have common code for several components I create an abstract base
>> component and put it into the base package. The template is not mandatory
>> for components or abstract base components/pages btw. You can use
>> subclassing whenever you want but that doesn't always makes your code
>> better.
>> 
>> If you have common logic in different components you should move it into a
>> service...
>> 
>> Well, and I think tapestry can't free you from your dirtyness, you should
>> try soap :)
>> 
>> 
>> Am 13.05.2010 um 14:28 schrieb Benny Law:
>> 
>>> I also wish component subclassing was at least an option. What I don't
>> like
>>> about copying and pasting from a Tapestry component is that I end up
>> relying
>>> on some internal packages and classes. That makes me feel dirty.
>>> 
>>> Benny
>>> 
>>> 
>>> On Thu, May 13, 2010 at 7:47 AM, Andreas Bohnert <a...@weberhofer.at>
>> wrote:
>>> 
>>>> I agree.
>>>> I'm upgrading a big project from tapestry 3 to 5.
>>>> As I looked into the documentation and sources of tapestry 5 I thought:
>>>> wow, this is really great. it could not be any better!
>>>> 
>>>> But if components are no meant to be subclassed this seems like a
>> drawback
>>>> for me. You have to copy and adjust the code which does not fit into the
>>>> tapestry world (DRY principle)
>>>> If you use embedded components to extend a component you need an
>> additional
>>>> (more or less useless) template file and you come in trouble if you use
>> this
>>>> component multiple times in a page (because of the embedded components
>> id
>>>> binding)
>>>> 
>>>> Anyway, even if there is way to get around these problems with embedded
>>>> components I described, it would feel more natural for me if I just
>> could
>>>> subclass a component.
>>>> 
>>>> Andreas
>>>> 
>>>> 
>>>> 
>>>> I ended up copying
>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to