Creating components - best practices

[Jan Vissers <Ja...@cumquat.nl>]

Hi,

I've been migrating some of my T4 components to T5, but now - also
triggered by some useful feedback on this mailing list - are wondering
whether I've been using the right approach.

Let me start by saying that my components are fairly simple, the visible
part is all made up from .tml (no programmatic render processing going
on). I think it is best to share with you, one component that is built in
a way that is typical for the way I've been doing stuff up until now.

This is a customized 'feedback' component, which allows me to easily add
feedback information from any page to a flash persisted property, for one
time only display. For instance - after some action it would say: 'Import
has been accepted and started'.

Now the way I'm able to easily add feedback info is to have a basepage
class hold on to a collection of entries and have some utility
addFeedback(....) methods on that class. Each concrete page then can use
these methods to add their stuff. I'm starting to think that this isn't
the nicest approach, since pages that need this way of feedback
functionality now have to subclass a basepage class. Another thing I have
that some of my components need access to this basepage's properties - so
I inject that page into the component. My main questions are:

a) although this approach works - isn't it better to try and have each
component stand on itself?

b) if so - what would be the best way to have functionality like depicted
above (regarding feedback) in order for each page to easily allow adding
feedback information? Looks to me that the collection holding feedback
entries should be as close - preferably within - the same code as the
component itself.


Let me know what you think.
-J.


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

Re: Creating components - best practices

[Bill Holloway <bi...@gmail.com>]

I think I'd try to factor that out a little.  Injecting a page into a
component is a little surprising.  If you need injected behaviors in a
component, that sounds like the right place for a service.  For your
feedback data, if you persist it between requests, then I'd look at an
application state object instead.  That's a nice way to abstract data  away
from the page/component hierarchy without moving to database work or some
other persistence.

Bill

On Fri, Apr 25, 2008 at 7:47 PM, Jan Vissers <Ja...@cumquat.nl> wrote:

> Hi,
>
> I've been migrating some of my T4 components to T5, but now - also
> triggered by some useful feedback on this mailing list - are wondering
> whether I've been using the right approach.
>
> Let me start by saying that my components are fairly simple, the visible
> part is all made up from .tml (no programmatic render processing going
> on). I think it is best to share with you, one component that is built in
> a way that is typical for the way I've been doing stuff up until now.
>
> This is a customized 'feedback' component, which allows me to easily add
> feedback information from any page to a flash persisted property, for one
> time only display. For instance - after some action it would say: 'Import
> has been accepted and started'.
>
> Now the way I'm able to easily add feedback info is to have a basepage
> class hold on to a collection of entries and have some utility
> addFeedback(....) methods on that class. Each concrete page then can use
> these methods to add their stuff. I'm starting to think that this isn't
> the nicest approach, since pages that need this way of feedback
> functionality now have to subclass a basepage class. Another thing I have
> that some of my components need access to this basepage's properties - so
> I inject that page into the component. My main questions are:
>
> a) although this approach works - isn't it better to try and have each
> component stand on itself?
>
> b) if so - what would be the best way to have functionality like depicted
> above (regarding feedback) in order for each page to easily allow adding
> feedback information? Looks to me that the collection holding feedback
> entries should be as close - preferably within - the same code as the
> component itself.
>
>
> Let me know what you think.
> -J.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Those who can make you believe absurdities can make you commit atrocities.

Voltaire