Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Hi,

Our current architecture:
---

We're currently using a 3-tier architecture (presentation,
service/business and persistence) consisting of Wicket (+ a little
Spring), Spring and Spring + Hibernate:

Wicket:

Does presentation, we're not inside a transaction / Hibernate session
so all used fields must be loaded by Spring. We call Spring singleton
beans and annotate those fields with @SpringBean.

Spring:

In the service layer we have Spring singleton beans, services, which
are called from the Wicket layer. We have our transaction / Hibernate
session boundary at this layer. We call DAO's from this layer.

Spring + Hibernate:

Our DAO's are Spring singleton beans which performs database
operations using HibernateTemplate.

And common to all the layers are our entities. We use the @Entity
annotation on them (not XML), from the Wicket layer we just use the
accessor methods making sure that the relevant fields are loaded (as
we would get an exception if they were Lazy and not yet loaded). Our
entities are stupid, they lack logic and are used mostly like a struct
in C/C++.

I think the general pattern is pretty common for Java EE and Spring
based web applications (feel free to disagree!). Yet it's classified
as an anti-pattern by Martin Fowler as we are using mostly procedural
programming and have an anemic domain model (
http://en.wikipedia.org/wiki/Anemic_Domain_Model ).

What I would like:
---

I would like to use a more OOP approach and have logic in our current
entities, creating a rich domain model. For that to work in all cases
they need to be able to load and save data. I would still use a Spring
singleton bean's for different services. But instead of changing the
entities like structs they would be rich objects capable of chaning
themself's and other objects.

I found this article very interesting:
http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860

But how would something like that work with Wicket? Could I just use
@SpringBean like I'm currently doing but use it on both "entities" and
Spring singleton services?

For me this has a purely practical benefit, as I could use some
inheritance in the domain object model to create different variations
of logic and not just data. Wicket feels quite agile and nice to work
with, but I still feel that the current architecture is a bit stale
and seldom supports elegant OO solutions (that said, of course things
can still be solved elegantly, I just think it would be easier if I
could do it in a more OO oriented way).

Comments? What are the pros and cons of this kind of architecture?

All comments are greatly appreciated!

Best regards, Kent

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Oops! Yes I'm talking about DAO's, not DTO's as I wrote. I guess I
shouldn't write acronyms after a long work day. ;-) Thanks for
spotting it!

Best regards, Kent


On Thu, May 28, 2009 at 6:07 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> Are you talking about DAOs (data access objects) and not DTOs (data
> transfer objects)?  DTOs are typically not singletons.  Nor are they
> set up via spring.
>
> On Thu, May 28, 2009 at 11:20 AM, Kent Larsson <ke...@gmail.com> wrote:
>> Do you have a separation between domain objects and DTO's? It sounds
>> like you don't (and there is nothing wrong with that), but if you do,
>> how do you inject the DTO into the entity? In my case each DTO is a
>> Spring singleton bean.
>>
>> On Thu, May 28, 2009 at 4:17 PM, Will Jaynes <wi...@jaynes.org> wrote:
>>> I use the same setup as you, but I add the use of the
>>> OpenEntityManagerInViewFilter. I still use only Spring services from within
>>> Wicket (as much as possible), but the domain objects can be as full featured
>>> as needed because a Hibernate session is always open when Wicket is using
>>> the services.
>>>
>>> On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com>wrote:
>>>
>>>> You mean @SpringConfigured("something") like in the linked article?
>>>>
>>>> On Thu, May 28, 2009 at 3:41 PM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>> > In your entities, you don't use @SpringBean.  You use
>>>> @Configurable/@Autowire.
>>>> >
>>>> > On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com>
>>>> wrote:
>>>> >> Hi,
>>>> >>
>>>> >> Our current architecture:
>>>> >> ---
>>>> >>
>>>> >> We're currently using a 3-tier architecture (presentation,
>>>> >> service/business and persistence) consisting of Wicket (+ a little
>>>> >> Spring), Spring and Spring + Hibernate:
>>>> >>
>>>> >> Wicket:
>>>> >>
>>>> >> Does presentation, we're not inside a transaction / Hibernate session
>>>> >> so all used fields must be loaded by Spring. We call Spring singleton
>>>> >> beans and annotate those fields with @SpringBean.
>>>> >>
>>>> >> Spring:
>>>> >>
>>>> >> In the service layer we have Spring singleton beans, services, which
>>>> >> are called from the Wicket layer. We have our transaction / Hibernate
>>>> >> session boundary at this layer. We call DAO's from this layer.
>>>> >>
>>>> >> Spring + Hibernate:
>>>> >>
>>>> >> Our DAO's are Spring singleton beans which performs database
>>>> >> operations using HibernateTemplate.
>>>> >>
>>>> >> And common to all the layers are our entities. We use the @Entity
>>>> >> annotation on them (not XML), from the Wicket layer we just use the
>>>> >> accessor methods making sure that the relevant fields are loaded (as
>>>> >> we would get an exception if they were Lazy and not yet loaded). Our
>>>> >> entities are stupid, they lack logic and are used mostly like a struct
>>>> >> in C/C++.
>>>> >>
>>>> >> I think the general pattern is pretty common for Java EE and Spring
>>>> >> based web applications (feel free to disagree!). Yet it's classified
>>>> >> as an anti-pattern by Martin Fowler as we are using mostly procedural
>>>> >> programming and have an anemic domain model (
>>>> >> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>>> >>
>>>> >> What I would like:
>>>> >> ---
>>>> >>
>>>> >> I would like to use a more OOP approach and have logic in our current
>>>> >> entities, creating a rich domain model. For that to work in all cases
>>>> >> they need to be able to load and save data. I would still use a Spring
>>>> >> singleton bean's for different services. But instead of changing the
>>>> >> entities like structs they would be rich objects capable of chaning
>>>> >> themself's and other objects.
>>>> >>
>>>> >> I found this article very interesting:
>>>> >> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>>> >>
>>>> >> But how would something like that work with Wicket? Could I just use
>>>> >> @SpringBean like I'm currently doing but use it on both "entities" and
>>>> >> Spring singleton services?
>>>> >>
>>>> >> For me this has a purely practical benefit, as I could use some
>>>> >> inheritance in the domain object model to create different variations
>>>> >> of logic and not just data. Wicket feels quite agile and nice to work
>>>> >> with, but I still feel that the current architecture is a bit stale
>>>> >> and seldom supports elegant OO solutions (that said, of course things
>>>> >> can still be solved elegantly, I just think it would be easier if I
>>>> >> could do it in a more OO oriented way).
>>>> >>
>>>> >> Comments? What are the pros and cons of this kind of architecture?
>>>> >>
>>>> >> All comments are greatly appreciated!
>>>> >>
>>>> >> Best regards, Kent
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[James Carman <jc...@carmanconsulting.com>]

Are you talking about DAOs (data access objects) and not DTOs (data
transfer objects)?  DTOs are typically not singletons.  Nor are they
set up via spring.

On Thu, May 28, 2009 at 11:20 AM, Kent Larsson <ke...@gmail.com> wrote:
> Do you have a separation between domain objects and DTO's? It sounds
> like you don't (and there is nothing wrong with that), but if you do,
> how do you inject the DTO into the entity? In my case each DTO is a
> Spring singleton bean.
>
> On Thu, May 28, 2009 at 4:17 PM, Will Jaynes <wi...@jaynes.org> wrote:
>> I use the same setup as you, but I add the use of the
>> OpenEntityManagerInViewFilter. I still use only Spring services from within
>> Wicket (as much as possible), but the domain objects can be as full featured
>> as needed because a Hibernate session is always open when Wicket is using
>> the services.
>>
>> On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com>wrote:
>>
>>> You mean @SpringConfigured("something") like in the linked article?
>>>
>>> On Thu, May 28, 2009 at 3:41 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>> > In your entities, you don't use @SpringBean.  You use
>>> @Configurable/@Autowire.
>>> >
>>> > On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> Our current architecture:
>>> >> ---
>>> >>
>>> >> We're currently using a 3-tier architecture (presentation,
>>> >> service/business and persistence) consisting of Wicket (+ a little
>>> >> Spring), Spring and Spring + Hibernate:
>>> >>
>>> >> Wicket:
>>> >>
>>> >> Does presentation, we're not inside a transaction / Hibernate session
>>> >> so all used fields must be loaded by Spring. We call Spring singleton
>>> >> beans and annotate those fields with @SpringBean.
>>> >>
>>> >> Spring:
>>> >>
>>> >> In the service layer we have Spring singleton beans, services, which
>>> >> are called from the Wicket layer. We have our transaction / Hibernate
>>> >> session boundary at this layer. We call DAO's from this layer.
>>> >>
>>> >> Spring + Hibernate:
>>> >>
>>> >> Our DAO's are Spring singleton beans which performs database
>>> >> operations using HibernateTemplate.
>>> >>
>>> >> And common to all the layers are our entities. We use the @Entity
>>> >> annotation on them (not XML), from the Wicket layer we just use the
>>> >> accessor methods making sure that the relevant fields are loaded (as
>>> >> we would get an exception if they were Lazy and not yet loaded). Our
>>> >> entities are stupid, they lack logic and are used mostly like a struct
>>> >> in C/C++.
>>> >>
>>> >> I think the general pattern is pretty common for Java EE and Spring
>>> >> based web applications (feel free to disagree!). Yet it's classified
>>> >> as an anti-pattern by Martin Fowler as we are using mostly procedural
>>> >> programming and have an anemic domain model (
>>> >> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>> >>
>>> >> What I would like:
>>> >> ---
>>> >>
>>> >> I would like to use a more OOP approach and have logic in our current
>>> >> entities, creating a rich domain model. For that to work in all cases
>>> >> they need to be able to load and save data. I would still use a Spring
>>> >> singleton bean's for different services. But instead of changing the
>>> >> entities like structs they would be rich objects capable of chaning
>>> >> themself's and other objects.
>>> >>
>>> >> I found this article very interesting:
>>> >> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>> >>
>>> >> But how would something like that work with Wicket? Could I just use
>>> >> @SpringBean like I'm currently doing but use it on both "entities" and
>>> >> Spring singleton services?
>>> >>
>>> >> For me this has a purely practical benefit, as I could use some
>>> >> inheritance in the domain object model to create different variations
>>> >> of logic and not just data. Wicket feels quite agile and nice to work
>>> >> with, but I still feel that the current architecture is a bit stale
>>> >> and seldom supports elegant OO solutions (that said, of course things
>>> >> can still be solved elegantly, I just think it would be easier if I
>>> >> could do it in a more OO oriented way).
>>> >>
>>> >> Comments? What are the pros and cons of this kind of architecture?
>>> >>
>>> >> All comments are greatly appreciated!
>>> >>
>>> >> Best regards, Kent
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Do you have a separation between domain objects and DTO's? It sounds
like you don't (and there is nothing wrong with that), but if you do,
how do you inject the DTO into the entity? In my case each DTO is a
Spring singleton bean.

On Thu, May 28, 2009 at 4:17 PM, Will Jaynes <wi...@jaynes.org> wrote:
> I use the same setup as you, but I add the use of the
> OpenEntityManagerInViewFilter. I still use only Spring services from within
> Wicket (as much as possible), but the domain objects can be as full featured
> as needed because a Hibernate session is always open when Wicket is using
> the services.
>
> On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com>wrote:
>
>> You mean @SpringConfigured("something") like in the linked article?
>>
>> On Thu, May 28, 2009 at 3:41 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>> > In your entities, you don't use @SpringBean.  You use
>> @Configurable/@Autowire.
>> >
>> > On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com>
>> wrote:
>> >> Hi,
>> >>
>> >> Our current architecture:
>> >> ---
>> >>
>> >> We're currently using a 3-tier architecture (presentation,
>> >> service/business and persistence) consisting of Wicket (+ a little
>> >> Spring), Spring and Spring + Hibernate:
>> >>
>> >> Wicket:
>> >>
>> >> Does presentation, we're not inside a transaction / Hibernate session
>> >> so all used fields must be loaded by Spring. We call Spring singleton
>> >> beans and annotate those fields with @SpringBean.
>> >>
>> >> Spring:
>> >>
>> >> In the service layer we have Spring singleton beans, services, which
>> >> are called from the Wicket layer. We have our transaction / Hibernate
>> >> session boundary at this layer. We call DAO's from this layer.
>> >>
>> >> Spring + Hibernate:
>> >>
>> >> Our DAO's are Spring singleton beans which performs database
>> >> operations using HibernateTemplate.
>> >>
>> >> And common to all the layers are our entities. We use the @Entity
>> >> annotation on them (not XML), from the Wicket layer we just use the
>> >> accessor methods making sure that the relevant fields are loaded (as
>> >> we would get an exception if they were Lazy and not yet loaded). Our
>> >> entities are stupid, they lack logic and are used mostly like a struct
>> >> in C/C++.
>> >>
>> >> I think the general pattern is pretty common for Java EE and Spring
>> >> based web applications (feel free to disagree!). Yet it's classified
>> >> as an anti-pattern by Martin Fowler as we are using mostly procedural
>> >> programming and have an anemic domain model (
>> >> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>> >>
>> >> What I would like:
>> >> ---
>> >>
>> >> I would like to use a more OOP approach and have logic in our current
>> >> entities, creating a rich domain model. For that to work in all cases
>> >> they need to be able to load and save data. I would still use a Spring
>> >> singleton bean's for different services. But instead of changing the
>> >> entities like structs they would be rich objects capable of chaning
>> >> themself's and other objects.
>> >>
>> >> I found this article very interesting:
>> >> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>> >>
>> >> But how would something like that work with Wicket? Could I just use
>> >> @SpringBean like I'm currently doing but use it on both "entities" and
>> >> Spring singleton services?
>> >>
>> >> For me this has a purely practical benefit, as I could use some
>> >> inheritance in the domain object model to create different variations
>> >> of logic and not just data. Wicket feels quite agile and nice to work
>> >> with, but I still feel that the current architecture is a bit stale
>> >> and seldom supports elegant OO solutions (that said, of course things
>> >> can still be solved elegantly, I just think it would be easier if I
>> >> could do it in a more OO oriented way).
>> >>
>> >> Comments? What are the pros and cons of this kind of architecture?
>> >>
>> >> All comments are greatly appreciated!
>> >>
>> >> Best regards, Kent
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Will Jaynes <wi...@jaynes.org>]

I use the same setup as you, but I add the use of the
OpenEntityManagerInViewFilter. I still use only Spring services from within
Wicket (as much as possible), but the domain objects can be as full featured
as needed because a Hibernate session is always open when Wicket is using
the services.

On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com>wrote:

> You mean @SpringConfigured("something") like in the linked article?
>
> On Thu, May 28, 2009 at 3:41 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
> > In your entities, you don't use @SpringBean.  You use
> @Configurable/@Autowire.
> >
> > On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com>
> wrote:
> >> Hi,
> >>
> >> Our current architecture:
> >> ---
> >>
> >> We're currently using a 3-tier architecture (presentation,
> >> service/business and persistence) consisting of Wicket (+ a little
> >> Spring), Spring and Spring + Hibernate:
> >>
> >> Wicket:
> >>
> >> Does presentation, we're not inside a transaction / Hibernate session
> >> so all used fields must be loaded by Spring. We call Spring singleton
> >> beans and annotate those fields with @SpringBean.
> >>
> >> Spring:
> >>
> >> In the service layer we have Spring singleton beans, services, which
> >> are called from the Wicket layer. We have our transaction / Hibernate
> >> session boundary at this layer. We call DAO's from this layer.
> >>
> >> Spring + Hibernate:
> >>
> >> Our DAO's are Spring singleton beans which performs database
> >> operations using HibernateTemplate.
> >>
> >> And common to all the layers are our entities. We use the @Entity
> >> annotation on them (not XML), from the Wicket layer we just use the
> >> accessor methods making sure that the relevant fields are loaded (as
> >> we would get an exception if they were Lazy and not yet loaded). Our
> >> entities are stupid, they lack logic and are used mostly like a struct
> >> in C/C++.
> >>
> >> I think the general pattern is pretty common for Java EE and Spring
> >> based web applications (feel free to disagree!). Yet it's classified
> >> as an anti-pattern by Martin Fowler as we are using mostly procedural
> >> programming and have an anemic domain model (
> >> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >>
> >> What I would like:
> >> ---
> >>
> >> I would like to use a more OOP approach and have logic in our current
> >> entities, creating a rich domain model. For that to work in all cases
> >> they need to be able to load and save data. I would still use a Spring
> >> singleton bean's for different services. But instead of changing the
> >> entities like structs they would be rich objects capable of chaning
> >> themself's and other objects.
> >>
> >> I found this article very interesting:
> >> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >>
> >> But how would something like that work with Wicket? Could I just use
> >> @SpringBean like I'm currently doing but use it on both "entities" and
> >> Spring singleton services?
> >>
> >> For me this has a purely practical benefit, as I could use some
> >> inheritance in the domain object model to create different variations
> >> of logic and not just data. Wicket feels quite agile and nice to work
> >> with, but I still feel that the current architecture is a bit stale
> >> and seldom supports elegant OO solutions (that said, of course things
> >> can still be solved elegantly, I just think it would be easier if I
> >> could do it in a more OO oriented way).
> >>
> >> Comments? What are the pros and cons of this kind of architecture?
> >>
> >> All comments are greatly appreciated!
> >>
> >> Best regards, Kent
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Ah, I just saw Autowired and the fact that you answered within three
minutes. I thought I wasn't clear enough, but apparently I was. I have
to say I'm *very* impressed! :-)

I'll check this out more and I'll post my results here later on (after
that I'll go into your other tip [in the other mail list thread]).
Your Wicket Advanced example has been very educational (for me) to
look at, I highly recommend it to others!

If this works out I may be getting close to my dream development
environment. :-)

Until later!

Best regards Kent



On Thu, May 28, 2009 at 4:22 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> No, I mean @Configurable/@Autowired
>
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Configurable.html
>
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Autowired.html
>
>
> With these, you can also use AspectJ to set things up.  There are
> aspects in spring-aspects.jar that takes care of it.  You have to
> introduce the AspectJ compiler into your build, but I believe that's
> done for you in my wicket-advanced example application.
>
> On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com> wrote:
>> You mean @SpringConfigured("something") like in the linked article?
>>
>> On Thu, May 28, 2009 at 3:41 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> In your entities, you don't use @SpringBean.  You use @Configurable/@Autowire.
>>>
>>> On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Our current architecture:
>>>> ---
>>>>
>>>> We're currently using a 3-tier architecture (presentation,
>>>> service/business and persistence) consisting of Wicket (+ a little
>>>> Spring), Spring and Spring + Hibernate:
>>>>
>>>> Wicket:
>>>>
>>>> Does presentation, we're not inside a transaction / Hibernate session
>>>> so all used fields must be loaded by Spring. We call Spring singleton
>>>> beans and annotate those fields with @SpringBean.
>>>>
>>>> Spring:
>>>>
>>>> In the service layer we have Spring singleton beans, services, which
>>>> are called from the Wicket layer. We have our transaction / Hibernate
>>>> session boundary at this layer. We call DAO's from this layer.
>>>>
>>>> Spring + Hibernate:
>>>>
>>>> Our DAO's are Spring singleton beans which performs database
>>>> operations using HibernateTemplate.
>>>>
>>>> And common to all the layers are our entities. We use the @Entity
>>>> annotation on them (not XML), from the Wicket layer we just use the
>>>> accessor methods making sure that the relevant fields are loaded (as
>>>> we would get an exception if they were Lazy and not yet loaded). Our
>>>> entities are stupid, they lack logic and are used mostly like a struct
>>>> in C/C++.
>>>>
>>>> I think the general pattern is pretty common for Java EE and Spring
>>>> based web applications (feel free to disagree!). Yet it's classified
>>>> as an anti-pattern by Martin Fowler as we are using mostly procedural
>>>> programming and have an anemic domain model (
>>>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>>>
>>>> What I would like:
>>>> ---
>>>>
>>>> I would like to use a more OOP approach and have logic in our current
>>>> entities, creating a rich domain model. For that to work in all cases
>>>> they need to be able to load and save data. I would still use a Spring
>>>> singleton bean's for different services. But instead of changing the
>>>> entities like structs they would be rich objects capable of chaning
>>>> themself's and other objects.
>>>>
>>>> I found this article very interesting:
>>>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>>>
>>>> But how would something like that work with Wicket? Could I just use
>>>> @SpringBean like I'm currently doing but use it on both "entities" and
>>>> Spring singleton services?
>>>>
>>>> For me this has a purely practical benefit, as I could use some
>>>> inheritance in the domain object model to create different variations
>>>> of logic and not just data. Wicket feels quite agile and nice to work
>>>> with, but I still feel that the current architecture is a bit stale
>>>> and seldom supports elegant OO solutions (that said, of course things
>>>> can still be solved elegantly, I just think it would be easier if I
>>>> could do it in a more OO oriented way).
>>>>
>>>> Comments? What are the pros and cons of this kind of architecture?
>>>>
>>>> All comments are greatly appreciated!
>>>>
>>>> Best regards, Kent
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[James Carman <jc...@carmanconsulting.com>]

No, I mean @Configurable/@Autowired

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Configurable.html

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Autowired.html


With these, you can also use AspectJ to set things up.  There are
aspects in spring-aspects.jar that takes care of it.  You have to
introduce the AspectJ compiler into your build, but I believe that's
done for you in my wicket-advanced example application.

On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <ke...@gmail.com> wrote:
> You mean @SpringConfigured("something") like in the linked article?
>
> On Thu, May 28, 2009 at 3:41 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> In your entities, you don't use @SpringBean.  You use @Configurable/@Autowire.
>>
>> On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com> wrote:
>>> Hi,
>>>
>>> Our current architecture:
>>> ---
>>>
>>> We're currently using a 3-tier architecture (presentation,
>>> service/business and persistence) consisting of Wicket (+ a little
>>> Spring), Spring and Spring + Hibernate:
>>>
>>> Wicket:
>>>
>>> Does presentation, we're not inside a transaction / Hibernate session
>>> so all used fields must be loaded by Spring. We call Spring singleton
>>> beans and annotate those fields with @SpringBean.
>>>
>>> Spring:
>>>
>>> In the service layer we have Spring singleton beans, services, which
>>> are called from the Wicket layer. We have our transaction / Hibernate
>>> session boundary at this layer. We call DAO's from this layer.
>>>
>>> Spring + Hibernate:
>>>
>>> Our DAO's are Spring singleton beans which performs database
>>> operations using HibernateTemplate.
>>>
>>> And common to all the layers are our entities. We use the @Entity
>>> annotation on them (not XML), from the Wicket layer we just use the
>>> accessor methods making sure that the relevant fields are loaded (as
>>> we would get an exception if they were Lazy and not yet loaded). Our
>>> entities are stupid, they lack logic and are used mostly like a struct
>>> in C/C++.
>>>
>>> I think the general pattern is pretty common for Java EE and Spring
>>> based web applications (feel free to disagree!). Yet it's classified
>>> as an anti-pattern by Martin Fowler as we are using mostly procedural
>>> programming and have an anemic domain model (
>>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>>
>>> What I would like:
>>> ---
>>>
>>> I would like to use a more OOP approach and have logic in our current
>>> entities, creating a rich domain model. For that to work in all cases
>>> they need to be able to load and save data. I would still use a Spring
>>> singleton bean's for different services. But instead of changing the
>>> entities like structs they would be rich objects capable of chaning
>>> themself's and other objects.
>>>
>>> I found this article very interesting:
>>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>>
>>> But how would something like that work with Wicket? Could I just use
>>> @SpringBean like I'm currently doing but use it on both "entities" and
>>> Spring singleton services?
>>>
>>> For me this has a purely practical benefit, as I could use some
>>> inheritance in the domain object model to create different variations
>>> of logic and not just data. Wicket feels quite agile and nice to work
>>> with, but I still feel that the current architecture is a bit stale
>>> and seldom supports elegant OO solutions (that said, of course things
>>> can still be solved elegantly, I just think it would be easier if I
>>> could do it in a more OO oriented way).
>>>
>>> Comments? What are the pros and cons of this kind of architecture?
>>>
>>> All comments are greatly appreciated!
>>>
>>> Best regards, Kent
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

You mean @SpringConfigured("something") like in the linked article?

On Thu, May 28, 2009 at 3:41 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> In your entities, you don't use @SpringBean.  You use @Configurable/@Autowire.
>
> On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com> wrote:
>> Hi,
>>
>> Our current architecture:
>> ---
>>
>> We're currently using a 3-tier architecture (presentation,
>> service/business and persistence) consisting of Wicket (+ a little
>> Spring), Spring and Spring + Hibernate:
>>
>> Wicket:
>>
>> Does presentation, we're not inside a transaction / Hibernate session
>> so all used fields must be loaded by Spring. We call Spring singleton
>> beans and annotate those fields with @SpringBean.
>>
>> Spring:
>>
>> In the service layer we have Spring singleton beans, services, which
>> are called from the Wicket layer. We have our transaction / Hibernate
>> session boundary at this layer. We call DAO's from this layer.
>>
>> Spring + Hibernate:
>>
>> Our DAO's are Spring singleton beans which performs database
>> operations using HibernateTemplate.
>>
>> And common to all the layers are our entities. We use the @Entity
>> annotation on them (not XML), from the Wicket layer we just use the
>> accessor methods making sure that the relevant fields are loaded (as
>> we would get an exception if they were Lazy and not yet loaded). Our
>> entities are stupid, they lack logic and are used mostly like a struct
>> in C/C++.
>>
>> I think the general pattern is pretty common for Java EE and Spring
>> based web applications (feel free to disagree!). Yet it's classified
>> as an anti-pattern by Martin Fowler as we are using mostly procedural
>> programming and have an anemic domain model (
>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>
>> What I would like:
>> ---
>>
>> I would like to use a more OOP approach and have logic in our current
>> entities, creating a rich domain model. For that to work in all cases
>> they need to be able to load and save data. I would still use a Spring
>> singleton bean's for different services. But instead of changing the
>> entities like structs they would be rich objects capable of chaning
>> themself's and other objects.
>>
>> I found this article very interesting:
>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>
>> But how would something like that work with Wicket? Could I just use
>> @SpringBean like I'm currently doing but use it on both "entities" and
>> Spring singleton services?
>>
>> For me this has a purely practical benefit, as I could use some
>> inheritance in the domain object model to create different variations
>> of logic and not just data. Wicket feels quite agile and nice to work
>> with, but I still feel that the current architecture is a bit stale
>> and seldom supports elegant OO solutions (that said, of course things
>> can still be solved elegantly, I just think it would be easier if I
>> could do it in a more OO oriented way).
>>
>> Comments? What are the pros and cons of this kind of architecture?
>>
>> All comments are greatly appreciated!
>>
>> Best regards, Kent
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[James Carman <jc...@carmanconsulting.com>]

In your entities, you don't use @SpringBean.  You use @Configurable/@Autowire.

On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <ke...@gmail.com> wrote:
> Hi,
>
> Our current architecture:
> ---
>
> We're currently using a 3-tier architecture (presentation,
> service/business and persistence) consisting of Wicket (+ a little
> Spring), Spring and Spring + Hibernate:
>
> Wicket:
>
> Does presentation, we're not inside a transaction / Hibernate session
> so all used fields must be loaded by Spring. We call Spring singleton
> beans and annotate those fields with @SpringBean.
>
> Spring:
>
> In the service layer we have Spring singleton beans, services, which
> are called from the Wicket layer. We have our transaction / Hibernate
> session boundary at this layer. We call DAO's from this layer.
>
> Spring + Hibernate:
>
> Our DAO's are Spring singleton beans which performs database
> operations using HibernateTemplate.
>
> And common to all the layers are our entities. We use the @Entity
> annotation on them (not XML), from the Wicket layer we just use the
> accessor methods making sure that the relevant fields are loaded (as
> we would get an exception if they were Lazy and not yet loaded). Our
> entities are stupid, they lack logic and are used mostly like a struct
> in C/C++.
>
> I think the general pattern is pretty common for Java EE and Spring
> based web applications (feel free to disagree!). Yet it's classified
> as an anti-pattern by Martin Fowler as we are using mostly procedural
> programming and have an anemic domain model (
> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>
> What I would like:
> ---
>
> I would like to use a more OOP approach and have logic in our current
> entities, creating a rich domain model. For that to work in all cases
> they need to be able to load and save data. I would still use a Spring
> singleton bean's for different services. But instead of changing the
> entities like structs they would be rich objects capable of chaning
> themself's and other objects.
>
> I found this article very interesting:
> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>
> But how would something like that work with Wicket? Could I just use
> @SpringBean like I'm currently doing but use it on both "entities" and
> Spring singleton services?
>
> For me this has a purely practical benefit, as I could use some
> inheritance in the domain object model to create different variations
> of logic and not just data. Wicket feels quite agile and nice to work
> with, but I still feel that the current architecture is a bit stale
> and seldom supports elegant OO solutions (that said, of course things
> can still be solved elegantly, I just think it would be easier if I
> could do it in a more OO oriented way).
>
> Comments? What are the pros and cons of this kind of architecture?
>
> All comments are greatly appreciated!
>
> Best regards, Kent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

RE: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Chris Colman <ch...@stepaheadsoftware.com>]

Yep, we use HttpSessionStore in a non clustered environment.

We also turn off session persistence in Tomcat in context.xml with 

    <Manager pathname="" />

So we there should be no session spooling to disk by the servlet
container.

Cool, I can relax now =]


> noep, there since 1.3.6 and enabled by default. if you use
> httpsessionstore the problem will only appear when clustering or when
> servlet container spools sessions to disk.
> 
> -igor
> 
> On Thu, May 28, 2009 at 7:26 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
> > Is that a relatively new feature because we're still on 1.4m2
> > (2008/05/24) and haven't had any trouble with non serializeable
model
> > objects when going back to pages that have been spooled to disk.
> >
> > Maybe if it's a newer feature and we upgrade to the latest wicket we
> > might start seeing some problems due to the lack of serializability
of
> > our model objects.... hmmm
> >
> > Chris
> >
> >> to keep memory overhread low only the last visisted page is stored
in
> >> http session. the rest of the pages are spooled to disk for
long-term
> >> storage in case the user uses the back button, and are cleaned up
on
> >> session expiration.
> >>
> >> -igor
> >>
> >> On Thu, May 28, 2009 at 6:54 PM, Chris Colman
> >> <ch...@stepaheadsoftware.com> wrote:
> >> > When you say "offline storage" do you mean that the user has
chosen
> > to
> >> > save pages for future offline reference or do you mean a more
> >> > 'automated' process that wicket performs when system memory
becomes
> > too
> >> > low?
> >> >
> >> > Chris
> >> >
> >> >> -----Original Message-----
> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> >> Sent: Friday, 29 May 2009 11:43 AM
> >> >> To: users@wicket.apache.org
> >> >> Subject: Re: Anemic domain model and are @SpringBean's
compatible
> > with
> >> > the
> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >> >>
> >> >> well, this is why salve removes the dependency field to at least
> > help
> >> >> with those.
> >> >>
> >> >> other then that you can use a loadabledetachablemodel to release
> > the
> >> >> reference when the page is not used.
> >> >>
> >> >> -igor
> >> >>
> >> >> On Thu, May 28, 2009 at 6:40 PM, Chris Colman
> >> >> <ch...@stepaheadsoftware.com> wrote:
> >> >> > Is that controllable?
> >> >> >
> >> >> > What if I have complex object models referenced from wicket UI
> >> >> > components that I don't want (can't reasonably with Java's non
> >> > optimal
> >> >> > serialization) serialized?
> >> >> >
> >> >> > If we're serializing for offline storage aren't we going to
> > require
> >> > the
> >> >> > underlying model objects to get serialized as well?
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> serialization in the context when you need to serialize the
> > object
> >> > -
> >> >> >> eg wicket serializes its pages for offline storage, etc.
> >> >> >>
> >> >> >> -igor
> >> >> >>
> >> >> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
> >> >> >> <ch...@stepaheadsoftware.com> wrote:
> >> >> >> > Another extremely light weight IoC with ORM wrapping (JDO
and
> >> >> > Hibernate)
> >> >> >> > is exPOJO at http://www.expojo.com
> >> >> >> >
> >> >> >> > No need for old fashioned DAOs etc., just POJOs being
> > persisted
> >> >> >> > transparently the way they should be.
> >> >> >> >
> >> >> >> > In terms of serialization:
> >> >> >> >
> >> >> >> > Is that for the purpose of scaling in a cluster
environment? I
> >> > vote
> >> >> > for
> >> >> >> > 'session affinity' every time - it's almost necessary when
you
> >> > have
> >> >> >> > anything more sophisticated than an anemic domain model. Do
> > you
> >> >> > really
> >> >> >> > want to be shifting complex object models from server to
> > server
> >> > via
> >> >> >> > serialization?
> >> >> >> >
> >> >> >> > If it's not for a cluster environment but for a single
server
> > to
> >> >> > allow
> >> >> >> > stale sessions to be swapped out then let the garbage
> > collection
> >> >> > clean
> >> >> >> > out the ORM's object cache instead.
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> >> >> >> Sent: Friday, 29 May 2009 3:38 AM
> >> >> >> >> To: users@wicket.apache.org
> >> >> >> >> Subject: Re: Anemic domain model and are @SpringBean's
> >> > compatible
> >> >> > with
> >> >> >> > the
> >> >> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >> >> >> >>
> >> >> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> >> >> >> > <ke...@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >> > Nice! I think Salve looks great! And it solves more than
> > this
> >> >> >> > problem,
> >> >> >> >> > I like the design by contract module too as it allows me
to
> >> >> > validate
> >> >> >> >> > parameters in a bit more declarative way.
> >> >> >> >> >
> >> >> >> >> > Do you think Salve is ready to be used in production?
I'm a
> >> > bit
> >> >> >> >> > concerned by "Although already usable, Salve is still in
> > its
> >> >> >> > infancy.
> >> >> >> >> > Not all features have been implemented and not all
problems
> >> >> > worked
> >> >> >> >> > out.". I only see one open issue and it doesn't seem too
> > major
> >> >> > for
> >> >> >> > me
> >> >> >> >> > to pick it up.
> >> >> >> >>
> >> >> >> >> we have been using it in production for a while without
any
> >> >> > problems.
> >> >> >> >> i just need to find the time to update the website text :)
> >> >> >> >>
> >> >> >> >> > If I'm not mistaken Salve may be used (for lots of
things,
> > but
> >> >> > one
> >> >> >> > is)
> >> >> >> >> > to solve serialization issues with Spring beans in
Wicket
> >> >> >> > components?
> >> >> >> >> > But isn't that the same issue that the Wicket IOC and
it's
> >> >> >> > @SpringBean
> >> >> >> >> > annotation solves?
> >> >> >> >>
> >> >> >> >> wicket ioc can only take it so far. because it has to
> > generate a
> >> >> > proxy
> >> >> >> >> there are limitations to what classes can be proxies - eg
no
> >> > final
> >> >> >> >> methods, default constructor, etc. salve doesnt use a
proxy
> > so
> >> > it
> >> >> >> >> doesnt have any problems.
> >> >> >> >>
> >> >> >> >> although small, wicket ioc does have an overhead of having
to
> >> >> >> >> serialize the proxy with the componnet. since salve
removes
> > the
> >> >> > field
> >> >> >> >> it has no such overhead, this is more important when you
are
> >> >> > returning
> >> >> >> >> large resultsets of entities that use dependencies.
> >> >> >> >>
> >> >> >> >> > If that's the case: Could I use Spring to inject my
> > entities
> >> > with
> >> >> >> >> > DAO's for now, and use the @SpringBean annotation on
those
> > as
> >> >> > well
> >> >> >> > in
> >> >> >> >> > my Wicket components (In those cases I have entities as
> > class
> >> >> > vars)?
> >> >> >> >> > And the @SpringBean will solve the serialization issue?
> >> >> >> >>
> >> >> >> >> you can use whatever works for you. salve is an
alternative
> > :)
> >> >> >> >>
> >> >> >> >> > By just looking at Salve a bit it seems I could migrate
to
> >> > Salve
> >> >> > in
> >> >> >> >> > two steps that way. And it might be a pretty smooth path
to
> >> > take?
> >> >> > It
> >> >> >> >> > would mean that I inject 1000 entities for no good
reason.
> > But
> >> > if
> >> >> > I
> >> >> >> >> > see a performance problem in doing so I could just
migrate
> > to
> >> >> > Salve?
> >> >> >> >> > By smooth path I mean that I would have access to my
DAO's
> > in
> >> > my
> >> >> >> >> > entities and would essentially only change the
dependency
> >> >> >> > annotations
> >> >> >> >> > and setup Salve.
> >> >> >> >>
> >> >> >> >> as long as you do not use spring-specific injection rules
you
> >> >> > should
> >> >> >> >> be fine. salve uses lookup by type primarily, but also
does
> > have
> >> >> >> >> @SpringBeanId that can be used as a qualifier.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> > Of course, if Salve is production ready. Then could I
throw
> >> > out
> >> >> >> > Wicket
> >> >> >> >> > IOC and the @SpringBean annotation and use Salve instead
to
> >> > solve
> >> >> >> >> > serialization issues? In this case I would use Salve for
my
> >> >> >> >> > presentation/Wicket -layer as well as dependency
injection
> > in
> >> > my
> >> >> >> >> > entities and Spring as I already do for my
service/business
> >> >> > -layer
> >> >> >> > and
> >> >> >> >> > my persistence/DTO -layer. Or would it be nicer to have
> > Salve
> >> >> > handle
> >> >> >> >> > dependencies in the last two layers as well?
> >> >> >> >>
> >> >> >> >> we use salve to inject across all layers. it gives you a
> >> > consistent
> >> >> >> >> approach to use and mock in unit tests. we have a spring
> > context
> >> >> > that
> >> >> >> >> contains true services - eg session factory, mail sender,
> > credit
> >> >> > card
> >> >> >> >> processor, etc. all of our domain model then uses salve to
> >> > inject
> >> >> >> >> these wherever needed.
> >> >> >> >>
> >> >> >> >> -igor
> >> >> >> >>
> >> >> >> >> > A lot of questions and text. Thanks for reading this
far!
> > :-)
> >> >> >> >> >
> >> >> >> >> > Best regards, Kent
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> >> >> >> > <ig...@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >> >> this is why i built salve.googlecode.com
> >> >> >> >> >>
> >> >> >> >> >> you can easily hook it into spring and have all your
> > objects
> >> >> > (doman
> >> >> >> >> >> objects or wicket components) injected via @Dependency
> >> > without
> >> >> >> >> >> worrying about serialization issues or eager injection
-
> > eg
> >> > if
> >> >> > you
> >> >> >> >> >> load a result set of 1000 hibernate entities that need
> >> > injection
> >> >> >> > you
> >> >> >> >> >> dont want all those injected for no reason.
> >> >> >> >> >>
> >> >> >> >> >> -igor
> >> >> >> >> >>
> >> >> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> >> >> >> > <ke...@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >> >>> Hi,
> >> >> >> >> >>>
> >> >> >> >> >>> Our current architecture:
> >> >> >> >> >>> ---
> >> >> >> >> >>>
> >> >> >> >> >>> We're currently using a 3-tier architecture
> > (presentation,
> >> >> >> >> >>> service/business and persistence) consisting of Wicket
(+
> > a
> >> >> > little
> >> >> >> >> >>> Spring), Spring and Spring + Hibernate:
> >> >> >> >> >>>
> >> >> >> >> >>> Wicket:
> >> >> >> >> >>>
> >> >> >> >> >>> Does presentation, we're not inside a transaction /
> >> > Hibernate
> >> >> >> > session
> >> >> >> >> >>> so all used fields must be loaded by Spring. We call
> > Spring
> >> >> >> > singleton
> >> >> >> >> >>> beans and annotate those fields with @SpringBean.
> >> >> >> >> >>>
> >> >> >> >> >>> Spring:
> >> >> >> >> >>>
> >> >> >> >> >>> In the service layer we have Spring singleton beans,
> >> > services,
> >> >> >> > which
> >> >> >> >> >>> are called from the Wicket layer. We have our
transaction
> > /
> >> >> >> > Hibernate
> >> >> >> >> >>> session boundary at this layer. We call DAO's from
this
> >> > layer.
> >> >> >> >> >>>
> >> >> >> >> >>> Spring + Hibernate:
> >> >> >> >> >>>
> >> >> >> >> >>> Our DAO's are Spring singleton beans which performs
> > database
> >> >> >> >> >>> operations using HibernateTemplate.
> >> >> >> >> >>>
> >> >> >> >> >>> And common to all the layers are our entities. We use
the
> >> >> > @Entity
> >> >> >> >> >>> annotation on them (not XML), from the Wicket layer we
> > just
> >> > use
> >> >> >> > the
> >> >> >> >> >>> accessor methods making sure that the relevant fields
are
> >> >> > loaded
> >> >> >> > (as
> >> >> >> >> >>> we would get an exception if they were Lazy and not
yet
> >> >> > loaded).
> >> >> >> > Our
> >> >> >> >> >>> entities are stupid, they lack logic and are used
mostly
> >> > like a
> >> >> >> > struct
> >> >> >> >> >>> in C/C++.
> >> >> >> >> >>>
> >> >> >> >> >>> I think the general pattern is pretty common for Java
EE
> > and
> >> >> >> > Spring
> >> >> >> >> >>> based web applications (feel free to disagree!). Yet
it's
> >> >> >> > classified
> >> >> >> >> >>> as an anti-pattern by Martin Fowler as we are using
> > mostly
> >> >> >> > procedural
> >> >> >> >> >>> programming and have an anemic domain model (
> >> >> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >> >> >> >> >>>
> >> >> >> >> >>> What I would like:
> >> >> >> >> >>> ---
> >> >> >> >> >>>
> >> >> >> >> >>> I would like to use a more OOP approach and have logic
in
> >> > our
> >> >> >> > current
> >> >> >> >> >>> entities, creating a rich domain model. For that to
work
> > in
> >> > all
> >> >> >> > cases
> >> >> >> >> >>> they need to be able to load and save data. I would
still
> >> > use a
> >> >> >> > Spring
> >> >> >> >> >>> singleton bean's for different services. But instead
of
> >> >> > changing
> >> >> >> > the
> >> >> >> >> >>> entities like structs they would be rich objects
capable
> > of
> >> >> >> > chaning
> >> >> >> >> >>> themself's and other objects.
> >> >> >> >> >>>
> >> >> >> >> >>> I found this article very interesting:
> >> >> >> >> >>>
> >> > http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >> >> >> >> >>>
> >> >> >> >> >>> But how would something like that work with Wicket?
Could
> > I
> >> >> > just
> >> >> >> > use
> >> >> >> >> >>> @SpringBean like I'm currently doing but use it on
both
> >> >> > "entities"
> >> >> >> > and
> >> >> >> >> >>> Spring singleton services?
> >> >> >> >> >>>
> >> >> >> >> >>> For me this has a purely practical benefit, as I could
> > use
> >> > some
> >> >> >> >> >>> inheritance in the domain object model to create
> > different
> >> >> >> > variations
> >> >> >> >> >>> of logic and not just data. Wicket feels quite agile
and
> >> > nice
> >> >> > to
> >> >> >> > work
> >> >> >> >> >>> with, but I still feel that the current architecture
is a
> >> > bit
> >> >> >> > stale
> >> >> >> >> >>> and seldom supports elegant OO solutions (that said,
of
> >> > course
> >> >> >> > things
> >> >> >> >> >>> can still be solved elegantly, I just think it would
be
> >> > easier
> >> >> > if
> >> >> >> > I
> >> >> >> >> >>> could do it in a more OO oriented way).
> >> >> >> >> >>>
> >> >> >> >> >>> Comments? What are the pros and cons of this kind of
> >> >> > architecture?
> >> >> >> >> >>>
> >> >> >> >> >>> All comments are greatly appreciated!
> >> >> >> >> >>>
> >> >> >> >> >>> Best regards, Kent
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >> >>> To unsubscribe, e-mail:
> > users-unsubscribe@wicket.apache.org
> >> >> >> >> >>> For additional commands, e-mail:
> >> > users-help@wicket.apache.org
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail:
> > users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> > users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail:
users-unsubscribe@wicket.apache.org
> >> >> >> >> > For additional commands, e-mail:
> > users-help@wicket.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail:
users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail:
users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> No virus found in this incoming message.
> >> >> >> >> Checked by AVG - www.avg.com
> >> >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 -
Release
> >> > Date:
> >> >> >> > 05/28/09
> >> >> >> >> 18:09:00
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail:
users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >
> >
---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >> No virus found in this incoming message.
> >> >> >> Checked by AVG - www.avg.com
> >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
> > Date:
> >> >> > 05/28/09
> >> >> >> 18:09:00
> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >> No virus found in this incoming message.
> >> >> Checked by AVG - www.avg.com
> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
Date:
> >> > 05/28/09
> >> >> 18:09:00
> >> >
> >> >
> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> > 05/28/09
> >> 18:09:00
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

noep, there since 1.3.6 and enabled by default. if you use
httpsessionstore the problem will only appear when clustering or when
servlet container spools sessions to disk.

-igor

On Thu, May 28, 2009 at 7:26 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> Is that a relatively new feature because we're still on 1.4m2
> (2008/05/24) and haven't had any trouble with non serializeable model
> objects when going back to pages that have been spooled to disk.
>
> Maybe if it's a newer feature and we upgrade to the latest wicket we
> might start seeing some problems due to the lack of serializability of
> our model objects.... hmmm
>
> Chris
>
>> to keep memory overhread low only the last visisted page is stored in
>> http session. the rest of the pages are spooled to disk for long-term
>> storage in case the user uses the back button, and are cleaned up on
>> session expiration.
>>
>> -igor
>>
>> On Thu, May 28, 2009 at 6:54 PM, Chris Colman
>> <ch...@stepaheadsoftware.com> wrote:
>> > When you say "offline storage" do you mean that the user has chosen
> to
>> > save pages for future offline reference or do you mean a more
>> > 'automated' process that wicket performs when system memory becomes
> too
>> > low?
>> >
>> > Chris
>> >
>> >> -----Original Message-----
>> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> >> Sent: Friday, 29 May 2009 11:43 AM
>> >> To: users@wicket.apache.org
>> >> Subject: Re: Anemic domain model and are @SpringBean's compatible
> with
>> > the
>> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>> >>
>> >> well, this is why salve removes the dependency field to at least
> help
>> >> with those.
>> >>
>> >> other then that you can use a loadabledetachablemodel to release
> the
>> >> reference when the page is not used.
>> >>
>> >> -igor
>> >>
>> >> On Thu, May 28, 2009 at 6:40 PM, Chris Colman
>> >> <ch...@stepaheadsoftware.com> wrote:
>> >> > Is that controllable?
>> >> >
>> >> > What if I have complex object models referenced from wicket UI
>> >> > components that I don't want (can't reasonably with Java's non
>> > optimal
>> >> > serialization) serialized?
>> >> >
>> >> > If we're serializing for offline storage aren't we going to
> require
>> > the
>> >> > underlying model objects to get serialized as well?
>> >> >
>> >> >> -----Original Message-----
>> >> >> serialization in the context when you need to serialize the
> object
>> > -
>> >> >> eg wicket serializes its pages for offline storage, etc.
>> >> >>
>> >> >> -igor
>> >> >>
>> >> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
>> >> >> <ch...@stepaheadsoftware.com> wrote:
>> >> >> > Another extremely light weight IoC with ORM wrapping (JDO and
>> >> > Hibernate)
>> >> >> > is exPOJO at http://www.expojo.com
>> >> >> >
>> >> >> > No need for old fashioned DAOs etc., just POJOs being
> persisted
>> >> >> > transparently the way they should be.
>> >> >> >
>> >> >> > In terms of serialization:
>> >> >> >
>> >> >> > Is that for the purpose of scaling in a cluster environment? I
>> > vote
>> >> > for
>> >> >> > 'session affinity' every time - it's almost necessary when you
>> > have
>> >> >> > anything more sophisticated than an anemic domain model. Do
> you
>> >> > really
>> >> >> > want to be shifting complex object models from server to
> server
>> > via
>> >> >> > serialization?
>> >> >> >
>> >> >> > If it's not for a cluster environment but for a single server
> to
>> >> > allow
>> >> >> > stale sessions to be swapped out then let the garbage
> collection
>> >> > clean
>> >> >> > out the ORM's object cache instead.
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> >> >> >> Sent: Friday, 29 May 2009 3:38 AM
>> >> >> >> To: users@wicket.apache.org
>> >> >> >> Subject: Re: Anemic domain model and are @SpringBean's
>> > compatible
>> >> > with
>> >> >> > the
>> >> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>> >> >> >>
>> >> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
>> >> >> > <ke...@gmail.com>
>> >> >> >> wrote:
>> >> >> >> > Nice! I think Salve looks great! And it solves more than
> this
>> >> >> > problem,
>> >> >> >> > I like the design by contract module too as it allows me to
>> >> > validate
>> >> >> >> > parameters in a bit more declarative way.
>> >> >> >> >
>> >> >> >> > Do you think Salve is ready to be used in production? I'm a
>> > bit
>> >> >> >> > concerned by "Although already usable, Salve is still in
> its
>> >> >> > infancy.
>> >> >> >> > Not all features have been implemented and not all problems
>> >> > worked
>> >> >> >> > out.". I only see one open issue and it doesn't seem too
> major
>> >> > for
>> >> >> > me
>> >> >> >> > to pick it up.
>> >> >> >>
>> >> >> >> we have been using it in production for a while without any
>> >> > problems.
>> >> >> >> i just need to find the time to update the website text :)
>> >> >> >>
>> >> >> >> > If I'm not mistaken Salve may be used (for lots of things,
> but
>> >> > one
>> >> >> > is)
>> >> >> >> > to solve serialization issues with Spring beans in Wicket
>> >> >> > components?
>> >> >> >> > But isn't that the same issue that the Wicket IOC and it's
>> >> >> > @SpringBean
>> >> >> >> > annotation solves?
>> >> >> >>
>> >> >> >> wicket ioc can only take it so far. because it has to
> generate a
>> >> > proxy
>> >> >> >> there are limitations to what classes can be proxies - eg no
>> > final
>> >> >> >> methods, default constructor, etc. salve doesnt use a proxy
> so
>> > it
>> >> >> >> doesnt have any problems.
>> >> >> >>
>> >> >> >> although small, wicket ioc does have an overhead of having to
>> >> >> >> serialize the proxy with the componnet. since salve removes
> the
>> >> > field
>> >> >> >> it has no such overhead, this is more important when you are
>> >> > returning
>> >> >> >> large resultsets of entities that use dependencies.
>> >> >> >>
>> >> >> >> > If that's the case: Could I use Spring to inject my
> entities
>> > with
>> >> >> >> > DAO's for now, and use the @SpringBean annotation on those
> as
>> >> > well
>> >> >> > in
>> >> >> >> > my Wicket components (In those cases I have entities as
> class
>> >> > vars)?
>> >> >> >> > And the @SpringBean will solve the serialization issue?
>> >> >> >>
>> >> >> >> you can use whatever works for you. salve is an alternative
> :)
>> >> >> >>
>> >> >> >> > By just looking at Salve a bit it seems I could migrate to
>> > Salve
>> >> > in
>> >> >> >> > two steps that way. And it might be a pretty smooth path to
>> > take?
>> >> > It
>> >> >> >> > would mean that I inject 1000 entities for no good reason.
> But
>> > if
>> >> > I
>> >> >> >> > see a performance problem in doing so I could just migrate
> to
>> >> > Salve?
>> >> >> >> > By smooth path I mean that I would have access to my DAO's
> in
>> > my
>> >> >> >> > entities and would essentially only change the dependency
>> >> >> > annotations
>> >> >> >> > and setup Salve.
>> >> >> >>
>> >> >> >> as long as you do not use spring-specific injection rules you
>> >> > should
>> >> >> >> be fine. salve uses lookup by type primarily, but also does
> have
>> >> >> >> @SpringBeanId that can be used as a qualifier.
>> >> >> >>
>> >> >> >>
>> >> >> >> > Of course, if Salve is production ready. Then could I throw
>> > out
>> >> >> > Wicket
>> >> >> >> > IOC and the @SpringBean annotation and use Salve instead to
>> > solve
>> >> >> >> > serialization issues? In this case I would use Salve for my
>> >> >> >> > presentation/Wicket -layer as well as dependency injection
> in
>> > my
>> >> >> >> > entities and Spring as I already do for my service/business
>> >> > -layer
>> >> >> > and
>> >> >> >> > my persistence/DTO -layer. Or would it be nicer to have
> Salve
>> >> > handle
>> >> >> >> > dependencies in the last two layers as well?
>> >> >> >>
>> >> >> >> we use salve to inject across all layers. it gives you a
>> > consistent
>> >> >> >> approach to use and mock in unit tests. we have a spring
> context
>> >> > that
>> >> >> >> contains true services - eg session factory, mail sender,
> credit
>> >> > card
>> >> >> >> processor, etc. all of our domain model then uses salve to
>> > inject
>> >> >> >> these wherever needed.
>> >> >> >>
>> >> >> >> -igor
>> >> >> >>
>> >> >> >> > A lot of questions and text. Thanks for reading this far!
> :-)
>> >> >> >> >
>> >> >> >> > Best regards, Kent
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
>> >> >> > <ig...@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >> this is why i built salve.googlecode.com
>> >> >> >> >>
>> >> >> >> >> you can easily hook it into spring and have all your
> objects
>> >> > (doman
>> >> >> >> >> objects or wicket components) injected via @Dependency
>> > without
>> >> >> >> >> worrying about serialization issues or eager injection -
> eg
>> > if
>> >> > you
>> >> >> >> >> load a result set of 1000 hibernate entities that need
>> > injection
>> >> >> > you
>> >> >> >> >> dont want all those injected for no reason.
>> >> >> >> >>
>> >> >> >> >> -igor
>> >> >> >> >>
>> >> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
>> >> >> > <ke...@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >>> Hi,
>> >> >> >> >>>
>> >> >> >> >>> Our current architecture:
>> >> >> >> >>> ---
>> >> >> >> >>>
>> >> >> >> >>> We're currently using a 3-tier architecture
> (presentation,
>> >> >> >> >>> service/business and persistence) consisting of Wicket (+
> a
>> >> > little
>> >> >> >> >>> Spring), Spring and Spring + Hibernate:
>> >> >> >> >>>
>> >> >> >> >>> Wicket:
>> >> >> >> >>>
>> >> >> >> >>> Does presentation, we're not inside a transaction /
>> > Hibernate
>> >> >> > session
>> >> >> >> >>> so all used fields must be loaded by Spring. We call
> Spring
>> >> >> > singleton
>> >> >> >> >>> beans and annotate those fields with @SpringBean.
>> >> >> >> >>>
>> >> >> >> >>> Spring:
>> >> >> >> >>>
>> >> >> >> >>> In the service layer we have Spring singleton beans,
>> > services,
>> >> >> > which
>> >> >> >> >>> are called from the Wicket layer. We have our transaction
> /
>> >> >> > Hibernate
>> >> >> >> >>> session boundary at this layer. We call DAO's from this
>> > layer.
>> >> >> >> >>>
>> >> >> >> >>> Spring + Hibernate:
>> >> >> >> >>>
>> >> >> >> >>> Our DAO's are Spring singleton beans which performs
> database
>> >> >> >> >>> operations using HibernateTemplate.
>> >> >> >> >>>
>> >> >> >> >>> And common to all the layers are our entities. We use the
>> >> > @Entity
>> >> >> >> >>> annotation on them (not XML), from the Wicket layer we
> just
>> > use
>> >> >> > the
>> >> >> >> >>> accessor methods making sure that the relevant fields are
>> >> > loaded
>> >> >> > (as
>> >> >> >> >>> we would get an exception if they were Lazy and not yet
>> >> > loaded).
>> >> >> > Our
>> >> >> >> >>> entities are stupid, they lack logic and are used mostly
>> > like a
>> >> >> > struct
>> >> >> >> >>> in C/C++.
>> >> >> >> >>>
>> >> >> >> >>> I think the general pattern is pretty common for Java EE
> and
>> >> >> > Spring
>> >> >> >> >>> based web applications (feel free to disagree!). Yet it's
>> >> >> > classified
>> >> >> >> >>> as an anti-pattern by Martin Fowler as we are using
> mostly
>> >> >> > procedural
>> >> >> >> >>> programming and have an anemic domain model (
>> >> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>> >> >> >> >>>
>> >> >> >> >>> What I would like:
>> >> >> >> >>> ---
>> >> >> >> >>>
>> >> >> >> >>> I would like to use a more OOP approach and have logic in
>> > our
>> >> >> > current
>> >> >> >> >>> entities, creating a rich domain model. For that to work
> in
>> > all
>> >> >> > cases
>> >> >> >> >>> they need to be able to load and save data. I would still
>> > use a
>> >> >> > Spring
>> >> >> >> >>> singleton bean's for different services. But instead of
>> >> > changing
>> >> >> > the
>> >> >> >> >>> entities like structs they would be rich objects capable
> of
>> >> >> > chaning
>> >> >> >> >>> themself's and other objects.
>> >> >> >> >>>
>> >> >> >> >>> I found this article very interesting:
>> >> >> >> >>>
>> > http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>> >> >> >> >>>
>> >> >> >> >>> But how would something like that work with Wicket? Could
> I
>> >> > just
>> >> >> > use
>> >> >> >> >>> @SpringBean like I'm currently doing but use it on both
>> >> > "entities"
>> >> >> > and
>> >> >> >> >>> Spring singleton services?
>> >> >> >> >>>
>> >> >> >> >>> For me this has a purely practical benefit, as I could
> use
>> > some
>> >> >> >> >>> inheritance in the domain object model to create
> different
>> >> >> > variations
>> >> >> >> >>> of logic and not just data. Wicket feels quite agile and
>> > nice
>> >> > to
>> >> >> > work
>> >> >> >> >>> with, but I still feel that the current architecture is a
>> > bit
>> >> >> > stale
>> >> >> >> >>> and seldom supports elegant OO solutions (that said, of
>> > course
>> >> >> > things
>> >> >> >> >>> can still be solved elegantly, I just think it would be
>> > easier
>> >> > if
>> >> >> > I
>> >> >> >> >>> could do it in a more OO oriented way).
>> >> >> >> >>>
>> >> >> >> >>> Comments? What are the pros and cons of this kind of
>> >> > architecture?
>> >> >> >> >>>
>> >> >> >> >>> All comments are greatly appreciated!
>> >> >> >> >>>
>> >> >> >> >>> Best regards, Kent
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >> >>> To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
>> >> >> >> >>> For additional commands, e-mail:
>> > users-help@wicket.apache.org
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail:
> users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail:
> users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >> No virus found in this incoming message.
>> >> >> >> Checked by AVG - www.avg.com
>> >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
>> > Date:
>> >> >> > 05/28/09
>> >> >> >> 18:09:00
>> >> >> >
>> >> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >
> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >> No virus found in this incoming message.
>> >> >> Checked by AVG - www.avg.com
>> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
> Date:
>> >> > 05/28/09
>> >> >> 18:09:00
>> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >> No virus found in this incoming message.
>> >> Checked by AVG - www.avg.com
>> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
>> > 05/28/09
>> >> 18:09:00
>> >
>> >
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> 05/28/09
>> 18:09:00
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

RE: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Chris Colman <ch...@stepaheadsoftware.com>]

Is that a relatively new feature because we're still on 1.4m2
(2008/05/24) and haven't had any trouble with non serializeable model
objects when going back to pages that have been spooled to disk.

Maybe if it's a newer feature and we upgrade to the latest wicket we
might start seeing some problems due to the lack of serializability of
our model objects.... hmmm

Chris

> to keep memory overhread low only the last visisted page is stored in
> http session. the rest of the pages are spooled to disk for long-term
> storage in case the user uses the back button, and are cleaned up on
> session expiration.
> 
> -igor
> 
> On Thu, May 28, 2009 at 6:54 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
> > When you say "offline storage" do you mean that the user has chosen
to
> > save pages for future offline reference or do you mean a more
> > 'automated' process that wicket performs when system memory becomes
too
> > low?
> >
> > Chris
> >
> >> -----Original Message-----
> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> Sent: Friday, 29 May 2009 11:43 AM
> >> To: users@wicket.apache.org
> >> Subject: Re: Anemic domain model and are @SpringBean's compatible
with
> > the
> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >>
> >> well, this is why salve removes the dependency field to at least
help
> >> with those.
> >>
> >> other then that you can use a loadabledetachablemodel to release
the
> >> reference when the page is not used.
> >>
> >> -igor
> >>
> >> On Thu, May 28, 2009 at 6:40 PM, Chris Colman
> >> <ch...@stepaheadsoftware.com> wrote:
> >> > Is that controllable?
> >> >
> >> > What if I have complex object models referenced from wicket UI
> >> > components that I don't want (can't reasonably with Java's non
> > optimal
> >> > serialization) serialized?
> >> >
> >> > If we're serializing for offline storage aren't we going to
require
> > the
> >> > underlying model objects to get serialized as well?
> >> >
> >> >> -----Original Message-----
> >> >> serialization in the context when you need to serialize the
object
> > -
> >> >> eg wicket serializes its pages for offline storage, etc.
> >> >>
> >> >> -igor
> >> >>
> >> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
> >> >> <ch...@stepaheadsoftware.com> wrote:
> >> >> > Another extremely light weight IoC with ORM wrapping (JDO and
> >> > Hibernate)
> >> >> > is exPOJO at http://www.expojo.com
> >> >> >
> >> >> > No need for old fashioned DAOs etc., just POJOs being
persisted
> >> >> > transparently the way they should be.
> >> >> >
> >> >> > In terms of serialization:
> >> >> >
> >> >> > Is that for the purpose of scaling in a cluster environment? I
> > vote
> >> > for
> >> >> > 'session affinity' every time - it's almost necessary when you
> > have
> >> >> > anything more sophisticated than an anemic domain model. Do
you
> >> > really
> >> >> > want to be shifting complex object models from server to
server
> > via
> >> >> > serialization?
> >> >> >
> >> >> > If it's not for a cluster environment but for a single server
to
> >> > allow
> >> >> > stale sessions to be swapped out then let the garbage
collection
> >> > clean
> >> >> > out the ORM's object cache instead.
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> >> >> Sent: Friday, 29 May 2009 3:38 AM
> >> >> >> To: users@wicket.apache.org
> >> >> >> Subject: Re: Anemic domain model and are @SpringBean's
> > compatible
> >> > with
> >> >> > the
> >> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >> >> >>
> >> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> >> >> > <ke...@gmail.com>
> >> >> >> wrote:
> >> >> >> > Nice! I think Salve looks great! And it solves more than
this
> >> >> > problem,
> >> >> >> > I like the design by contract module too as it allows me to
> >> > validate
> >> >> >> > parameters in a bit more declarative way.
> >> >> >> >
> >> >> >> > Do you think Salve is ready to be used in production? I'm a
> > bit
> >> >> >> > concerned by "Although already usable, Salve is still in
its
> >> >> > infancy.
> >> >> >> > Not all features have been implemented and not all problems
> >> > worked
> >> >> >> > out.". I only see one open issue and it doesn't seem too
major
> >> > for
> >> >> > me
> >> >> >> > to pick it up.
> >> >> >>
> >> >> >> we have been using it in production for a while without any
> >> > problems.
> >> >> >> i just need to find the time to update the website text :)
> >> >> >>
> >> >> >> > If I'm not mistaken Salve may be used (for lots of things,
but
> >> > one
> >> >> > is)
> >> >> >> > to solve serialization issues with Spring beans in Wicket
> >> >> > components?
> >> >> >> > But isn't that the same issue that the Wicket IOC and it's
> >> >> > @SpringBean
> >> >> >> > annotation solves?
> >> >> >>
> >> >> >> wicket ioc can only take it so far. because it has to
generate a
> >> > proxy
> >> >> >> there are limitations to what classes can be proxies - eg no
> > final
> >> >> >> methods, default constructor, etc. salve doesnt use a proxy
so
> > it
> >> >> >> doesnt have any problems.
> >> >> >>
> >> >> >> although small, wicket ioc does have an overhead of having to
> >> >> >> serialize the proxy with the componnet. since salve removes
the
> >> > field
> >> >> >> it has no such overhead, this is more important when you are
> >> > returning
> >> >> >> large resultsets of entities that use dependencies.
> >> >> >>
> >> >> >> > If that's the case: Could I use Spring to inject my
entities
> > with
> >> >> >> > DAO's for now, and use the @SpringBean annotation on those
as
> >> > well
> >> >> > in
> >> >> >> > my Wicket components (In those cases I have entities as
class
> >> > vars)?
> >> >> >> > And the @SpringBean will solve the serialization issue?
> >> >> >>
> >> >> >> you can use whatever works for you. salve is an alternative
:)
> >> >> >>
> >> >> >> > By just looking at Salve a bit it seems I could migrate to
> > Salve
> >> > in
> >> >> >> > two steps that way. And it might be a pretty smooth path to
> > take?
> >> > It
> >> >> >> > would mean that I inject 1000 entities for no good reason.
But
> > if
> >> > I
> >> >> >> > see a performance problem in doing so I could just migrate
to
> >> > Salve?
> >> >> >> > By smooth path I mean that I would have access to my DAO's
in
> > my
> >> >> >> > entities and would essentially only change the dependency
> >> >> > annotations
> >> >> >> > and setup Salve.
> >> >> >>
> >> >> >> as long as you do not use spring-specific injection rules you
> >> > should
> >> >> >> be fine. salve uses lookup by type primarily, but also does
have
> >> >> >> @SpringBeanId that can be used as a qualifier.
> >> >> >>
> >> >> >>
> >> >> >> > Of course, if Salve is production ready. Then could I throw
> > out
> >> >> > Wicket
> >> >> >> > IOC and the @SpringBean annotation and use Salve instead to
> > solve
> >> >> >> > serialization issues? In this case I would use Salve for my
> >> >> >> > presentation/Wicket -layer as well as dependency injection
in
> > my
> >> >> >> > entities and Spring as I already do for my service/business
> >> > -layer
> >> >> > and
> >> >> >> > my persistence/DTO -layer. Or would it be nicer to have
Salve
> >> > handle
> >> >> >> > dependencies in the last two layers as well?
> >> >> >>
> >> >> >> we use salve to inject across all layers. it gives you a
> > consistent
> >> >> >> approach to use and mock in unit tests. we have a spring
context
> >> > that
> >> >> >> contains true services - eg session factory, mail sender,
credit
> >> > card
> >> >> >> processor, etc. all of our domain model then uses salve to
> > inject
> >> >> >> these wherever needed.
> >> >> >>
> >> >> >> -igor
> >> >> >>
> >> >> >> > A lot of questions and text. Thanks for reading this far!
:-)
> >> >> >> >
> >> >> >> > Best regards, Kent
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> >> >> > <ig...@gmail.com>
> >> >> >> wrote:
> >> >> >> >> this is why i built salve.googlecode.com
> >> >> >> >>
> >> >> >> >> you can easily hook it into spring and have all your
objects
> >> > (doman
> >> >> >> >> objects or wicket components) injected via @Dependency
> > without
> >> >> >> >> worrying about serialization issues or eager injection -
eg
> > if
> >> > you
> >> >> >> >> load a result set of 1000 hibernate entities that need
> > injection
> >> >> > you
> >> >> >> >> dont want all those injected for no reason.
> >> >> >> >>
> >> >> >> >> -igor
> >> >> >> >>
> >> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> >> >> > <ke...@gmail.com>
> >> >> >> wrote:
> >> >> >> >>> Hi,
> >> >> >> >>>
> >> >> >> >>> Our current architecture:
> >> >> >> >>> ---
> >> >> >> >>>
> >> >> >> >>> We're currently using a 3-tier architecture
(presentation,
> >> >> >> >>> service/business and persistence) consisting of Wicket (+
a
> >> > little
> >> >> >> >>> Spring), Spring and Spring + Hibernate:
> >> >> >> >>>
> >> >> >> >>> Wicket:
> >> >> >> >>>
> >> >> >> >>> Does presentation, we're not inside a transaction /
> > Hibernate
> >> >> > session
> >> >> >> >>> so all used fields must be loaded by Spring. We call
Spring
> >> >> > singleton
> >> >> >> >>> beans and annotate those fields with @SpringBean.
> >> >> >> >>>
> >> >> >> >>> Spring:
> >> >> >> >>>
> >> >> >> >>> In the service layer we have Spring singleton beans,
> > services,
> >> >> > which
> >> >> >> >>> are called from the Wicket layer. We have our transaction
/
> >> >> > Hibernate
> >> >> >> >>> session boundary at this layer. We call DAO's from this
> > layer.
> >> >> >> >>>
> >> >> >> >>> Spring + Hibernate:
> >> >> >> >>>
> >> >> >> >>> Our DAO's are Spring singleton beans which performs
database
> >> >> >> >>> operations using HibernateTemplate.
> >> >> >> >>>
> >> >> >> >>> And common to all the layers are our entities. We use the
> >> > @Entity
> >> >> >> >>> annotation on them (not XML), from the Wicket layer we
just
> > use
> >> >> > the
> >> >> >> >>> accessor methods making sure that the relevant fields are
> >> > loaded
> >> >> > (as
> >> >> >> >>> we would get an exception if they were Lazy and not yet
> >> > loaded).
> >> >> > Our
> >> >> >> >>> entities are stupid, they lack logic and are used mostly
> > like a
> >> >> > struct
> >> >> >> >>> in C/C++.
> >> >> >> >>>
> >> >> >> >>> I think the general pattern is pretty common for Java EE
and
> >> >> > Spring
> >> >> >> >>> based web applications (feel free to disagree!). Yet it's
> >> >> > classified
> >> >> >> >>> as an anti-pattern by Martin Fowler as we are using
mostly
> >> >> > procedural
> >> >> >> >>> programming and have an anemic domain model (
> >> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >> >> >> >>>
> >> >> >> >>> What I would like:
> >> >> >> >>> ---
> >> >> >> >>>
> >> >> >> >>> I would like to use a more OOP approach and have logic in
> > our
> >> >> > current
> >> >> >> >>> entities, creating a rich domain model. For that to work
in
> > all
> >> >> > cases
> >> >> >> >>> they need to be able to load and save data. I would still
> > use a
> >> >> > Spring
> >> >> >> >>> singleton bean's for different services. But instead of
> >> > changing
> >> >> > the
> >> >> >> >>> entities like structs they would be rich objects capable
of
> >> >> > chaning
> >> >> >> >>> themself's and other objects.
> >> >> >> >>>
> >> >> >> >>> I found this article very interesting:
> >> >> >> >>>
> > http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >> >> >> >>>
> >> >> >> >>> But how would something like that work with Wicket? Could
I
> >> > just
> >> >> > use
> >> >> >> >>> @SpringBean like I'm currently doing but use it on both
> >> > "entities"
> >> >> > and
> >> >> >> >>> Spring singleton services?
> >> >> >> >>>
> >> >> >> >>> For me this has a purely practical benefit, as I could
use
> > some
> >> >> >> >>> inheritance in the domain object model to create
different
> >> >> > variations
> >> >> >> >>> of logic and not just data. Wicket feels quite agile and
> > nice
> >> > to
> >> >> > work
> >> >> >> >>> with, but I still feel that the current architecture is a
> > bit
> >> >> > stale
> >> >> >> >>> and seldom supports elegant OO solutions (that said, of
> > course
> >> >> > things
> >> >> >> >>> can still be solved elegantly, I just think it would be
> > easier
> >> > if
> >> >> > I
> >> >> >> >>> could do it in a more OO oriented way).
> >> >> >> >>>
> >> >> >> >>> Comments? What are the pros and cons of this kind of
> >> > architecture?
> >> >> >> >>>
> >> >> >> >>> All comments are greatly appreciated!
> >> >> >> >>>
> >> >> >> >>> Best regards, Kent
> >> >> >> >>>
> >> >> >> >>>
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >>> To unsubscribe, e-mail:
users-unsubscribe@wicket.apache.org
> >> >> >> >>> For additional commands, e-mail:
> > users-help@wicket.apache.org
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail:
users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail:
users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail:
users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >
> >
---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >> No virus found in this incoming message.
> >> >> >> Checked by AVG - www.avg.com
> >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
> > Date:
> >> >> > 05/28/09
> >> >> >> 18:09:00
> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >> No virus found in this incoming message.
> >> >> Checked by AVG - www.avg.com
> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
Date:
> >> > 05/28/09
> >> >> 18:09:00
> >> >
> >> >
> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> > 05/28/09
> >> 18:09:00
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

to keep memory overhread low only the last visisted page is stored in
http session. the rest of the pages are spooled to disk for long-term
storage in case the user uses the back button, and are cleaned up on
session expiration.

-igor

On Thu, May 28, 2009 at 6:54 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> When you say "offline storage" do you mean that the user has chosen to
> save pages for future offline reference or do you mean a more
> 'automated' process that wicket performs when system memory becomes too
> low?
>
> Chris
>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> Sent: Friday, 29 May 2009 11:43 AM
>> To: users@wicket.apache.org
>> Subject: Re: Anemic domain model and are @SpringBean's compatible with
> the
>> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>>
>> well, this is why salve removes the dependency field to at least help
>> with those.
>>
>> other then that you can use a loadabledetachablemodel to release the
>> reference when the page is not used.
>>
>> -igor
>>
>> On Thu, May 28, 2009 at 6:40 PM, Chris Colman
>> <ch...@stepaheadsoftware.com> wrote:
>> > Is that controllable?
>> >
>> > What if I have complex object models referenced from wicket UI
>> > components that I don't want (can't reasonably with Java's non
> optimal
>> > serialization) serialized?
>> >
>> > If we're serializing for offline storage aren't we going to require
> the
>> > underlying model objects to get serialized as well?
>> >
>> >> -----Original Message-----
>> >> serialization in the context when you need to serialize the object
> -
>> >> eg wicket serializes its pages for offline storage, etc.
>> >>
>> >> -igor
>> >>
>> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
>> >> <ch...@stepaheadsoftware.com> wrote:
>> >> > Another extremely light weight IoC with ORM wrapping (JDO and
>> > Hibernate)
>> >> > is exPOJO at http://www.expojo.com
>> >> >
>> >> > No need for old fashioned DAOs etc., just POJOs being persisted
>> >> > transparently the way they should be.
>> >> >
>> >> > In terms of serialization:
>> >> >
>> >> > Is that for the purpose of scaling in a cluster environment? I
> vote
>> > for
>> >> > 'session affinity' every time - it's almost necessary when you
> have
>> >> > anything more sophisticated than an anemic domain model. Do you
>> > really
>> >> > want to be shifting complex object models from server to server
> via
>> >> > serialization?
>> >> >
>> >> > If it's not for a cluster environment but for a single server to
>> > allow
>> >> > stale sessions to be swapped out then let the garbage collection
>> > clean
>> >> > out the ORM's object cache instead.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> >> >> Sent: Friday, 29 May 2009 3:38 AM
>> >> >> To: users@wicket.apache.org
>> >> >> Subject: Re: Anemic domain model and are @SpringBean's
> compatible
>> > with
>> >> > the
>> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>> >> >>
>> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
>> >> > <ke...@gmail.com>
>> >> >> wrote:
>> >> >> > Nice! I think Salve looks great! And it solves more than this
>> >> > problem,
>> >> >> > I like the design by contract module too as it allows me to
>> > validate
>> >> >> > parameters in a bit more declarative way.
>> >> >> >
>> >> >> > Do you think Salve is ready to be used in production? I'm a
> bit
>> >> >> > concerned by "Although already usable, Salve is still in its
>> >> > infancy.
>> >> >> > Not all features have been implemented and not all problems
>> > worked
>> >> >> > out.". I only see one open issue and it doesn't seem too major
>> > for
>> >> > me
>> >> >> > to pick it up.
>> >> >>
>> >> >> we have been using it in production for a while without any
>> > problems.
>> >> >> i just need to find the time to update the website text :)
>> >> >>
>> >> >> > If I'm not mistaken Salve may be used (for lots of things, but
>> > one
>> >> > is)
>> >> >> > to solve serialization issues with Spring beans in Wicket
>> >> > components?
>> >> >> > But isn't that the same issue that the Wicket IOC and it's
>> >> > @SpringBean
>> >> >> > annotation solves?
>> >> >>
>> >> >> wicket ioc can only take it so far. because it has to generate a
>> > proxy
>> >> >> there are limitations to what classes can be proxies - eg no
> final
>> >> >> methods, default constructor, etc. salve doesnt use a proxy so
> it
>> >> >> doesnt have any problems.
>> >> >>
>> >> >> although small, wicket ioc does have an overhead of having to
>> >> >> serialize the proxy with the componnet. since salve removes the
>> > field
>> >> >> it has no such overhead, this is more important when you are
>> > returning
>> >> >> large resultsets of entities that use dependencies.
>> >> >>
>> >> >> > If that's the case: Could I use Spring to inject my entities
> with
>> >> >> > DAO's for now, and use the @SpringBean annotation on those as
>> > well
>> >> > in
>> >> >> > my Wicket components (In those cases I have entities as class
>> > vars)?
>> >> >> > And the @SpringBean will solve the serialization issue?
>> >> >>
>> >> >> you can use whatever works for you. salve is an alternative :)
>> >> >>
>> >> >> > By just looking at Salve a bit it seems I could migrate to
> Salve
>> > in
>> >> >> > two steps that way. And it might be a pretty smooth path to
> take?
>> > It
>> >> >> > would mean that I inject 1000 entities for no good reason. But
> if
>> > I
>> >> >> > see a performance problem in doing so I could just migrate to
>> > Salve?
>> >> >> > By smooth path I mean that I would have access to my DAO's in
> my
>> >> >> > entities and would essentially only change the dependency
>> >> > annotations
>> >> >> > and setup Salve.
>> >> >>
>> >> >> as long as you do not use spring-specific injection rules you
>> > should
>> >> >> be fine. salve uses lookup by type primarily, but also does have
>> >> >> @SpringBeanId that can be used as a qualifier.
>> >> >>
>> >> >>
>> >> >> > Of course, if Salve is production ready. Then could I throw
> out
>> >> > Wicket
>> >> >> > IOC and the @SpringBean annotation and use Salve instead to
> solve
>> >> >> > serialization issues? In this case I would use Salve for my
>> >> >> > presentation/Wicket -layer as well as dependency injection in
> my
>> >> >> > entities and Spring as I already do for my service/business
>> > -layer
>> >> > and
>> >> >> > my persistence/DTO -layer. Or would it be nicer to have Salve
>> > handle
>> >> >> > dependencies in the last two layers as well?
>> >> >>
>> >> >> we use salve to inject across all layers. it gives you a
> consistent
>> >> >> approach to use and mock in unit tests. we have a spring context
>> > that
>> >> >> contains true services - eg session factory, mail sender, credit
>> > card
>> >> >> processor, etc. all of our domain model then uses salve to
> inject
>> >> >> these wherever needed.
>> >> >>
>> >> >> -igor
>> >> >>
>> >> >> > A lot of questions and text. Thanks for reading this far! :-)
>> >> >> >
>> >> >> > Best regards, Kent
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
>> >> > <ig...@gmail.com>
>> >> >> wrote:
>> >> >> >> this is why i built salve.googlecode.com
>> >> >> >>
>> >> >> >> you can easily hook it into spring and have all your objects
>> > (doman
>> >> >> >> objects or wicket components) injected via @Dependency
> without
>> >> >> >> worrying about serialization issues or eager injection - eg
> if
>> > you
>> >> >> >> load a result set of 1000 hibernate entities that need
> injection
>> >> > you
>> >> >> >> dont want all those injected for no reason.
>> >> >> >>
>> >> >> >> -igor
>> >> >> >>
>> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
>> >> > <ke...@gmail.com>
>> >> >> wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> Our current architecture:
>> >> >> >>> ---
>> >> >> >>>
>> >> >> >>> We're currently using a 3-tier architecture (presentation,
>> >> >> >>> service/business and persistence) consisting of Wicket (+ a
>> > little
>> >> >> >>> Spring), Spring and Spring + Hibernate:
>> >> >> >>>
>> >> >> >>> Wicket:
>> >> >> >>>
>> >> >> >>> Does presentation, we're not inside a transaction /
> Hibernate
>> >> > session
>> >> >> >>> so all used fields must be loaded by Spring. We call Spring
>> >> > singleton
>> >> >> >>> beans and annotate those fields with @SpringBean.
>> >> >> >>>
>> >> >> >>> Spring:
>> >> >> >>>
>> >> >> >>> In the service layer we have Spring singleton beans,
> services,
>> >> > which
>> >> >> >>> are called from the Wicket layer. We have our transaction /
>> >> > Hibernate
>> >> >> >>> session boundary at this layer. We call DAO's from this
> layer.
>> >> >> >>>
>> >> >> >>> Spring + Hibernate:
>> >> >> >>>
>> >> >> >>> Our DAO's are Spring singleton beans which performs database
>> >> >> >>> operations using HibernateTemplate.
>> >> >> >>>
>> >> >> >>> And common to all the layers are our entities. We use the
>> > @Entity
>> >> >> >>> annotation on them (not XML), from the Wicket layer we just
> use
>> >> > the
>> >> >> >>> accessor methods making sure that the relevant fields are
>> > loaded
>> >> > (as
>> >> >> >>> we would get an exception if they were Lazy and not yet
>> > loaded).
>> >> > Our
>> >> >> >>> entities are stupid, they lack logic and are used mostly
> like a
>> >> > struct
>> >> >> >>> in C/C++.
>> >> >> >>>
>> >> >> >>> I think the general pattern is pretty common for Java EE and
>> >> > Spring
>> >> >> >>> based web applications (feel free to disagree!). Yet it's
>> >> > classified
>> >> >> >>> as an anti-pattern by Martin Fowler as we are using mostly
>> >> > procedural
>> >> >> >>> programming and have an anemic domain model (
>> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>> >> >> >>>
>> >> >> >>> What I would like:
>> >> >> >>> ---
>> >> >> >>>
>> >> >> >>> I would like to use a more OOP approach and have logic in
> our
>> >> > current
>> >> >> >>> entities, creating a rich domain model. For that to work in
> all
>> >> > cases
>> >> >> >>> they need to be able to load and save data. I would still
> use a
>> >> > Spring
>> >> >> >>> singleton bean's for different services. But instead of
>> > changing
>> >> > the
>> >> >> >>> entities like structs they would be rich objects capable of
>> >> > chaning
>> >> >> >>> themself's and other objects.
>> >> >> >>>
>> >> >> >>> I found this article very interesting:
>> >> >> >>>
> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>> >> >> >>>
>> >> >> >>> But how would something like that work with Wicket? Could I
>> > just
>> >> > use
>> >> >> >>> @SpringBean like I'm currently doing but use it on both
>> > "entities"
>> >> > and
>> >> >> >>> Spring singleton services?
>> >> >> >>>
>> >> >> >>> For me this has a purely practical benefit, as I could use
> some
>> >> >> >>> inheritance in the domain object model to create different
>> >> > variations
>> >> >> >>> of logic and not just data. Wicket feels quite agile and
> nice
>> > to
>> >> > work
>> >> >> >>> with, but I still feel that the current architecture is a
> bit
>> >> > stale
>> >> >> >>> and seldom supports elegant OO solutions (that said, of
> course
>> >> > things
>> >> >> >>> can still be solved elegantly, I just think it would be
> easier
>> > if
>> >> > I
>> >> >> >>> could do it in a more OO oriented way).
>> >> >> >>>
>> >> >> >>> Comments? What are the pros and cons of this kind of
>> > architecture?
>> >> >> >>>
>> >> >> >>> All comments are greatly appreciated!
>> >> >> >>>
>> >> >> >>> Best regards, Kent
>> >> >> >>>
>> >> >> >>>
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >>> For additional commands, e-mail:
> users-help@wicket.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >
> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >> No virus found in this incoming message.
>> >> >> Checked by AVG - www.avg.com
>> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
> Date:
>> >> > 05/28/09
>> >> >> 18:09:00
>> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >> No virus found in this incoming message.
>> >> Checked by AVG - www.avg.com
>> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
>> > 05/28/09
>> >> 18:09:00
>> >
>> >
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> 05/28/09
>> 18:09:00
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

RE: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Chris Colman <ch...@stepaheadsoftware.com>]

When you say "offline storage" do you mean that the user has chosen to
save pages for future offline reference or do you mean a more
'automated' process that wicket performs when system memory becomes too
low?

Chris

> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> Sent: Friday, 29 May 2009 11:43 AM
> To: users@wicket.apache.org
> Subject: Re: Anemic domain model and are @SpringBean's compatible with
the
> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> 
> well, this is why salve removes the dependency field to at least help
> with those.
> 
> other then that you can use a loadabledetachablemodel to release the
> reference when the page is not used.
> 
> -igor
> 
> On Thu, May 28, 2009 at 6:40 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
> > Is that controllable?
> >
> > What if I have complex object models referenced from wicket UI
> > components that I don't want (can't reasonably with Java's non
optimal
> > serialization) serialized?
> >
> > If we're serializing for offline storage aren't we going to require
the
> > underlying model objects to get serialized as well?
> >
> >> -----Original Message-----
> >> serialization in the context when you need to serialize the object
-
> >> eg wicket serializes its pages for offline storage, etc.
> >>
> >> -igor
> >>
> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
> >> <ch...@stepaheadsoftware.com> wrote:
> >> > Another extremely light weight IoC with ORM wrapping (JDO and
> > Hibernate)
> >> > is exPOJO at http://www.expojo.com
> >> >
> >> > No need for old fashioned DAOs etc., just POJOs being persisted
> >> > transparently the way they should be.
> >> >
> >> > In terms of serialization:
> >> >
> >> > Is that for the purpose of scaling in a cluster environment? I
vote
> > for
> >> > 'session affinity' every time - it's almost necessary when you
have
> >> > anything more sophisticated than an anemic domain model. Do you
> > really
> >> > want to be shifting complex object models from server to server
via
> >> > serialization?
> >> >
> >> > If it's not for a cluster environment but for a single server to
> > allow
> >> > stale sessions to be swapped out then let the garbage collection
> > clean
> >> > out the ORM's object cache instead.
> >> >
> >> >> -----Original Message-----
> >> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> >> Sent: Friday, 29 May 2009 3:38 AM
> >> >> To: users@wicket.apache.org
> >> >> Subject: Re: Anemic domain model and are @SpringBean's
compatible
> > with
> >> > the
> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >> >>
> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> >> > <ke...@gmail.com>
> >> >> wrote:
> >> >> > Nice! I think Salve looks great! And it solves more than this
> >> > problem,
> >> >> > I like the design by contract module too as it allows me to
> > validate
> >> >> > parameters in a bit more declarative way.
> >> >> >
> >> >> > Do you think Salve is ready to be used in production? I'm a
bit
> >> >> > concerned by "Although already usable, Salve is still in its
> >> > infancy.
> >> >> > Not all features have been implemented and not all problems
> > worked
> >> >> > out.". I only see one open issue and it doesn't seem too major
> > for
> >> > me
> >> >> > to pick it up.
> >> >>
> >> >> we have been using it in production for a while without any
> > problems.
> >> >> i just need to find the time to update the website text :)
> >> >>
> >> >> > If I'm not mistaken Salve may be used (for lots of things, but
> > one
> >> > is)
> >> >> > to solve serialization issues with Spring beans in Wicket
> >> > components?
> >> >> > But isn't that the same issue that the Wicket IOC and it's
> >> > @SpringBean
> >> >> > annotation solves?
> >> >>
> >> >> wicket ioc can only take it so far. because it has to generate a
> > proxy
> >> >> there are limitations to what classes can be proxies - eg no
final
> >> >> methods, default constructor, etc. salve doesnt use a proxy so
it
> >> >> doesnt have any problems.
> >> >>
> >> >> although small, wicket ioc does have an overhead of having to
> >> >> serialize the proxy with the componnet. since salve removes the
> > field
> >> >> it has no such overhead, this is more important when you are
> > returning
> >> >> large resultsets of entities that use dependencies.
> >> >>
> >> >> > If that's the case: Could I use Spring to inject my entities
with
> >> >> > DAO's for now, and use the @SpringBean annotation on those as
> > well
> >> > in
> >> >> > my Wicket components (In those cases I have entities as class
> > vars)?
> >> >> > And the @SpringBean will solve the serialization issue?
> >> >>
> >> >> you can use whatever works for you. salve is an alternative :)
> >> >>
> >> >> > By just looking at Salve a bit it seems I could migrate to
Salve
> > in
> >> >> > two steps that way. And it might be a pretty smooth path to
take?
> > It
> >> >> > would mean that I inject 1000 entities for no good reason. But
if
> > I
> >> >> > see a performance problem in doing so I could just migrate to
> > Salve?
> >> >> > By smooth path I mean that I would have access to my DAO's in
my
> >> >> > entities and would essentially only change the dependency
> >> > annotations
> >> >> > and setup Salve.
> >> >>
> >> >> as long as you do not use spring-specific injection rules you
> > should
> >> >> be fine. salve uses lookup by type primarily, but also does have
> >> >> @SpringBeanId that can be used as a qualifier.
> >> >>
> >> >>
> >> >> > Of course, if Salve is production ready. Then could I throw
out
> >> > Wicket
> >> >> > IOC and the @SpringBean annotation and use Salve instead to
solve
> >> >> > serialization issues? In this case I would use Salve for my
> >> >> > presentation/Wicket -layer as well as dependency injection in
my
> >> >> > entities and Spring as I already do for my service/business
> > -layer
> >> > and
> >> >> > my persistence/DTO -layer. Or would it be nicer to have Salve
> > handle
> >> >> > dependencies in the last two layers as well?
> >> >>
> >> >> we use salve to inject across all layers. it gives you a
consistent
> >> >> approach to use and mock in unit tests. we have a spring context
> > that
> >> >> contains true services - eg session factory, mail sender, credit
> > card
> >> >> processor, etc. all of our domain model then uses salve to
inject
> >> >> these wherever needed.
> >> >>
> >> >> -igor
> >> >>
> >> >> > A lot of questions and text. Thanks for reading this far! :-)
> >> >> >
> >> >> > Best regards, Kent
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> >> > <ig...@gmail.com>
> >> >> wrote:
> >> >> >> this is why i built salve.googlecode.com
> >> >> >>
> >> >> >> you can easily hook it into spring and have all your objects
> > (doman
> >> >> >> objects or wicket components) injected via @Dependency
without
> >> >> >> worrying about serialization issues or eager injection - eg
if
> > you
> >> >> >> load a result set of 1000 hibernate entities that need
injection
> >> > you
> >> >> >> dont want all those injected for no reason.
> >> >> >>
> >> >> >> -igor
> >> >> >>
> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> >> > <ke...@gmail.com>
> >> >> wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> Our current architecture:
> >> >> >>> ---
> >> >> >>>
> >> >> >>> We're currently using a 3-tier architecture (presentation,
> >> >> >>> service/business and persistence) consisting of Wicket (+ a
> > little
> >> >> >>> Spring), Spring and Spring + Hibernate:
> >> >> >>>
> >> >> >>> Wicket:
> >> >> >>>
> >> >> >>> Does presentation, we're not inside a transaction /
Hibernate
> >> > session
> >> >> >>> so all used fields must be loaded by Spring. We call Spring
> >> > singleton
> >> >> >>> beans and annotate those fields with @SpringBean.
> >> >> >>>
> >> >> >>> Spring:
> >> >> >>>
> >> >> >>> In the service layer we have Spring singleton beans,
services,
> >> > which
> >> >> >>> are called from the Wicket layer. We have our transaction /
> >> > Hibernate
> >> >> >>> session boundary at this layer. We call DAO's from this
layer.
> >> >> >>>
> >> >> >>> Spring + Hibernate:
> >> >> >>>
> >> >> >>> Our DAO's are Spring singleton beans which performs database
> >> >> >>> operations using HibernateTemplate.
> >> >> >>>
> >> >> >>> And common to all the layers are our entities. We use the
> > @Entity
> >> >> >>> annotation on them (not XML), from the Wicket layer we just
use
> >> > the
> >> >> >>> accessor methods making sure that the relevant fields are
> > loaded
> >> > (as
> >> >> >>> we would get an exception if they were Lazy and not yet
> > loaded).
> >> > Our
> >> >> >>> entities are stupid, they lack logic and are used mostly
like a
> >> > struct
> >> >> >>> in C/C++.
> >> >> >>>
> >> >> >>> I think the general pattern is pretty common for Java EE and
> >> > Spring
> >> >> >>> based web applications (feel free to disagree!). Yet it's
> >> > classified
> >> >> >>> as an anti-pattern by Martin Fowler as we are using mostly
> >> > procedural
> >> >> >>> programming and have an anemic domain model (
> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >> >> >>>
> >> >> >>> What I would like:
> >> >> >>> ---
> >> >> >>>
> >> >> >>> I would like to use a more OOP approach and have logic in
our
> >> > current
> >> >> >>> entities, creating a rich domain model. For that to work in
all
> >> > cases
> >> >> >>> they need to be able to load and save data. I would still
use a
> >> > Spring
> >> >> >>> singleton bean's for different services. But instead of
> > changing
> >> > the
> >> >> >>> entities like structs they would be rich objects capable of
> >> > chaning
> >> >> >>> themself's and other objects.
> >> >> >>>
> >> >> >>> I found this article very interesting:
> >> >> >>>
http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >> >> >>>
> >> >> >>> But how would something like that work with Wicket? Could I
> > just
> >> > use
> >> >> >>> @SpringBean like I'm currently doing but use it on both
> > "entities"
> >> > and
> >> >> >>> Spring singleton services?
> >> >> >>>
> >> >> >>> For me this has a purely practical benefit, as I could use
some
> >> >> >>> inheritance in the domain object model to create different
> >> > variations
> >> >> >>> of logic and not just data. Wicket feels quite agile and
nice
> > to
> >> > work
> >> >> >>> with, but I still feel that the current architecture is a
bit
> >> > stale
> >> >> >>> and seldom supports elegant OO solutions (that said, of
course
> >> > things
> >> >> >>> can still be solved elegantly, I just think it would be
easier
> > if
> >> > I
> >> >> >>> could do it in a more OO oriented way).
> >> >> >>>
> >> >> >>> Comments? What are the pros and cons of this kind of
> > architecture?
> >> >> >>>
> >> >> >>> All comments are greatly appreciated!
> >> >> >>>
> >> >> >>> Best regards, Kent
> >> >> >>>
> >> >> >>>
> >> >
> >
---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >>> For additional commands, e-mail:
users-help@wicket.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >
> >
---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >
> >
---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >> No virus found in this incoming message.
> >> >> Checked by AVG - www.avg.com
> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release
Date:
> >> > 05/28/09
> >> >> 18:09:00
> >> >
> >> >
> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> > 05/28/09
> >> 18:09:00
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

well, this is why salve removes the dependency field to at least help
with those.

other then that you can use a loadabledetachablemodel to release the
reference when the page is not used.

-igor

On Thu, May 28, 2009 at 6:40 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> Is that controllable?
>
> What if I have complex object models referenced from wicket UI
> components that I don't want (can't reasonably with Java's non optimal
> serialization) serialized?
>
> If we're serializing for offline storage aren't we going to require the
> underlying model objects to get serialized as well?
>
>> -----Original Message-----
>> serialization in the context when you need to serialize the object -
>> eg wicket serializes its pages for offline storage, etc.
>>
>> -igor
>>
>> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
>> <ch...@stepaheadsoftware.com> wrote:
>> > Another extremely light weight IoC with ORM wrapping (JDO and
> Hibernate)
>> > is exPOJO at http://www.expojo.com
>> >
>> > No need for old fashioned DAOs etc., just POJOs being persisted
>> > transparently the way they should be.
>> >
>> > In terms of serialization:
>> >
>> > Is that for the purpose of scaling in a cluster environment? I vote
> for
>> > 'session affinity' every time - it's almost necessary when you have
>> > anything more sophisticated than an anemic domain model. Do you
> really
>> > want to be shifting complex object models from server to server via
>> > serialization?
>> >
>> > If it's not for a cluster environment but for a single server to
> allow
>> > stale sessions to be swapped out then let the garbage collection
> clean
>> > out the ORM's object cache instead.
>> >
>> >> -----Original Message-----
>> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> >> Sent: Friday, 29 May 2009 3:38 AM
>> >> To: users@wicket.apache.org
>> >> Subject: Re: Anemic domain model and are @SpringBean's compatible
> with
>> > the
>> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>> >>
>> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
>> > <ke...@gmail.com>
>> >> wrote:
>> >> > Nice! I think Salve looks great! And it solves more than this
>> > problem,
>> >> > I like the design by contract module too as it allows me to
> validate
>> >> > parameters in a bit more declarative way.
>> >> >
>> >> > Do you think Salve is ready to be used in production? I'm a bit
>> >> > concerned by "Although already usable, Salve is still in its
>> > infancy.
>> >> > Not all features have been implemented and not all problems
> worked
>> >> > out.". I only see one open issue and it doesn't seem too major
> for
>> > me
>> >> > to pick it up.
>> >>
>> >> we have been using it in production for a while without any
> problems.
>> >> i just need to find the time to update the website text :)
>> >>
>> >> > If I'm not mistaken Salve may be used (for lots of things, but
> one
>> > is)
>> >> > to solve serialization issues with Spring beans in Wicket
>> > components?
>> >> > But isn't that the same issue that the Wicket IOC and it's
>> > @SpringBean
>> >> > annotation solves?
>> >>
>> >> wicket ioc can only take it so far. because it has to generate a
> proxy
>> >> there are limitations to what classes can be proxies - eg no final
>> >> methods, default constructor, etc. salve doesnt use a proxy so it
>> >> doesnt have any problems.
>> >>
>> >> although small, wicket ioc does have an overhead of having to
>> >> serialize the proxy with the componnet. since salve removes the
> field
>> >> it has no such overhead, this is more important when you are
> returning
>> >> large resultsets of entities that use dependencies.
>> >>
>> >> > If that's the case: Could I use Spring to inject my entities with
>> >> > DAO's for now, and use the @SpringBean annotation on those as
> well
>> > in
>> >> > my Wicket components (In those cases I have entities as class
> vars)?
>> >> > And the @SpringBean will solve the serialization issue?
>> >>
>> >> you can use whatever works for you. salve is an alternative :)
>> >>
>> >> > By just looking at Salve a bit it seems I could migrate to Salve
> in
>> >> > two steps that way. And it might be a pretty smooth path to take?
> It
>> >> > would mean that I inject 1000 entities for no good reason. But if
> I
>> >> > see a performance problem in doing so I could just migrate to
> Salve?
>> >> > By smooth path I mean that I would have access to my DAO's in my
>> >> > entities and would essentially only change the dependency
>> > annotations
>> >> > and setup Salve.
>> >>
>> >> as long as you do not use spring-specific injection rules you
> should
>> >> be fine. salve uses lookup by type primarily, but also does have
>> >> @SpringBeanId that can be used as a qualifier.
>> >>
>> >>
>> >> > Of course, if Salve is production ready. Then could I throw out
>> > Wicket
>> >> > IOC and the @SpringBean annotation and use Salve instead to solve
>> >> > serialization issues? In this case I would use Salve for my
>> >> > presentation/Wicket -layer as well as dependency injection in my
>> >> > entities and Spring as I already do for my service/business
> -layer
>> > and
>> >> > my persistence/DTO -layer. Or would it be nicer to have Salve
> handle
>> >> > dependencies in the last two layers as well?
>> >>
>> >> we use salve to inject across all layers. it gives you a consistent
>> >> approach to use and mock in unit tests. we have a spring context
> that
>> >> contains true services - eg session factory, mail sender, credit
> card
>> >> processor, etc. all of our domain model then uses salve to inject
>> >> these wherever needed.
>> >>
>> >> -igor
>> >>
>> >> > A lot of questions and text. Thanks for reading this far! :-)
>> >> >
>> >> > Best regards, Kent
>> >> >
>> >> >
>> >> >
>> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
>> > <ig...@gmail.com>
>> >> wrote:
>> >> >> this is why i built salve.googlecode.com
>> >> >>
>> >> >> you can easily hook it into spring and have all your objects
> (doman
>> >> >> objects or wicket components) injected via @Dependency without
>> >> >> worrying about serialization issues or eager injection - eg if
> you
>> >> >> load a result set of 1000 hibernate entities that need injection
>> > you
>> >> >> dont want all those injected for no reason.
>> >> >>
>> >> >> -igor
>> >> >>
>> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
>> > <ke...@gmail.com>
>> >> wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> Our current architecture:
>> >> >>> ---
>> >> >>>
>> >> >>> We're currently using a 3-tier architecture (presentation,
>> >> >>> service/business and persistence) consisting of Wicket (+ a
> little
>> >> >>> Spring), Spring and Spring + Hibernate:
>> >> >>>
>> >> >>> Wicket:
>> >> >>>
>> >> >>> Does presentation, we're not inside a transaction / Hibernate
>> > session
>> >> >>> so all used fields must be loaded by Spring. We call Spring
>> > singleton
>> >> >>> beans and annotate those fields with @SpringBean.
>> >> >>>
>> >> >>> Spring:
>> >> >>>
>> >> >>> In the service layer we have Spring singleton beans, services,
>> > which
>> >> >>> are called from the Wicket layer. We have our transaction /
>> > Hibernate
>> >> >>> session boundary at this layer. We call DAO's from this layer.
>> >> >>>
>> >> >>> Spring + Hibernate:
>> >> >>>
>> >> >>> Our DAO's are Spring singleton beans which performs database
>> >> >>> operations using HibernateTemplate.
>> >> >>>
>> >> >>> And common to all the layers are our entities. We use the
> @Entity
>> >> >>> annotation on them (not XML), from the Wicket layer we just use
>> > the
>> >> >>> accessor methods making sure that the relevant fields are
> loaded
>> > (as
>> >> >>> we would get an exception if they were Lazy and not yet
> loaded).
>> > Our
>> >> >>> entities are stupid, they lack logic and are used mostly like a
>> > struct
>> >> >>> in C/C++.
>> >> >>>
>> >> >>> I think the general pattern is pretty common for Java EE and
>> > Spring
>> >> >>> based web applications (feel free to disagree!). Yet it's
>> > classified
>> >> >>> as an anti-pattern by Martin Fowler as we are using mostly
>> > procedural
>> >> >>> programming and have an anemic domain model (
>> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>> >> >>>
>> >> >>> What I would like:
>> >> >>> ---
>> >> >>>
>> >> >>> I would like to use a more OOP approach and have logic in our
>> > current
>> >> >>> entities, creating a rich domain model. For that to work in all
>> > cases
>> >> >>> they need to be able to load and save data. I would still use a
>> > Spring
>> >> >>> singleton bean's for different services. But instead of
> changing
>> > the
>> >> >>> entities like structs they would be rich objects capable of
>> > chaning
>> >> >>> themself's and other objects.
>> >> >>>
>> >> >>> I found this article very interesting:
>> >> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>> >> >>>
>> >> >>> But how would something like that work with Wicket? Could I
> just
>> > use
>> >> >>> @SpringBean like I'm currently doing but use it on both
> "entities"
>> > and
>> >> >>> Spring singleton services?
>> >> >>>
>> >> >>> For me this has a purely practical benefit, as I could use some
>> >> >>> inheritance in the domain object model to create different
>> > variations
>> >> >>> of logic and not just data. Wicket feels quite agile and nice
> to
>> > work
>> >> >>> with, but I still feel that the current architecture is a bit
>> > stale
>> >> >>> and seldom supports elegant OO solutions (that said, of course
>> > things
>> >> >>> can still be solved elegantly, I just think it would be easier
> if
>> > I
>> >> >>> could do it in a more OO oriented way).
>> >> >>>
>> >> >>> Comments? What are the pros and cons of this kind of
> architecture?
>> >> >>>
>> >> >>> All comments are greatly appreciated!
>> >> >>>
>> >> >>> Best regards, Kent
>> >> >>>
>> >> >>>
>> >
> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >
> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >
> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >> No virus found in this incoming message.
>> >> Checked by AVG - www.avg.com
>> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
>> > 05/28/09
>> >> 18:09:00
>> >
>> >
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> 05/28/09
>> 18:09:00
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

RE: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Chris Colman <ch...@stepaheadsoftware.com>]

Is that controllable?

What if I have complex object models referenced from wicket UI
components that I don't want (can't reasonably with Java's non optimal
serialization) serialized?

If we're serializing for offline storage aren't we going to require the
underlying model objects to get serialized as well?

> -----Original Message-----
> serialization in the context when you need to serialize the object -
> eg wicket serializes its pages for offline storage, etc.
> 
> -igor
> 
> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
> > Another extremely light weight IoC with ORM wrapping (JDO and
Hibernate)
> > is exPOJO at http://www.expojo.com
> >
> > No need for old fashioned DAOs etc., just POJOs being persisted
> > transparently the way they should be.
> >
> > In terms of serialization:
> >
> > Is that for the purpose of scaling in a cluster environment? I vote
for
> > 'session affinity' every time - it's almost necessary when you have
> > anything more sophisticated than an anemic domain model. Do you
really
> > want to be shifting complex object models from server to server via
> > serialization?
> >
> > If it's not for a cluster environment but for a single server to
allow
> > stale sessions to be swapped out then let the garbage collection
clean
> > out the ORM's object cache instead.
> >
> >> -----Original Message-----
> >> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> >> Sent: Friday, 29 May 2009 3:38 AM
> >> To: users@wicket.apache.org
> >> Subject: Re: Anemic domain model and are @SpringBean's compatible
with
> > the
> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >>
> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> > <ke...@gmail.com>
> >> wrote:
> >> > Nice! I think Salve looks great! And it solves more than this
> > problem,
> >> > I like the design by contract module too as it allows me to
validate
> >> > parameters in a bit more declarative way.
> >> >
> >> > Do you think Salve is ready to be used in production? I'm a bit
> >> > concerned by "Although already usable, Salve is still in its
> > infancy.
> >> > Not all features have been implemented and not all problems
worked
> >> > out.". I only see one open issue and it doesn't seem too major
for
> > me
> >> > to pick it up.
> >>
> >> we have been using it in production for a while without any
problems.
> >> i just need to find the time to update the website text :)
> >>
> >> > If I'm not mistaken Salve may be used (for lots of things, but
one
> > is)
> >> > to solve serialization issues with Spring beans in Wicket
> > components?
> >> > But isn't that the same issue that the Wicket IOC and it's
> > @SpringBean
> >> > annotation solves?
> >>
> >> wicket ioc can only take it so far. because it has to generate a
proxy
> >> there are limitations to what classes can be proxies - eg no final
> >> methods, default constructor, etc. salve doesnt use a proxy so it
> >> doesnt have any problems.
> >>
> >> although small, wicket ioc does have an overhead of having to
> >> serialize the proxy with the componnet. since salve removes the
field
> >> it has no such overhead, this is more important when you are
returning
> >> large resultsets of entities that use dependencies.
> >>
> >> > If that's the case: Could I use Spring to inject my entities with
> >> > DAO's for now, and use the @SpringBean annotation on those as
well
> > in
> >> > my Wicket components (In those cases I have entities as class
vars)?
> >> > And the @SpringBean will solve the serialization issue?
> >>
> >> you can use whatever works for you. salve is an alternative :)
> >>
> >> > By just looking at Salve a bit it seems I could migrate to Salve
in
> >> > two steps that way. And it might be a pretty smooth path to take?
It
> >> > would mean that I inject 1000 entities for no good reason. But if
I
> >> > see a performance problem in doing so I could just migrate to
Salve?
> >> > By smooth path I mean that I would have access to my DAO's in my
> >> > entities and would essentially only change the dependency
> > annotations
> >> > and setup Salve.
> >>
> >> as long as you do not use spring-specific injection rules you
should
> >> be fine. salve uses lookup by type primarily, but also does have
> >> @SpringBeanId that can be used as a qualifier.
> >>
> >>
> >> > Of course, if Salve is production ready. Then could I throw out
> > Wicket
> >> > IOC and the @SpringBean annotation and use Salve instead to solve
> >> > serialization issues? In this case I would use Salve for my
> >> > presentation/Wicket -layer as well as dependency injection in my
> >> > entities and Spring as I already do for my service/business
-layer
> > and
> >> > my persistence/DTO -layer. Or would it be nicer to have Salve
handle
> >> > dependencies in the last two layers as well?
> >>
> >> we use salve to inject across all layers. it gives you a consistent
> >> approach to use and mock in unit tests. we have a spring context
that
> >> contains true services - eg session factory, mail sender, credit
card
> >> processor, etc. all of our domain model then uses salve to inject
> >> these wherever needed.
> >>
> >> -igor
> >>
> >> > A lot of questions and text. Thanks for reading this far! :-)
> >> >
> >> > Best regards, Kent
> >> >
> >> >
> >> >
> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> > <ig...@gmail.com>
> >> wrote:
> >> >> this is why i built salve.googlecode.com
> >> >>
> >> >> you can easily hook it into spring and have all your objects
(doman
> >> >> objects or wicket components) injected via @Dependency without
> >> >> worrying about serialization issues or eager injection - eg if
you
> >> >> load a result set of 1000 hibernate entities that need injection
> > you
> >> >> dont want all those injected for no reason.
> >> >>
> >> >> -igor
> >> >>
> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> > <ke...@gmail.com>
> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> Our current architecture:
> >> >>> ---
> >> >>>
> >> >>> We're currently using a 3-tier architecture (presentation,
> >> >>> service/business and persistence) consisting of Wicket (+ a
little
> >> >>> Spring), Spring and Spring + Hibernate:
> >> >>>
> >> >>> Wicket:
> >> >>>
> >> >>> Does presentation, we're not inside a transaction / Hibernate
> > session
> >> >>> so all used fields must be loaded by Spring. We call Spring
> > singleton
> >> >>> beans and annotate those fields with @SpringBean.
> >> >>>
> >> >>> Spring:
> >> >>>
> >> >>> In the service layer we have Spring singleton beans, services,
> > which
> >> >>> are called from the Wicket layer. We have our transaction /
> > Hibernate
> >> >>> session boundary at this layer. We call DAO's from this layer.
> >> >>>
> >> >>> Spring + Hibernate:
> >> >>>
> >> >>> Our DAO's are Spring singleton beans which performs database
> >> >>> operations using HibernateTemplate.
> >> >>>
> >> >>> And common to all the layers are our entities. We use the
@Entity
> >> >>> annotation on them (not XML), from the Wicket layer we just use
> > the
> >> >>> accessor methods making sure that the relevant fields are
loaded
> > (as
> >> >>> we would get an exception if they were Lazy and not yet
loaded).
> > Our
> >> >>> entities are stupid, they lack logic and are used mostly like a
> > struct
> >> >>> in C/C++.
> >> >>>
> >> >>> I think the general pattern is pretty common for Java EE and
> > Spring
> >> >>> based web applications (feel free to disagree!). Yet it's
> > classified
> >> >>> as an anti-pattern by Martin Fowler as we are using mostly
> > procedural
> >> >>> programming and have an anemic domain model (
> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >> >>>
> >> >>> What I would like:
> >> >>> ---
> >> >>>
> >> >>> I would like to use a more OOP approach and have logic in our
> > current
> >> >>> entities, creating a rich domain model. For that to work in all
> > cases
> >> >>> they need to be able to load and save data. I would still use a
> > Spring
> >> >>> singleton bean's for different services. But instead of
changing
> > the
> >> >>> entities like structs they would be rich objects capable of
> > chaning
> >> >>> themself's and other objects.
> >> >>>
> >> >>> I found this article very interesting:
> >> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >> >>>
> >> >>> But how would something like that work with Wicket? Could I
just
> > use
> >> >>> @SpringBean like I'm currently doing but use it on both
"entities"
> > and
> >> >>> Spring singleton services?
> >> >>>
> >> >>> For me this has a purely practical benefit, as I could use some
> >> >>> inheritance in the domain object model to create different
> > variations
> >> >>> of logic and not just data. Wicket feels quite agile and nice
to
> > work
> >> >>> with, but I still feel that the current architecture is a bit
> > stale
> >> >>> and seldom supports elegant OO solutions (that said, of course
> > things
> >> >>> can still be solved elegantly, I just think it would be easier
if
> > I
> >> >>> could do it in a more OO oriented way).
> >> >>>
> >> >>> Comments? What are the pros and cons of this kind of
architecture?
> >> >>>
> >> >>> All comments are greatly appreciated!
> >> >>>
> >> >>> Best regards, Kent
> >> >>>
> >> >>>
> >
---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> > 05/28/09
> >> 18:09:00
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

serialization in the context when you need to serialize the object -
eg wicket serializes its pages for offline storage, etc.

-igor

On Thu, May 28, 2009 at 5:51 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> Another extremely light weight IoC with ORM wrapping (JDO and Hibernate)
> is exPOJO at http://www.expojo.com
>
> No need for old fashioned DAOs etc., just POJOs being persisted
> transparently the way they should be.
>
> In terms of serialization:
>
> Is that for the purpose of scaling in a cluster environment? I vote for
> 'session affinity' every time - it's almost necessary when you have
> anything more sophisticated than an anemic domain model. Do you really
> want to be shifting complex object models from server to server via
> serialization?
>
> If it's not for a cluster environment but for a single server to allow
> stale sessions to be swapped out then let the garbage collection clean
> out the ORM's object cache instead.
>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
>> Sent: Friday, 29 May 2009 3:38 AM
>> To: users@wicket.apache.org
>> Subject: Re: Anemic domain model and are @SpringBean's compatible with
> the
>> solution in "Spring 2.0 vs. the Anemic Domain Model"?
>>
>> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> <ke...@gmail.com>
>> wrote:
>> > Nice! I think Salve looks great! And it solves more than this
> problem,
>> > I like the design by contract module too as it allows me to validate
>> > parameters in a bit more declarative way.
>> >
>> > Do you think Salve is ready to be used in production? I'm a bit
>> > concerned by "Although already usable, Salve is still in its
> infancy.
>> > Not all features have been implemented and not all problems worked
>> > out.". I only see one open issue and it doesn't seem too major for
> me
>> > to pick it up.
>>
>> we have been using it in production for a while without any problems.
>> i just need to find the time to update the website text :)
>>
>> > If I'm not mistaken Salve may be used (for lots of things, but one
> is)
>> > to solve serialization issues with Spring beans in Wicket
> components?
>> > But isn't that the same issue that the Wicket IOC and it's
> @SpringBean
>> > annotation solves?
>>
>> wicket ioc can only take it so far. because it has to generate a proxy
>> there are limitations to what classes can be proxies - eg no final
>> methods, default constructor, etc. salve doesnt use a proxy so it
>> doesnt have any problems.
>>
>> although small, wicket ioc does have an overhead of having to
>> serialize the proxy with the componnet. since salve removes the field
>> it has no such overhead, this is more important when you are returning
>> large resultsets of entities that use dependencies.
>>
>> > If that's the case: Could I use Spring to inject my entities with
>> > DAO's for now, and use the @SpringBean annotation on those as well
> in
>> > my Wicket components (In those cases I have entities as class vars)?
>> > And the @SpringBean will solve the serialization issue?
>>
>> you can use whatever works for you. salve is an alternative :)
>>
>> > By just looking at Salve a bit it seems I could migrate to Salve in
>> > two steps that way. And it might be a pretty smooth path to take? It
>> > would mean that I inject 1000 entities for no good reason. But if I
>> > see a performance problem in doing so I could just migrate to Salve?
>> > By smooth path I mean that I would have access to my DAO's in my
>> > entities and would essentially only change the dependency
> annotations
>> > and setup Salve.
>>
>> as long as you do not use spring-specific injection rules you should
>> be fine. salve uses lookup by type primarily, but also does have
>> @SpringBeanId that can be used as a qualifier.
>>
>>
>> > Of course, if Salve is production ready. Then could I throw out
> Wicket
>> > IOC and the @SpringBean annotation and use Salve instead to solve
>> > serialization issues? In this case I would use Salve for my
>> > presentation/Wicket -layer as well as dependency injection in my
>> > entities and Spring as I already do for my service/business -layer
> and
>> > my persistence/DTO -layer. Or would it be nicer to have Salve handle
>> > dependencies in the last two layers as well?
>>
>> we use salve to inject across all layers. it gives you a consistent
>> approach to use and mock in unit tests. we have a spring context that
>> contains true services - eg session factory, mail sender, credit card
>> processor, etc. all of our domain model then uses salve to inject
>> these wherever needed.
>>
>> -igor
>>
>> > A lot of questions and text. Thanks for reading this far! :-)
>> >
>> > Best regards, Kent
>> >
>> >
>> >
>> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> <ig...@gmail.com>
>> wrote:
>> >> this is why i built salve.googlecode.com
>> >>
>> >> you can easily hook it into spring and have all your objects (doman
>> >> objects or wicket components) injected via @Dependency without
>> >> worrying about serialization issues or eager injection - eg if you
>> >> load a result set of 1000 hibernate entities that need injection
> you
>> >> dont want all those injected for no reason.
>> >>
>> >> -igor
>> >>
>> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> <ke...@gmail.com>
>> wrote:
>> >>> Hi,
>> >>>
>> >>> Our current architecture:
>> >>> ---
>> >>>
>> >>> We're currently using a 3-tier architecture (presentation,
>> >>> service/business and persistence) consisting of Wicket (+ a little
>> >>> Spring), Spring and Spring + Hibernate:
>> >>>
>> >>> Wicket:
>> >>>
>> >>> Does presentation, we're not inside a transaction / Hibernate
> session
>> >>> so all used fields must be loaded by Spring. We call Spring
> singleton
>> >>> beans and annotate those fields with @SpringBean.
>> >>>
>> >>> Spring:
>> >>>
>> >>> In the service layer we have Spring singleton beans, services,
> which
>> >>> are called from the Wicket layer. We have our transaction /
> Hibernate
>> >>> session boundary at this layer. We call DAO's from this layer.
>> >>>
>> >>> Spring + Hibernate:
>> >>>
>> >>> Our DAO's are Spring singleton beans which performs database
>> >>> operations using HibernateTemplate.
>> >>>
>> >>> And common to all the layers are our entities. We use the @Entity
>> >>> annotation on them (not XML), from the Wicket layer we just use
> the
>> >>> accessor methods making sure that the relevant fields are loaded
> (as
>> >>> we would get an exception if they were Lazy and not yet loaded).
> Our
>> >>> entities are stupid, they lack logic and are used mostly like a
> struct
>> >>> in C/C++.
>> >>>
>> >>> I think the general pattern is pretty common for Java EE and
> Spring
>> >>> based web applications (feel free to disagree!). Yet it's
> classified
>> >>> as an anti-pattern by Martin Fowler as we are using mostly
> procedural
>> >>> programming and have an anemic domain model (
>> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>> >>>
>> >>> What I would like:
>> >>> ---
>> >>>
>> >>> I would like to use a more OOP approach and have logic in our
> current
>> >>> entities, creating a rich domain model. For that to work in all
> cases
>> >>> they need to be able to load and save data. I would still use a
> Spring
>> >>> singleton bean's for different services. But instead of changing
> the
>> >>> entities like structs they would be rich objects capable of
> chaning
>> >>> themself's and other objects.
>> >>>
>> >>> I found this article very interesting:
>> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>> >>>
>> >>> But how would something like that work with Wicket? Could I just
> use
>> >>> @SpringBean like I'm currently doing but use it on both "entities"
> and
>> >>> Spring singleton services?
>> >>>
>> >>> For me this has a purely practical benefit, as I could use some
>> >>> inheritance in the domain object model to create different
> variations
>> >>> of logic and not just data. Wicket feels quite agile and nice to
> work
>> >>> with, but I still feel that the current architecture is a bit
> stale
>> >>> and seldom supports elegant OO solutions (that said, of course
> things
>> >>> can still be solved elegantly, I just think it would be easier if
> I
>> >>> could do it in a more OO oriented way).
>> >>>
>> >>> Comments? What are the pros and cons of this kind of architecture?
>> >>>
>> >>> All comments are greatly appreciated!
>> >>>
>> >>> Best regards, Kent
>> >>>
>> >>>
> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> 05/28/09
>> 18:09:00
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

RE: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Chris Colman <ch...@stepaheadsoftware.com>]

Another extremely light weight IoC with ORM wrapping (JDO and Hibernate)
is exPOJO at http://www.expojo.com

No need for old fashioned DAOs etc., just POJOs being persisted
transparently the way they should be.

In terms of serialization:

Is that for the purpose of scaling in a cluster environment? I vote for
'session affinity' every time - it's almost necessary when you have
anything more sophisticated than an anemic domain model. Do you really
want to be shifting complex object models from server to server via
serialization?

If it's not for a cluster environment but for a single server to allow
stale sessions to be swapped out then let the garbage collection clean
out the ORM's object cache instead.

> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> Sent: Friday, 29 May 2009 3:38 AM
> To: users@wicket.apache.org
> Subject: Re: Anemic domain model and are @SpringBean's compatible with
the
> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> 
> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
<ke...@gmail.com>
> wrote:
> > Nice! I think Salve looks great! And it solves more than this
problem,
> > I like the design by contract module too as it allows me to validate
> > parameters in a bit more declarative way.
> >
> > Do you think Salve is ready to be used in production? I'm a bit
> > concerned by "Although already usable, Salve is still in its
infancy.
> > Not all features have been implemented and not all problems worked
> > out.". I only see one open issue and it doesn't seem too major for
me
> > to pick it up.
> 
> we have been using it in production for a while without any problems.
> i just need to find the time to update the website text :)
> 
> > If I'm not mistaken Salve may be used (for lots of things, but one
is)
> > to solve serialization issues with Spring beans in Wicket
components?
> > But isn't that the same issue that the Wicket IOC and it's
@SpringBean
> > annotation solves?
> 
> wicket ioc can only take it so far. because it has to generate a proxy
> there are limitations to what classes can be proxies - eg no final
> methods, default constructor, etc. salve doesnt use a proxy so it
> doesnt have any problems.
> 
> although small, wicket ioc does have an overhead of having to
> serialize the proxy with the componnet. since salve removes the field
> it has no such overhead, this is more important when you are returning
> large resultsets of entities that use dependencies.
> 
> > If that's the case: Could I use Spring to inject my entities with
> > DAO's for now, and use the @SpringBean annotation on those as well
in
> > my Wicket components (In those cases I have entities as class vars)?
> > And the @SpringBean will solve the serialization issue?
> 
> you can use whatever works for you. salve is an alternative :)
> 
> > By just looking at Salve a bit it seems I could migrate to Salve in
> > two steps that way. And it might be a pretty smooth path to take? It
> > would mean that I inject 1000 entities for no good reason. But if I
> > see a performance problem in doing so I could just migrate to Salve?
> > By smooth path I mean that I would have access to my DAO's in my
> > entities and would essentially only change the dependency
annotations
> > and setup Salve.
> 
> as long as you do not use spring-specific injection rules you should
> be fine. salve uses lookup by type primarily, but also does have
> @SpringBeanId that can be used as a qualifier.
> 
> 
> > Of course, if Salve is production ready. Then could I throw out
Wicket
> > IOC and the @SpringBean annotation and use Salve instead to solve
> > serialization issues? In this case I would use Salve for my
> > presentation/Wicket -layer as well as dependency injection in my
> > entities and Spring as I already do for my service/business -layer
and
> > my persistence/DTO -layer. Or would it be nicer to have Salve handle
> > dependencies in the last two layers as well?
> 
> we use salve to inject across all layers. it gives you a consistent
> approach to use and mock in unit tests. we have a spring context that
> contains true services - eg session factory, mail sender, credit card
> processor, etc. all of our domain model then uses salve to inject
> these wherever needed.
> 
> -igor
> 
> > A lot of questions and text. Thanks for reading this far! :-)
> >
> > Best regards, Kent
> >
> >
> >
> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
<ig...@gmail.com>
> wrote:
> >> this is why i built salve.googlecode.com
> >>
> >> you can easily hook it into spring and have all your objects (doman
> >> objects or wicket components) injected via @Dependency without
> >> worrying about serialization issues or eager injection - eg if you
> >> load a result set of 1000 hibernate entities that need injection
you
> >> dont want all those injected for no reason.
> >>
> >> -igor
> >>
> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
<ke...@gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> Our current architecture:
> >>> ---
> >>>
> >>> We're currently using a 3-tier architecture (presentation,
> >>> service/business and persistence) consisting of Wicket (+ a little
> >>> Spring), Spring and Spring + Hibernate:
> >>>
> >>> Wicket:
> >>>
> >>> Does presentation, we're not inside a transaction / Hibernate
session
> >>> so all used fields must be loaded by Spring. We call Spring
singleton
> >>> beans and annotate those fields with @SpringBean.
> >>>
> >>> Spring:
> >>>
> >>> In the service layer we have Spring singleton beans, services,
which
> >>> are called from the Wicket layer. We have our transaction /
Hibernate
> >>> session boundary at this layer. We call DAO's from this layer.
> >>>
> >>> Spring + Hibernate:
> >>>
> >>> Our DAO's are Spring singleton beans which performs database
> >>> operations using HibernateTemplate.
> >>>
> >>> And common to all the layers are our entities. We use the @Entity
> >>> annotation on them (not XML), from the Wicket layer we just use
the
> >>> accessor methods making sure that the relevant fields are loaded
(as
> >>> we would get an exception if they were Lazy and not yet loaded).
Our
> >>> entities are stupid, they lack logic and are used mostly like a
struct
> >>> in C/C++.
> >>>
> >>> I think the general pattern is pretty common for Java EE and
Spring
> >>> based web applications (feel free to disagree!). Yet it's
classified
> >>> as an anti-pattern by Martin Fowler as we are using mostly
procedural
> >>> programming and have an anemic domain model (
> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >>>
> >>> What I would like:
> >>> ---
> >>>
> >>> I would like to use a more OOP approach and have logic in our
current
> >>> entities, creating a rich domain model. For that to work in all
cases
> >>> they need to be able to load and save data. I would still use a
Spring
> >>> singleton bean's for different services. But instead of changing
the
> >>> entities like structs they would be rich objects capable of
chaning
> >>> themself's and other objects.
> >>>
> >>> I found this article very interesting:
> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >>>
> >>> But how would something like that work with Wicket? Could I just
use
> >>> @SpringBean like I'm currently doing but use it on both "entities"
and
> >>> Spring singleton services?
> >>>
> >>> For me this has a purely practical benefit, as I could use some
> >>> inheritance in the domain object model to create different
variations
> >>> of logic and not just data. Wicket feels quite agile and nice to
work
> >>> with, but I still feel that the current architecture is a bit
stale
> >>> and seldom supports elegant OO solutions (that said, of course
things
> >>> can still be solved elegantly, I just think it would be easier if
I
> >>> could do it in a more OO oriented way).
> >>>
> >>> Comments? What are the pros and cons of this kind of architecture?
> >>>
> >>> All comments are greatly appreciated!
> >>>
> >>> Best regards, Kent
> >>>
> >>>
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

On Thu, May 28, 2009 at 10:09 AM, Kent Larsson <ke...@gmail.com> wrote:
> Nice! I think Salve looks great! And it solves more than this problem,
> I like the design by contract module too as it allows me to validate
> parameters in a bit more declarative way.
>
> Do you think Salve is ready to be used in production? I'm a bit
> concerned by "Although already usable, Salve is still in its infancy.
> Not all features have been implemented and not all problems worked
> out.". I only see one open issue and it doesn't seem too major for me
> to pick it up.

we have been using it in production for a while without any problems.
i just need to find the time to update the website text :)

> If I'm not mistaken Salve may be used (for lots of things, but one is)
> to solve serialization issues with Spring beans in Wicket components?
> But isn't that the same issue that the Wicket IOC and it's @SpringBean
> annotation solves?

wicket ioc can only take it so far. because it has to generate a proxy
there are limitations to what classes can be proxies - eg no final
methods, default constructor, etc. salve doesnt use a proxy so it
doesnt have any problems.

although small, wicket ioc does have an overhead of having to
serialize the proxy with the componnet. since salve removes the field
it has no such overhead, this is more important when you are returning
large resultsets of entities that use dependencies.

> If that's the case: Could I use Spring to inject my entities with
> DAO's for now, and use the @SpringBean annotation on those as well in
> my Wicket components (In those cases I have entities as class vars)?
> And the @SpringBean will solve the serialization issue?

you can use whatever works for you. salve is an alternative :)

> By just looking at Salve a bit it seems I could migrate to Salve in
> two steps that way. And it might be a pretty smooth path to take? It
> would mean that I inject 1000 entities for no good reason. But if I
> see a performance problem in doing so I could just migrate to Salve?
> By smooth path I mean that I would have access to my DAO's in my
> entities and would essentially only change the dependency annotations
> and setup Salve.

as long as you do not use spring-specific injection rules you should
be fine. salve uses lookup by type primarily, but also does have
@SpringBeanId that can be used as a qualifier.


> Of course, if Salve is production ready. Then could I throw out Wicket
> IOC and the @SpringBean annotation and use Salve instead to solve
> serialization issues? In this case I would use Salve for my
> presentation/Wicket -layer as well as dependency injection in my
> entities and Spring as I already do for my service/business -layer and
> my persistence/DTO -layer. Or would it be nicer to have Salve handle
> dependencies in the last two layers as well?

we use salve to inject across all layers. it gives you a consistent
approach to use and mock in unit tests. we have a spring context that
contains true services - eg session factory, mail sender, credit card
processor, etc. all of our domain model then uses salve to inject
these wherever needed.

-igor

> A lot of questions and text. Thanks for reading this far! :-)
>
> Best regards, Kent
>
>
>
> On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> this is why i built salve.googlecode.com
>>
>> you can easily hook it into spring and have all your objects (doman
>> objects or wicket components) injected via @Dependency without
>> worrying about serialization issues or eager injection - eg if you
>> load a result set of 1000 hibernate entities that need injection you
>> dont want all those injected for no reason.
>>
>> -igor
>>
>> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson <ke...@gmail.com> wrote:
>>> Hi,
>>>
>>> Our current architecture:
>>> ---
>>>
>>> We're currently using a 3-tier architecture (presentation,
>>> service/business and persistence) consisting of Wicket (+ a little
>>> Spring), Spring and Spring + Hibernate:
>>>
>>> Wicket:
>>>
>>> Does presentation, we're not inside a transaction / Hibernate session
>>> so all used fields must be loaded by Spring. We call Spring singleton
>>> beans and annotate those fields with @SpringBean.
>>>
>>> Spring:
>>>
>>> In the service layer we have Spring singleton beans, services, which
>>> are called from the Wicket layer. We have our transaction / Hibernate
>>> session boundary at this layer. We call DAO's from this layer.
>>>
>>> Spring + Hibernate:
>>>
>>> Our DAO's are Spring singleton beans which performs database
>>> operations using HibernateTemplate.
>>>
>>> And common to all the layers are our entities. We use the @Entity
>>> annotation on them (not XML), from the Wicket layer we just use the
>>> accessor methods making sure that the relevant fields are loaded (as
>>> we would get an exception if they were Lazy and not yet loaded). Our
>>> entities are stupid, they lack logic and are used mostly like a struct
>>> in C/C++.
>>>
>>> I think the general pattern is pretty common for Java EE and Spring
>>> based web applications (feel free to disagree!). Yet it's classified
>>> as an anti-pattern by Martin Fowler as we are using mostly procedural
>>> programming and have an anemic domain model (
>>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>>
>>> What I would like:
>>> ---
>>>
>>> I would like to use a more OOP approach and have logic in our current
>>> entities, creating a rich domain model. For that to work in all cases
>>> they need to be able to load and save data. I would still use a Spring
>>> singleton bean's for different services. But instead of changing the
>>> entities like structs they would be rich objects capable of chaning
>>> themself's and other objects.
>>>
>>> I found this article very interesting:
>>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>>
>>> But how would something like that work with Wicket? Could I just use
>>> @SpringBean like I'm currently doing but use it on both "entities" and
>>> Spring singleton services?
>>>
>>> For me this has a purely practical benefit, as I could use some
>>> inheritance in the domain object model to create different variations
>>> of logic and not just data. Wicket feels quite agile and nice to work
>>> with, but I still feel that the current architecture is a bit stale
>>> and seldom supports elegant OO solutions (that said, of course things
>>> can still be solved elegantly, I just think it would be easier if I
>>> could do it in a more OO oriented way).
>>>
>>> Comments? What are the pros and cons of this kind of architecture?
>>>
>>> All comments are greatly appreciated!
>>>
>>> Best regards, Kent
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Nice! I think Salve looks great! And it solves more than this problem,
I like the design by contract module too as it allows me to validate
parameters in a bit more declarative way.

Do you think Salve is ready to be used in production? I'm a bit
concerned by "Although already usable, Salve is still in its infancy.
Not all features have been implemented and not all problems worked
out.". I only see one open issue and it doesn't seem too major for me
to pick it up.

If I'm not mistaken Salve may be used (for lots of things, but one is)
to solve serialization issues with Spring beans in Wicket components?
But isn't that the same issue that the Wicket IOC and it's @SpringBean
annotation solves?

If that's the case: Could I use Spring to inject my entities with
DAO's for now, and use the @SpringBean annotation on those as well in
my Wicket components (In those cases I have entities as class vars)?
And the @SpringBean will solve the serialization issue?

By just looking at Salve a bit it seems I could migrate to Salve in
two steps that way. And it might be a pretty smooth path to take? It
would mean that I inject 1000 entities for no good reason. But if I
see a performance problem in doing so I could just migrate to Salve?
By smooth path I mean that I would have access to my DAO's in my
entities and would essentially only change the dependency annotations
and setup Salve.

Of course, if Salve is production ready. Then could I throw out Wicket
IOC and the @SpringBean annotation and use Salve instead to solve
serialization issues? In this case I would use Salve for my
presentation/Wicket -layer as well as dependency injection in my
entities and Spring as I already do for my service/business -layer and
my persistence/DTO -layer. Or would it be nicer to have Salve handle
dependencies in the last two layers as well?

A lot of questions and text. Thanks for reading this far! :-)

Best regards, Kent



On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> this is why i built salve.googlecode.com
>
> you can easily hook it into spring and have all your objects (doman
> objects or wicket components) injected via @Dependency without
> worrying about serialization issues or eager injection - eg if you
> load a result set of 1000 hibernate entities that need injection you
> dont want all those injected for no reason.
>
> -igor
>
> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson <ke...@gmail.com> wrote:
>> Hi,
>>
>> Our current architecture:
>> ---
>>
>> We're currently using a 3-tier architecture (presentation,
>> service/business and persistence) consisting of Wicket (+ a little
>> Spring), Spring and Spring + Hibernate:
>>
>> Wicket:
>>
>> Does presentation, we're not inside a transaction / Hibernate session
>> so all used fields must be loaded by Spring. We call Spring singleton
>> beans and annotate those fields with @SpringBean.
>>
>> Spring:
>>
>> In the service layer we have Spring singleton beans, services, which
>> are called from the Wicket layer. We have our transaction / Hibernate
>> session boundary at this layer. We call DAO's from this layer.
>>
>> Spring + Hibernate:
>>
>> Our DAO's are Spring singleton beans which performs database
>> operations using HibernateTemplate.
>>
>> And common to all the layers are our entities. We use the @Entity
>> annotation on them (not XML), from the Wicket layer we just use the
>> accessor methods making sure that the relevant fields are loaded (as
>> we would get an exception if they were Lazy and not yet loaded). Our
>> entities are stupid, they lack logic and are used mostly like a struct
>> in C/C++.
>>
>> I think the general pattern is pretty common for Java EE and Spring
>> based web applications (feel free to disagree!). Yet it's classified
>> as an anti-pattern by Martin Fowler as we are using mostly procedural
>> programming and have an anemic domain model (
>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>>
>> What I would like:
>> ---
>>
>> I would like to use a more OOP approach and have logic in our current
>> entities, creating a rich domain model. For that to work in all cases
>> they need to be able to load and save data. I would still use a Spring
>> singleton bean's for different services. But instead of changing the
>> entities like structs they would be rich objects capable of chaning
>> themself's and other objects.
>>
>> I found this article very interesting:
>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>>
>> But how would something like that work with Wicket? Could I just use
>> @SpringBean like I'm currently doing but use it on both "entities" and
>> Spring singleton services?
>>
>> For me this has a purely practical benefit, as I could use some
>> inheritance in the domain object model to create different variations
>> of logic and not just data. Wicket feels quite agile and nice to work
>> with, but I still feel that the current architecture is a bit stale
>> and seldom supports elegant OO solutions (that said, of course things
>> can still be solved elegantly, I just think it would be easier if I
>> could do it in a more OO oriented way).
>>
>> Comments? What are the pros and cons of this kind of architecture?
>>
>> All comments are greatly appreciated!
>>
>> Best regards, Kent
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Hi,

Thanks for answering. But I tried that and it wasn't enough on my
computer at least. I think the documentation says that it works in
some environments but not all. Using Tomcat 6 I couldn't get it
working without the -javaagent parameter.

I'm writing from memory now so it's probably a little wrong. But I
think the other solution was placing spring-agent.jar or
aspectjweaver.jar on $CATALINA_HOME/common/lib and using that tag.

Are you using Tomcat 6 and got this working purely by adding the
<context:load-time-weaver/> tag to your Spring XML?

Best regards, Kent


On Wed, Jun 10, 2009 at 5:52 PM, Maarten
Bosteels<mb...@gmail.com> wrote:
> Hi,
>
> According to the docs [1], it should be enough to add this to your spring
> XML configuration file:
>
> <context:load-time-weaver/>
>
> [1]  http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw
>
> Maarten
>
>
>
> On Wed, Jun 10, 2009 at 3:19 PM, Kent Larsson <ke...@gmail.com>wrote:
>
>> I skipped the AJDT plugin and am doing LTW (Load-Time Weaving) now, it
>> works.
>>
>> In my case I added: (It might be of use to someone)
>>
>>
>>  -javaagent:"/home/kent/.ivy2/cache/org.springframework/spring-agent/jars/spring-agent-2.5.6.SEC01.jar"
>>
>> To the Server Overview / Open launch configuration / Arguments.
>>
>> I'll investigate if I can use a classloader for Tomcat which I specify
>> in my Spring XML configuration instead, as it would mean that the
>> developers of the project won't have to mess with the server
>> configuration.
>>
>> On Wed, Jun 10, 2009 at 10:11 AM, Kent Larsson<ke...@gmail.com>
>> wrote:
>> > By the way. When using @Configured one has to get AspectJ working if
>> > I'm not mistaken?
>> >
>> > I've been messing with it for a while now and it's not going great.
>> > :-/ What I did was install the AJDT plugin for Eclipse and converted
>> > my project to a AspectJ project, then I got stuck. How are you who
>> > have it working solve the AspectJ part with Eclipse problem? Do you
>> > use load time weaving? I can't find a decent manual for the AJDT
>> > plugin.
>> >
>> > On Fri, May 29, 2009 at 12:59 PM, Kent Larsson<ke...@gmail.com>
>> wrote:
>> >> Ah, interesting. Thanks for elaborating!
>> >>
>> >> On Fri, May 29, 2009 at 12:31 PM, James Carman
>> >> <jc...@carmanconsulting.com> wrote:
>> >>> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com>
>> wrote:
>> >>>>> I try not to design my domain models in such a way
>> >>>>
>> >>>> Could you elaborate on this a bit, please?
>> >>>
>> >>> I kind of "cheat" a bit.  When there needs to be something done that
>> >>> involves multiple domain entities, I usually push that logic into a
>> >>> "service" class rather than into the entities themselves.  For
>> >>> operations solely involving an entity and its aggregated entities, I
>> >>> usually put that into the entity class itself.
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Maarten Bosteels <mb...@gmail.com>]

Hi,

According to the docs [1], it should be enough to add this to your spring
XML configuration file:

<context:load-time-weaver/>

[1]  http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw

Maarten



On Wed, Jun 10, 2009 at 3:19 PM, Kent Larsson <ke...@gmail.com>wrote:

> I skipped the AJDT plugin and am doing LTW (Load-Time Weaving) now, it
> works.
>
> In my case I added: (It might be of use to someone)
>
>
>  -javaagent:"/home/kent/.ivy2/cache/org.springframework/spring-agent/jars/spring-agent-2.5.6.SEC01.jar"
>
> To the Server Overview / Open launch configuration / Arguments.
>
> I'll investigate if I can use a classloader for Tomcat which I specify
> in my Spring XML configuration instead, as it would mean that the
> developers of the project won't have to mess with the server
> configuration.
>
> On Wed, Jun 10, 2009 at 10:11 AM, Kent Larsson<ke...@gmail.com>
> wrote:
> > By the way. When using @Configured one has to get AspectJ working if
> > I'm not mistaken?
> >
> > I've been messing with it for a while now and it's not going great.
> > :-/ What I did was install the AJDT plugin for Eclipse and converted
> > my project to a AspectJ project, then I got stuck. How are you who
> > have it working solve the AspectJ part with Eclipse problem? Do you
> > use load time weaving? I can't find a decent manual for the AJDT
> > plugin.
> >
> > On Fri, May 29, 2009 at 12:59 PM, Kent Larsson<ke...@gmail.com>
> wrote:
> >> Ah, interesting. Thanks for elaborating!
> >>
> >> On Fri, May 29, 2009 at 12:31 PM, James Carman
> >> <jc...@carmanconsulting.com> wrote:
> >>> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com>
> wrote:
> >>>>> I try not to design my domain models in such a way
> >>>>
> >>>> Could you elaborate on this a bit, please?
> >>>
> >>> I kind of "cheat" a bit.  When there needs to be something done that
> >>> involves multiple domain entities, I usually push that logic into a
> >>> "service" class rather than into the entities themselves.  For
> >>> operations solely involving an entity and its aggregated entities, I
> >>> usually put that into the entity class itself.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

I skipped the AJDT plugin and am doing LTW (Load-Time Weaving) now, it works.

In my case I added: (It might be of use to someone)

 -javaagent:"/home/kent/.ivy2/cache/org.springframework/spring-agent/jars/spring-agent-2.5.6.SEC01.jar"

To the Server Overview / Open launch configuration / Arguments.

I'll investigate if I can use a classloader for Tomcat which I specify
in my Spring XML configuration instead, as it would mean that the
developers of the project won't have to mess with the server
configuration.

On Wed, Jun 10, 2009 at 10:11 AM, Kent Larsson<ke...@gmail.com> wrote:
> By the way. When using @Configured one has to get AspectJ working if
> I'm not mistaken?
>
> I've been messing with it for a while now and it's not going great.
> :-/ What I did was install the AJDT plugin for Eclipse and converted
> my project to a AspectJ project, then I got stuck. How are you who
> have it working solve the AspectJ part with Eclipse problem? Do you
> use load time weaving? I can't find a decent manual for the AJDT
> plugin.
>
> On Fri, May 29, 2009 at 12:59 PM, Kent Larsson<ke...@gmail.com> wrote:
>> Ah, interesting. Thanks for elaborating!
>>
>> On Fri, May 29, 2009 at 12:31 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>>> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com> wrote:
>>>>> I try not to design my domain models in such a way
>>>>
>>>> Could you elaborate on this a bit, please?
>>>
>>> I kind of "cheat" a bit.  When there needs to be something done that
>>> involves multiple domain entities, I usually push that logic into a
>>> "service" class rather than into the entities themselves.  For
>>> operations solely involving an entity and its aggregated entities, I
>>> usually put that into the entity class itself.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

By the way. When using @Configured one has to get AspectJ working if
I'm not mistaken?

I've been messing with it for a while now and it's not going great.
:-/ What I did was install the AJDT plugin for Eclipse and converted
my project to a AspectJ project, then I got stuck. How are you who
have it working solve the AspectJ part with Eclipse problem? Do you
use load time weaving? I can't find a decent manual for the AJDT
plugin.

On Fri, May 29, 2009 at 12:59 PM, Kent Larsson<ke...@gmail.com> wrote:
> Ah, interesting. Thanks for elaborating!
>
> On Fri, May 29, 2009 at 12:31 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com> wrote:
>>>> I try not to design my domain models in such a way
>>>
>>> Could you elaborate on this a bit, please?
>>
>> I kind of "cheat" a bit.  When there needs to be something done that
>> involves multiple domain entities, I usually push that logic into a
>> "service" class rather than into the entities themselves.  For
>> operations solely involving an entity and its aggregated entities, I
>> usually put that into the entity class itself.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

Ah, interesting. Thanks for elaborating!

On Fri, May 29, 2009 at 12:31 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com> wrote:
>>> I try not to design my domain models in such a way
>>
>> Could you elaborate on this a bit, please?
>
> I kind of "cheat" a bit.  When there needs to be something done that
> involves multiple domain entities, I usually push that logic into a
> "service" class rather than into the entities themselves.  For
> operations solely involving an entity and its aggregated entities, I
> usually put that into the entity class itself.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in

[James Carman <jc...@carmanconsulting.com>]

On Fri, May 29, 2009 at 11:03 AM, Daniel Toffetti <dt...@yahoo.com.ar> wrote:
>    Out of curiosity, does the practice of building medium to
> complex queries and mixed batches of updates and deletes within
> stores procedures, for optimum DB performance, has been completely
> deprecated ???

I personally hate putting stuff in the database, because it just leads
to troubles, based on my experience.  It's harder to unit test your
code if too much stuff is in the database.  I like to use in-memory
(HSQLDB) databases during unit tests and you can't rely on those
stored procedures being around during your unit test.  Also, in some
organizations, DBAs maintain very tight control over things like
stored procedures in their databases.  It can become a bottleneck.

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

RE: wicket and jquery

[Stefan Lindner <li...@visionet.de>]

I'm just finishing up some things (e.g. documentation :-) and proper examples). I must confess that the library is based upon wicket 1.4. and i don't plan to backport it to wicket 1.3.
In a few days I will open up our subversion repository for public access.

-----Ursprüngliche Nachricht-----
Von: Cristi Manole [mailto:cristimanole@gmail.com] 
Gesendet: Freitag, 29. Mai 2009 19:32
An: users@wicket.apache.org
Betreff: Re: wicket and jquery

not bad. do you have a link?

Cristi Manole

On Fri, May 29, 2009 at 1:39 PM, Stefan Lindner <li...@visionet.de> wrote:

> Currently I'm building a wicket library around jQuery. Drag and drop and
> resizable are ready for use (with callback handlers in Wicket-Java onDrop,
> on Resized etc.). If anybody is interrested I can provied a simple library
> with some simple examples.
>
> -----Ursprüngliche Nachricht-----
> Von: Dorothée Giernoth [mailto:Dorothee.Giernoth@kds-kg.de]
> Gesendet: Freitag, 29. Mai 2009 17:33
> An: users@wicket.apache.org
> Betreff: AW: wicket and jquery
>
> Thnx guys, I will check that out. This might mean, that not all hope is
> lost!
> Have a great weekend!
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rodolfo Hansen [mailto:kryptt@gmail.com]
> Gesendet: Freitag, 29. Mai 2009 17:21
> An: users@wicket.apache.org
> Betreff: Re: wicket and jquery
>
> Also you can checkout
>
> http://code.google.com/p/wiquery/
>
> which has a couple of ideas...
>
> On Fri, May 29, 2009 at 11:15 AM, Dipu <di...@googlemail.com> wrote:
>
> > take a look at this
> >
> >
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent
> >
> > -dipu
> >
> > 2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> > > Hello everyone,
> > >
> > > i know this might sound a little weird and naive and maybe stupid ... I
> > dunno, I'll ask anyway (though I did research myself, but I would need
> some
> > sort of useful hint for a total wicket-jquery-newbie): how can I use
> wicket
> > and jquery together? Where can I find an example?
> > >
> > > And yes I did ask google, but seriously - no harm meant - it seems
> > soooooo NOT organized ... there are like a billion dead links ... maybe
> even
> > more and I am on the edge and desperate ... soooo please, bear with me!
> > >
> > > Thnx,
> > > dg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Rodolfo Hansen
> CEO, KindleIT Software Development
> Email: rhansen@kindleit.net
> Office: 1 (809) 732-5200
> Mobile: 1 (809) 299-7332
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Cristi Manole

Nova Creator Software
www.novacreator.com

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

Re: wicket and jquery

[Cristi Manole <cr...@gmail.com>]

not bad. do you have a link?

Cristi Manole

On Fri, May 29, 2009 at 1:39 PM, Stefan Lindner <li...@visionet.de> wrote:

> Currently I'm building a wicket library around jQuery. Drag and drop and
> resizable are ready for use (with callback handlers in Wicket-Java onDrop,
> on Resized etc.). If anybody is interrested I can provied a simple library
> with some simple examples.
>
> -----Ursprüngliche Nachricht-----
> Von: Dorothée Giernoth [mailto:Dorothee.Giernoth@kds-kg.de]
> Gesendet: Freitag, 29. Mai 2009 17:33
> An: users@wicket.apache.org
> Betreff: AW: wicket and jquery
>
> Thnx guys, I will check that out. This might mean, that not all hope is
> lost!
> Have a great weekend!
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rodolfo Hansen [mailto:kryptt@gmail.com]
> Gesendet: Freitag, 29. Mai 2009 17:21
> An: users@wicket.apache.org
> Betreff: Re: wicket and jquery
>
> Also you can checkout
>
> http://code.google.com/p/wiquery/
>
> which has a couple of ideas...
>
> On Fri, May 29, 2009 at 11:15 AM, Dipu <di...@googlemail.com> wrote:
>
> > take a look at this
> >
> >
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent
> >
> > -dipu
> >
> > 2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> > > Hello everyone,
> > >
> > > i know this might sound a little weird and naive and maybe stupid ... I
> > dunno, I'll ask anyway (though I did research myself, but I would need
> some
> > sort of useful hint for a total wicket-jquery-newbie): how can I use
> wicket
> > and jquery together? Where can I find an example?
> > >
> > > And yes I did ask google, but seriously - no harm meant - it seems
> > soooooo NOT organized ... there are like a billion dead links ... maybe
> even
> > more and I am on the edge and desperate ... soooo please, bear with me!
> > >
> > > Thnx,
> > > dg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Rodolfo Hansen
> CEO, KindleIT Software Development
> Email: rhansen@kindleit.net
> Office: 1 (809) 732-5200
> Mobile: 1 (809) 299-7332
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Cristi Manole

Nova Creator Software
www.novacreator.com

AW: wicket and jquery

[Stefan Lindner <li...@visionet.de>]

Currently I'm building a wicket library around jQuery. Drag and drop and resizable are ready for use (with callback handlers in Wicket-Java onDrop, on Resized etc.). If anybody is interrested I can provied a simple library with some simple examples.

-----Ursprüngliche Nachricht-----
Von: Dorothée Giernoth [mailto:Dorothee.Giernoth@kds-kg.de] 
Gesendet: Freitag, 29. Mai 2009 17:33
An: users@wicket.apache.org
Betreff: AW: wicket and jquery

Thnx guys, I will check that out. This might mean, that not all hope is lost!
Have a great weekend!


-----Ursprüngliche Nachricht-----
Von: Rodolfo Hansen [mailto:kryptt@gmail.com] 
Gesendet: Freitag, 29. Mai 2009 17:21
An: users@wicket.apache.org
Betreff: Re: wicket and jquery

Also you can checkout

http://code.google.com/p/wiquery/

which has a couple of ideas...

On Fri, May 29, 2009 at 11:15 AM, Dipu <di...@googlemail.com> wrote:

> take a look at this
>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent
>
> -dipu
>
> 2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> > Hello everyone,
> >
> > i know this might sound a little weird and naive and maybe stupid ... I
> dunno, I'll ask anyway (though I did research myself, but I would need some
> sort of useful hint for a total wicket-jquery-newbie): how can I use wicket
> and jquery together? Where can I find an example?
> >
> > And yes I did ask google, but seriously - no harm meant - it seems
> soooooo NOT organized ... there are like a billion dead links ... maybe even
> more and I am on the edge and desperate ... soooo please, bear with me!
> >
> > Thnx,
> > dg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Rodolfo Hansen
CEO, KindleIT Software Development
Email: rhansen@kindleit.net
Office: 1 (809) 732-5200
Mobile: 1 (809) 299-7332

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


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

Re: weird changes on ajaxeditablemultilinelabel

[Igor Vaynberg <ig...@gmail.com>]

make sure your servlet container and the pages you serve are all using
utf-8 encoding

-igor

2009/6/2 Dorothée Giernoth <Do...@kds-kg.de>:
> Hey everyone,
>
> I am having a little problem with multiline editable labels.
> I add some text in Spanish with some special characters, but now this happens when I activate the field to edit the text and leave it again without actually changing anything:
>
> BEFORE:
> Encerrados en el hotel... calor
> Después del estrago aéreo
> ¿Y que persona eres tu? Baja!
> Te fías de la retórica
> Te juro si supiera que te daña, nunca partiría
> No, no, no
> Si solo con valor me lo pidieras, no te dejaría
> No, no, no ...
>
> AFTER:
> Encerrados en el hotel... calor
> Después del estrago aéreo
> ¿Y que persona eres tu? Baja!
> Te fías de la retórica
> Te juro si supiera que te daña, nunca partiría
> No, no, no
> Si solo con valor me lo pidieras, no te dejaría
> No, no, no
>
> How can I avoid this kind of change?
>
> Thnx in advance.
> DG
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

weird changes on ajaxeditablemultilinelabel

[Dorothée Giernoth <Do...@kds-kg.de>]

Hey everyone,

I am having a little problem with multiline editable labels.
I add some text in Spanish with some special characters, but now this happens when I activate the field to edit the text and leave it again without actually changing anything:

BEFORE:
Encerrados en el hotel... calor
Después del estrago aéreo
¿Y que persona eres tu? Baja!
Te fías de la retórica
Te juro si supiera que te daña, nunca partiría
No, no, no
Si solo con valor me lo pidieras, no te dejaría
No, no, no ...

AFTER:
Encerrados en el hotel... calor
Después del estrago aéreo
¿Y que persona eres tu? Baja!
Te fías de la retórica
Te juro si supiera que te daña, nunca partiría
No, no, no
Si solo con valor me lo pidieras, no te dejaría
No, no, no

How can I avoid this kind of change?

Thnx in advance.
DG

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

AW: wicket and jquery

[Dorothée Giernoth <Do...@kds-kg.de>]

Thnx guys, I will check that out. This might mean, that not all hope is lost!
Have a great weekend!


-----Ursprüngliche Nachricht-----
Von: Rodolfo Hansen [mailto:kryptt@gmail.com] 
Gesendet: Freitag, 29. Mai 2009 17:21
An: users@wicket.apache.org
Betreff: Re: wicket and jquery

Also you can checkout

http://code.google.com/p/wiquery/

which has a couple of ideas...

On Fri, May 29, 2009 at 11:15 AM, Dipu <di...@googlemail.com> wrote:

> take a look at this
>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent
>
> -dipu
>
> 2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> > Hello everyone,
> >
> > i know this might sound a little weird and naive and maybe stupid ... I
> dunno, I'll ask anyway (though I did research myself, but I would need some
> sort of useful hint for a total wicket-jquery-newbie): how can I use wicket
> and jquery together? Where can I find an example?
> >
> > And yes I did ask google, but seriously - no harm meant - it seems
> soooooo NOT organized ... there are like a billion dead links ... maybe even
> more and I am on the edge and desperate ... soooo please, bear with me!
> >
> > Thnx,
> > dg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Rodolfo Hansen
CEO, KindleIT Software Development
Email: rhansen@kindleit.net
Office: 1 (809) 732-5200
Mobile: 1 (809) 299-7332

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

Re: wicket and jquery

[Rodolfo Hansen <kr...@gmail.com>]

Also you can checkout

http://code.google.com/p/wiquery/

which has a couple of ideas...

On Fri, May 29, 2009 at 11:15 AM, Dipu <di...@googlemail.com> wrote:

> take a look at this
>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent
>
> -dipu
>
> 2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> > Hello everyone,
> >
> > i know this might sound a little weird and naive and maybe stupid ... I
> dunno, I'll ask anyway (though I did research myself, but I would need some
> sort of useful hint for a total wicket-jquery-newbie): how can I use wicket
> and jquery together? Where can I find an example?
> >
> > And yes I did ask google, but seriously - no harm meant - it seems
> soooooo NOT organized ... there are like a billion dead links ... maybe even
> more and I am on the edge and desperate ... soooo please, bear with me!
> >
> > Thnx,
> > dg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Rodolfo Hansen
CEO, KindleIT Software Development
Email: rhansen@kindleit.net
Office: 1 (809) 732-5200
Mobile: 1 (809) 299-7332

Re: wicket and jquery

[Dipu <di...@googlemail.com>]

take a look at this
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent

-dipu

2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>:
> Hello everyone,
>
> i know this might sound a little weird and naive and maybe stupid ... I dunno, I'll ask anyway (though I did research myself, but I would need some sort of useful hint for a total wicket-jquery-newbie): how can I use wicket and jquery together? Where can I find an example?
>
> And yes I did ask google, but seriously - no harm meant - it seems soooooo NOT organized ... there are like a billion dead links ... maybe even more and I am on the edge and desperate ... soooo please, bear with me!
>
> Thnx,
> dg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: wicket and jquery

[Cristi Manole <cr...@gmail.com>]

Hi,

There's no magic here. it's just a (decent) javascript library that you can
use. Usually what people are doing (or at least how I use it) here is build
the web application the normal way - html / css / javascript (consider this
the designer role) and then "wickify" it - meaning go through the initial
design and put wicket:id's to elements I want to connect to my java logic.
And do whatever my business rules are. Or go one step further and build
stand-alone component for reuse on other projects.

The point is I don't actually care if the designer uses jquery or extjs or
anything else. He's not forced on using any javascript at all. Perfectly
clean separation.

I guess you're looking on using a nice "widget" that somebody built using
jquery. The integration with wicket is as simple as I said above. No magic.

For a very (_very_) dumb example, take a look for instance here (to get an
idea) :
http://www.dooriented.com/blog/2009/05/11/wicket-component-jquery-accordion-menu/

Hope I was able to help you a little bit,
Cristi Manole

2009/5/29 Dorothée Giernoth <Do...@kds-kg.de>

> Hello everyone,
>
> i know this might sound a little weird and naive and maybe stupid ... I
> dunno, I'll ask anyway (though I did research myself, but I would need some
> sort of useful hint for a total wicket-jquery-newbie): how can I use wicket
> and jquery together? Where can I find an example?
>
> And yes I did ask google, but seriously - no harm meant - it seems soooooo
> NOT organized ... there are like a billion dead links ... maybe even more
> and I am on the edge and desperate ... soooo please, bear with me!
>
> Thnx,
> dg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Cristi Manole

Nova Creator Software
www.novacreator.com

wicket and jquery

[Dorothée Giernoth <Do...@kds-kg.de>]

Hello everyone,

i know this might sound a little weird and naive and maybe stupid ... I dunno, I'll ask anyway (though I did research myself, but I would need some sort of useful hint for a total wicket-jquery-newbie): how can I use wicket and jquery together? Where can I find an example?

And yes I did ask google, but seriously - no harm meant - it seems soooooo NOT organized ... there are like a billion dead links ... maybe even more and I am on the edge and desperate ... soooo please, bear with me!

Thnx,
dg


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

Re: Anemic domain model and are @SpringBean's compatible with the solution in

[Daniel Toffetti <dt...@yahoo.com.ar>]

James Carman <jcarman <at> carmanconsulting.com> writes:
> 
> On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <kent.larsson <at> gmail.com>
> wrote:
> >> I try not to design my domain models in such a way
> >
> > Could you elaborate on this a bit, please?
> 
> I kind of "cheat" a bit.  When there needs to be something done that
> involves multiple domain entities, I usually push that logic into a
> "service" class rather than into the entities themselves.  For
> operations solely involving an entity and its aggregated entities, I
> usually put that into the entity class itself.
> 

    Out of curiosity, does the practice of building medium to
complex queries and mixed batches of updates and deletes within
stores procedures, for optimum DB performance, has been completely
deprecated ???

Cheers,

Daniel




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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[James Carman <jc...@carmanconsulting.com>]

On Fri, May 29, 2009 at 4:04 AM, Kent Larsson <ke...@gmail.com> wrote:
>> I try not to design my domain models in such a way
>
> Could you elaborate on this a bit, please?

I kind of "cheat" a bit.  When there needs to be something done that
involves multiple domain entities, I usually push that logic into a
"service" class rather than into the entities themselves.  For
operations solely involving an entity and its aggregated entities, I
usually put that into the entity class itself.

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Kent Larsson <ke...@gmail.com>]

> I try not to design my domain models in such a way

Could you elaborate on this a bit, please?

On Fri, May 29, 2009 at 6:19 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Thu, May 28, 2009 at 11:36 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> this is why i built salve.googlecode.com
>>
>> you can easily hook it into spring and have all your objects (doman
>> objects or wicket components) injected via @Dependency without
>> worrying about serialization issues or eager injection - eg if you
>> load a result set of 1000 hibernate entities that need injection you
>> dont want all those injected for no reason.
>
> I try not to design my domain models in such a way, but sometimes it
> just fits if you want to be "domain-driven" and salve definitely is a
> good alternative to the @Configurable/@Autowire support in Spring.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[James Carman <jc...@carmanconsulting.com>]

On Thu, May 28, 2009 at 11:36 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> this is why i built salve.googlecode.com
>
> you can easily hook it into spring and have all your objects (doman
> objects or wicket components) injected via @Dependency without
> worrying about serialization issues or eager injection - eg if you
> load a result set of 1000 hibernate entities that need injection you
> dont want all those injected for no reason.

I try not to design my domain models in such a way, but sometimes it
just fits if you want to be "domain-driven" and salve definitely is a
good alternative to the @Configurable/@Autowire support in Spring.

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

Re: Anemic domain model and are @SpringBean's compatible with the solution in "Spring 2.0 vs. the Anemic Domain Model"?

[Igor Vaynberg <ig...@gmail.com>]

this is why i built salve.googlecode.com

you can easily hook it into spring and have all your objects (doman
objects or wicket components) injected via @Dependency without
worrying about serialization issues or eager injection - eg if you
load a result set of 1000 hibernate entities that need injection you
dont want all those injected for no reason.

-igor

On Thu, May 28, 2009 at 6:38 AM, Kent Larsson <ke...@gmail.com> wrote:
> Hi,
>
> Our current architecture:
> ---
>
> We're currently using a 3-tier architecture (presentation,
> service/business and persistence) consisting of Wicket (+ a little
> Spring), Spring and Spring + Hibernate:
>
> Wicket:
>
> Does presentation, we're not inside a transaction / Hibernate session
> so all used fields must be loaded by Spring. We call Spring singleton
> beans and annotate those fields with @SpringBean.
>
> Spring:
>
> In the service layer we have Spring singleton beans, services, which
> are called from the Wicket layer. We have our transaction / Hibernate
> session boundary at this layer. We call DAO's from this layer.
>
> Spring + Hibernate:
>
> Our DAO's are Spring singleton beans which performs database
> operations using HibernateTemplate.
>
> And common to all the layers are our entities. We use the @Entity
> annotation on them (not XML), from the Wicket layer we just use the
> accessor methods making sure that the relevant fields are loaded (as
> we would get an exception if they were Lazy and not yet loaded). Our
> entities are stupid, they lack logic and are used mostly like a struct
> in C/C++.
>
> I think the general pattern is pretty common for Java EE and Spring
> based web applications (feel free to disagree!). Yet it's classified
> as an anti-pattern by Martin Fowler as we are using mostly procedural
> programming and have an anemic domain model (
> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
>
> What I would like:
> ---
>
> I would like to use a more OOP approach and have logic in our current
> entities, creating a rich domain model. For that to work in all cases
> they need to be able to load and save data. I would still use a Spring
> singleton bean's for different services. But instead of changing the
> entities like structs they would be rich objects capable of chaning
> themself's and other objects.
>
> I found this article very interesting:
> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
>
> But how would something like that work with Wicket? Could I just use
> @SpringBean like I'm currently doing but use it on both "entities" and
> Spring singleton services?
>
> For me this has a purely practical benefit, as I could use some
> inheritance in the domain object model to create different variations
> of logic and not just data. Wicket feels quite agile and nice to work
> with, but I still feel that the current architecture is a bit stale
> and seldom supports elegant OO solutions (that said, of course things
> can still be solved elegantly, I just think it would be easier if I
> could do it in a more OO oriented way).
>
> Comments? What are the pros and cons of this kind of architecture?
>
> All comments are greatly appreciated!
>
> Best regards, Kent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

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