>
>> -Original Message-
>> From: Howard Lewis Ship [mailto:hls...@gmail.com]
>> Sent: Thursday, November 20, 2008 12:16
>> To: Tapestry users
>> Subject: Re: Tapestry-IoC: binding service without code, just convention
>> over configuration
>>
>&
7;t know how you manage to actually close them!
Jonathan
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2008 12:16
> To: Tapestry users
> Subject: Re: Tapestry-IoC: binding service without code, just convention
> o
>
> That's one of the reasons I wrote the Ars Machina Generic DAO, Generic
> DAO-Hibernate and Generic Controller: all the common methods (findAll,
> findById, save, update, delete, findByExample, etc) are already written. I
> don't have to rewrite them for every entity class.
My generic dao is p
Em Thu, 20 Nov 2008 15:28:02 -0300, Thiago H. de Paula Figueiredo
<[EMAIL PROTECTED]> escreveu:
As far as I know, I cannot put the @CommitAfter method in one IoC
service and have its calls wrapped in a transaction, just components and
pages methods. If I'm wrong, I'll use Tapestry-Hibernate.
Em Thu, 20 Nov 2008 14:14:59 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
I think Tapestry makes it easier to separate your business logic out
as IoC services or even Spring beans. It's easier to inject a service
or bean in Tapestry than in any framework I'm aware of.
I completely
Em Thu, 20 Nov 2008 14:16:33 -0300, Jonathan Barker
<[EMAIL PROTECTED]> escreveu:
Ah, I had to jump in.
Everybody is invited!
I like using business services that keep data access code out of my
pages. That part feels good.
So do I! :)
Unfortunately, that often means that a findAll() i
w! In the meantime,
> I'll settle for keeping Session out of my pages.
>
> Jonathan
>
>
>> -Original Message-----
>> From: Chris Lewis [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, November 20, 2008 11:42
>> To: Tapestry users
>> Subject: Re: Tapest
I think Tapestry makes it easier to separate your business logic out
as IoC services or even Spring beans. It's easier to inject a service
or bean in Tapestry than in any framework I'm aware of. My of the
examples, demos or prototypes do intentionally blur the layers a bit,
but you are anything b
settle for keeping Session out of my pages.
Jonathan
> -Original Message-
> From: Chris Lewis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2008 11:42
> To: Tapestry users
> Subject: Re: Tapestry-IoC: binding service without code, just convention
> over config
One more example . . .
Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo
<[EMAIL PROTECTED]> escreveu:
This is a common confusion: there is the controller in the MVC pattern
and the controller in the 3-tier architecture, and both are different
things. A controller in MVC,
Em Thu, 20 Nov 2008 13:41:46 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
Thanks for the input Thiago.
All discussions are good discussions. :)
I'm curious about your reasoning for
avoiding tapestry-hibernate. I use it for it's value encoder and primary
key encoder auto wiring, and tha
Thanks for the input Thiago. I'm curious about your reasoning for
avoiding tapestry-hibernate. I use it for it's value encoder and primary
key encoder auto wiring, and that's pretty much it. I avoid injecting
Session into pages, and I assume that's the practice you specifically
are avoiding in the
> I'm thinking of not even have that binder.bind() call, automatically
binding services located in packages defined by some convention.
Very interesting idea. This mechanism could be something similar to Spring's
classpath scanning for managed components:
http://static.springframework.org/spring/
Em Wed, 19 Nov 2008 17:37:48 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
Hi Thiago,
Hi, Chris!
Out of architectural curiosity, what do you use a UserController for in
your example?
I'm a strong supporter of n-tier architectures, so the view layer (in this
case, Tapestry) does no b
Hi Thiago,
Out of architectural curiosity, what do you use a UserController for in
your example?
Thiago H. de Paula Figueiredo wrote:
> Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship
> <[EMAIL PROTECTED]> escreveu:
>
>> Interesting idea. You could probably put something together around
>>
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
publi
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
publi
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder("my.package.root").bin
Hi!
I have been wondering about some ways to write even less configuration
with Tapestry-IoC and yet more convention over configuration.
At first we had:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class, ServiceImplementation.class);
}
Then, if ServiceImplem
19 matches
Mail list logo
