You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Richard Clark <rd...@nextquestion.net> on 2005/11/02 18:57:32 UTC
Pat vs. the toolbar (was Re: "Why I Like Annotations")
Maybe I'm missing something, but you can define a parameter as
optional and give it a default value. Why not declare "listener" as
optional and default it to the listener in your root page class?
I realize this doesn't make your toolbar class 100% reusable across
all projects, unless you document it as "calls listener
listenToTheMusic(allTheTime...), unless overridden by a listener=...
parameter".
...Richard
On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>
> My latest "I want" is a bit different from my earlier "I wants":
>
> I want to reduce the number of little pieces parts I have to change
> to alter the product. Lets say, for example, I want to add a new
> toolbar
> button to one of my forms:
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Pat vs. the toolbar (was Re: "Why I Like Annotations")
Posted by Richard Clark <rd...@nextquestion.net>.
Perfect encapsulation says "my internal mechanisms are hidden and all
external dependancies are made explicit." So, any perfectly
encapsulated code will need all of its dependencies specified
everywhere it's used. There's not really a way to say "I'm using it
in 20 places but only want to document the dependency in one place"
without breaking that encapsulation at some level. (Even an #include
file would break encapsulation.)
The trend of late has been away from encapsulation and more toward
defaults and "convention" -- cf. Ruby on Rails, the way Tapestry
assumes that abstract accessors on a page represent transient
properties (to be initialized to null on load) unless otherwise
specified, etc. It works, when well documented.
Personally, I prefer high encapsulation and clearly specifying
dependancies to low encapsulation and implicit dependencies. (I was
asking how to do this with a vallidator the other day (hoping to
inject something it needs), and it turns out I couldn't.) But, as
pages proliferate with the same boilerplate specifications, I'm
finding it best to collapse the common case into one place and only
specify the exceptions.
I find that encapsulation is like a good raincoat -- it keeps you
warm and safe in shifting weather. Apply it too stringently and it
becomes a straitjacket. If it leads to an excess of duplicate code,
you'll have a serious maintenance nightmare.
As the Pragmatic Programmers say, "Don't Repeat Yourself". as test
driven developers say "when you're doing something 3 times in
different places, it's time to refactor (to one)."
...Richard
On Nov 2, 2005, at 11:14, Patrick Casey wrote:
>
> I could, but I always get the heebie-geebies when I drive stakes
> through component encapsulation like that, it kind of feels like I'm
> defeating the purpose of using a component based framework at all.
>
>> -----Original Message-----
>> From: Richard Clark [mailto:rdclark@nextquestion.net]
>> Sent: Wednesday, November 02, 2005 9:58 AM
>> To: Tapestry users
>> Subject: Pat vs. the toolbar (was Re: "Why I Like Annotations")
>>
>> Maybe I'm missing something, but you can define a parameter as
>> optional and give it a default value. Why not declare "listener" as
>> optional and default it to the listener in your root page class?
>>
>> I realize this doesn't make your toolbar class 100% reusable across
>> all projects, unless you document it as "calls listener
>> listenToTheMusic(allTheTime...), unless overridden by a listener=...
>> parameter".
>>
>> ...Richard
>>
>>
>> On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>>
>>>
>>> My latest "I want" is a bit different from my earlier "I wants":
>>>
>>> I want to reduce the number of little pieces parts I have to change
>>> to alter the product. Lets say, for example, I want to add a new
>>> toolbar
>>> button to one of my forms:
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-
>> help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Pat vs. the toolbar (was Re: "Why I Like Annotations")
Posted by Patrick Casey <pa...@adelphia.net>.
I could, but I always get the heebie-geebies when I drive stakes
through component encapsulation like that, it kind of feels like I'm
defeating the purpose of using a component based framework at all.
> -----Original Message-----
> From: Richard Clark [mailto:rdclark@nextquestion.net]
> Sent: Wednesday, November 02, 2005 9:58 AM
> To: Tapestry users
> Subject: Pat vs. the toolbar (was Re: "Why I Like Annotations")
>
> Maybe I'm missing something, but you can define a parameter as
> optional and give it a default value. Why not declare "listener" as
> optional and default it to the listener in your root page class?
>
> I realize this doesn't make your toolbar class 100% reusable across
> all projects, unless you document it as "calls listener
> listenToTheMusic(allTheTime...), unless overridden by a listener=...
> parameter".
>
> ...Richard
>
>
> On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>
> >
> > My latest "I want" is a bit different from my earlier "I wants":
> >
> > I want to reduce the number of little pieces parts I have to change
> > to alter the product. Lets say, for example, I want to add a new
> > toolbar
> > button to one of my forms:
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org