12:55 p.m.
Cross-posting to forge dev.
On Tue, Sep 20, 2011 at 13:54, Dan Allen <dan.j.allen(a)gmail.com> wrote:
xsalefter,
Thanks, this is valuable feedback and certainly usage patterns to keep in
mind when designing the new iteration of these components.
In numerous conversations that I've had with developers familiar with Seam
2, the common theme is that *Home and *Query components are not the ideal
design. They lead developers into tight corners exactly in the way you are
describing. Thus, we likely won't be following the status quo (though, it's
not too big of an effort to port the existing functionality to CDI, so if
someone would like to work on that, we won't discourage it).
Instead, I think these components should provide boilerplate functionality,
yet be flexible and easily tuned to the needs of the developer. I think
you're right in that going back to a generic DAO design might be a more
reasonable strategy. I don't think developer expect to code entirely in XML,
they simply don't want to type the same boilerplate over and over again.
I like Jason's idea of using named queries. Keep in mind we could read the
queries as a suggestion and produce more sophisticated queries in an
extension...so we aren't limited to what named queries support today. We've
also been considering supporting finder "missing" methods that build a query
from the name of the method (or a set of annotations on the method).
Whatever we decide, this should be the framework code that forge uses when
generating CRUD applications. Let's make it something that we aren't ashamed
of having in our projects ;)
-Dan
p.s. I also recommend renaming SAF, because it's a really confusing term.
Something like "entity framework" is far more sensible.
On Tue, Sep 20, 2011 at 03:47, xsalefter <xsalefter(a)yahoo.com> wrote:
> Hi all.. I know that I never involved on this mailing-list so much, nor
> contribute things to the community. But because I have an experience with
> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and
> EntityHome a lot) in some project, I have a thought about this.
>
> EntityQuery anda EntityHome is perfect in case you want to creating an
> simple CRUD application. Well, not as simple as is. I ever involved in a
> project with 40 more database tables with quite extensive financial
> transaction, and use an EntityQuery and EntityHome a lot. The main problem
> with these classes is that, It's hard (well, at least, for me) to make your
> code consistent. What I mean by consistent is that, it is confusing to
> determine whether the classes is a part of your UI layer, or
> service/domain-model layer. Or where you add new functionality to satisfied
> a specifics requirement. The study case is maybe like this:
>
> Let say that we have a module named accounting transaction. And we want to
> create a input transaction page, thus we have a TransactionHome.xhtml backed
> with TransactionHome.java. Now the problems occurs. Because we want a chart
> of account list in the TransactionHome.xhtml, where is better place to put
> the logic to call the chart of account list? In the TransactionHome.java, or
> ChartOfAccountList.java?
>
> In the beginning I put it in the ChartOfAccountList.java, and start to
> realize that seam's EntityList is specialized class to create a page with
> contains a rich datatable search option, paging, and sorting. It will be
> strange to the code if try to add non searching/sorting/paging on it. Then I
> think to back to good-old DAO object, and thinking again about the backing
> bean: I need to call/inject the DAO in some backing-bean, but where?
> TransactionHome.java? Well, TransactionHome already have getEntityManager(),
> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd.
> Then when I thinking again about the EntityHome, I'm not sure whether I need
> to treat this class as UI or Service class. You see, this is simple case
> study (don't get me start with "The list of Chart Of Account need to
> aligning with the logged in user's departments and user's role. And make
> sure that an user with level A have a $xxx limit transaction, where level B
> have $xxx limit").
>
> My purpose is not to blame something or rant to something, but instead,
> give an idea whether is it good enough to leave ***Home and ***Query
> concept, and back to at least
> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at
> least we have a "service" layer, which is "centralized" place to
write a
> business logic in our application. We could treat the "service" as
> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence
> classes with minimal coupled with the front-end layer), and put the richness
> of Weld and Seam 3 maybe in the UI and view layer.
>
> Well, I know this is personal view, from me, and my experience. Thus, just
> ignore if in case this is annoying and not fit with your purpose/target.
>
> Thanks,
> xsalefter
>
> *
> *
> The Home idea
>
>
https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/...
>
> The Query idea
>
>
https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/...
>
> The main thing that I would change with the Query class above is to use
> named queries, thus espousing the generally accepted best practice in
> default applications. I understand this doesn't fill all the gaps of the
> older SAF from Seam 2, but I think it works for the majority of cases, and
> it also helps people understand the best way to do things instead of relying
> on the magic of SAF from Seam 2 (which I have found to be a major problem in
> projects and teams I have worked with over the last three years).
>
> I've spoken with Lincoln about this and there are two JIRAs (
> https://issues.jboss.org/browse/SEAMFORGE-280 and
> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate
> this via the JPA plugin or perhaps Seam Persistence plugin.
>
> Discuss.
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:22 p.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
Here's some additional feedback I received from a community member a while
back...to merge it into this thread.
(begin feedback)
...from being burned from 3 seam based customers with apps and maintenance.
The "Home" or any other name should be just be put into a grave and slowly
cast away to sea ;). It is too heavy and complicated and just about
anything inherited (extends) truly causes heartache[Favor Composition over
inheritance: Effective Java]. The current seam home has a few super classes
above the home and when you try to unit test it (the standard definition of
unit-testing including isolation) you get the "No Active Application Context
Found (if I remember it right). That happens because it is tightly coupled
with the application. But not to be hard on Home, I do realize the history
of the home object and know it was developed when EL had no parameters. So I
have learned a lot since then and I here are some things that I can impart
to Seam 3.
1. My "Home" now is a "ServiceBean", and I have one for each
"Major" entity,
see below. I have really stewed over this over months and months, and the
"Home" of "ServiceBean" should be kept small, focused, reusable,
tested and
untouched. It's only task is to update, persist, possibly remove, or some
other functions that are required. In my example below I have custom close
action. Notice also that although these beans are stateful that doesn't
mean everything should be, so in these methods I have the parameter of what
is being needed to be updated, and not a field. In other words I don't have
@In private Job job, I opted for public boolean update(job). Mostly
because, again, I want to make this service bean reusable so whether I have
a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I
need to work on I only need one jobServiceBean to cater to all my jobs, in
whatever conversation I am using. I also fire events from here if I need to
do that. After this is tested, and what I need I usually don't touch it
anymore. If I need to enhance I either use a decorator pattern around it,
or enhance it in an @Observer. I'll email about that later.
@Name("jobServiceBean")
@Scope(ScopeType.CONVERSATION)
public class JobServiceBean implements JobService {
private EntityManager entityManager;
private StatusMessages statusMessages;
@In
public void setEntityManager(EntityManager entityManager) {
this.entityManager = entityManager;
}
@In
public void setStatusMessages(StatusMessages statusMessages) {
this.statusMessages = statusMessages;
}
public boolean update(Job job) {
this.entityManager.flush();
this.statusMessages.add(StatusMessage.Severity.INFO<http://statusmessage.severity.info/>,
"Successfully updated job {0}", job.getName());
return true;
}
public boolean close(Job job) {
job.setJobStatus(JobStatus.CLOSED);
this.entityManager.flush();
this.statusMessages.add(StatusMessage.Severity.INFO<http://statusmessage.severity.info/>,
"Successfully closed job {0}", job.getName());
return true;
}
}
2. One thing you may have noticed from above that there is no 'instance'
field with corresponding getters or setters like the old 'Home'. So the
ServiceBean in my case is not a full crud, but CUD + your own business
methods. That's because that too should be decoupled because we never know
the source of the object is. Is the object created from a factory? from a
copy? is it a mapped component, a managed component? Creation of objects or
loading of objects, or the manufacturing of objects from factories should be
separate from the "home" or in my case the "ServiceBean".
(end feedback)
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
9:52 a.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
just one comment:
Calling .flush() on every alteration really should not be promoted as a good practice.
/max
On Sep 22, 2011, at 24:22, Dan Allen wrote:
Here's some additional feedback I received from a community
member a while back...to merge it into this thread.
(begin feedback)
...from being burned from 3 seam based customers with apps and maintenance. The
"Home" or any other name should be just be put into a grave and slowly cast away
to sea ;). It is too heavy and complicated and just about anything inherited (extends)
truly causes heartache[Favor Composition over inheritance: Effective Java]. The current
seam home has a few super classes above the home and when you try to unit test it (the
standard definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it is tightly
coupled with the application. But not to be hard on Home, I do realize the history of the
home object and know it was developed when EL had no parameters. So I have learned a lot
since then and I here are some things that I can impart to Seam 3.
1. My "Home" now is a "ServiceBean", and I have one for each
"Major" entity, see below. I have really stewed over this over months and
months, and the "Home" of "ServiceBean" should be kept small, focused,
reusable, tested and untouched. It's only task is to update, persist, possibly
remove, or some other functions that are required. In my example below I have custom
close action. Notice also that although these beans are stateful that doesn't mean
everything should be, so in these methods I have the parameter of what is being needed to
be updated, and not a field. In other words I don't have @In private Job job, I opted
for public boolean update(job). Mostly because, again, I want to make this service bean
reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever
component of job I need to work on I only need one jobServiceBean to cater to all my jobs,
in whatever conversation I am using. I also fire events from here if I need to do that.
After this is tested, and what I need I usually don't touch it anymore. If I need to
enhance I either use a decorator pattern around it, or enhance it in an @Observer.
I'll email about that later.
@Name("jobServiceBean")
@Scope(ScopeType.CONVERSATION)
public class JobServiceBean implements JobService {
private EntityManager entityManager;
private StatusMessages statusMessages;
@In
public void setEntityManager(EntityManager entityManager) {
this.entityManager = entityManager;
}
@In
public void setStatusMessages(StatusMessages statusMessages) {
this.statusMessages = statusMessages;
}
public boolean update(Job job) {
this.entityManager.flush();
this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated
job {0}", job.getName());
return true;
}
public boolean close(Job job) {
job.setJobStatus(JobStatus.CLOSED);
this.entityManager.flush();
this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed
job {0}", job.getName());
return true;
}
}
2. One thing you may have noticed from above that there is no 'instance' field
with corresponding getters or setters like the old 'Home'. So the ServiceBean in
my case is not a full crud, but CUD + your own business methods. That's because that
too should be decoupled because we never know the source of the object is. Is the object
created from a factory? from a copy? is it a mapped component, a managed component?
Creation of objects or loading of objects, or the manufacturing of objects from factories
should be separate from the "home" or in my case the "ServiceBean".
(end feedback)
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
/max
http://about.me/maxandersen
12:12 p.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
Exactly. flush() has a specific purpose and really doesn't belong in
boilerplate code.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers and developers
On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
wrote:
just one comment:
Calling .flush() on every alteration really should not be promoted as a
good
practice.
/max
On Sep 22, 2011, at 24:22, Dan Allen wrote:
> Here's some additional feedback I received from a community member a
while
back...to merge it into this thread.
>
> (begin feedback)
>
> ...from being burned from 3 seam based customers with apps and
maintenance. The
"Home" or any other name should be just be put into a grave
and slowly cast away to sea ;). It is too heavy and complicated and just
about anything inherited (extends) truly causes heartache[Favor Composition
over inheritance: Effective Java]. The current seam home has a few super
classes above the home and when you try to unit test it (the standard
definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it
is tightly coupled with the application. But not to be hard on Home, I do
realize the history of the home object and know it was developed when EL had
no parameters. So I have learned a lot since then and I here are some things
that I can impart to Seam 3.
>
> 1. My "Home" now is a "ServiceBean", and I have one for each
"Major"
entity, see below. I have really stewed over this over months and
months,
and the "Home" of "ServiceBean" should be kept small, focused,
reusable,
tested and untouched. It's only task is to update, persist, possibly remove,
or some other functions that are required. In my example below I have custom
close action. Notice also that although these beans are stateful that
doesn't mean everything should be, so in these methods I have the parameter
of what is being needed to be updated, and not a field. In other words I
don't have @In private Job job, I opted for public boolean update(job).
Mostly because, again, I want to make this service bean reusable so whether
I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of
job I need to work on I only need one jobServiceBean to cater to all my
jobs, in whatever conversation I am using. I also fire events from here if I
need to do that. !
After this is tested, and what I need I usually don't touch it
anymore. If
I need to enhance I either use a decorator pattern around it, or enhance
it
in an @Observer. I'll email about that later.
>
> @Name("jobServiceBean")
> @Scope(ScopeType.CONVERSATION)
> public class JobServiceBean implements JobService {
> private EntityManager entityManager;
> private StatusMessages statusMessages;
>
> @In
> public void setEntityManager(EntityManager entityManager) {
> this.entityManager = entityManager;
> }
>
> @In
> public void setStatusMessages(StatusMessages statusMessages) {
> this.statusMessages = statusMessages;
> }
>
> public boolean update(Job job) {
> this.entityManager.flush();
> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
updated
job {0}", job.getName());
> return true;
> }
>
> public boolean close(Job job) {
> job.setJobStatus(JobStatus.CLOSED);
> this.entityManager.flush();
> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed
job {0}", job.getName());
> return true;
> }
> }
>
> 2. One thing you may have noticed from above that there is no 'instance'
field with corresponding getters or setters like the old 'Home'. So the
ServiceBean in my case is not a full crud, but CUD + your own business
methods. That's because that too should be decoupled because we never know
the source of the object is. Is the object created from a factory? from a
copy? is it a mapped component, a managed component? Creation of objects or
loading of objects, or the manufacturing of objects from factories should be
separate from the "home" or in my case the "ServiceBean".
>
> (end feedback)
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
/max
http://about.me/maxandersen
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
8:32 a.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
Sorry for not being able to post my gist. After writting some "sketches", I
realized that I don't have it very clear in my mind yet.
just to move from zero I posted something:
https://gist.github.com/1245041
It's a really simple example on how we could avoid inheritance, but it's
not contemplating a lot of needed features,
so I'm not even near to be convinced with that gist.
btw, the @AutoHome approach seems very nice.
On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Exactly. flush() has a specific purpose and really doesn't belong
in
boilerplate code.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers and developers
On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen"
<max.andersen(a)redhat.com>
wrote:
> just one comment:
>
> Calling .flush() on every alteration really should not be promoted as a
good practice.
>
> /max
>
> On Sep 22, 2011, at 24:22, Dan Allen wrote:
>
>> Here's some additional feedback I received from a community member a
while back...to merge it into this thread.
>>
>> (begin feedback)
>>
>> ...from being burned from 3 seam based customers with apps and
maintenance. The "Home" or any other name should be just be put into a grave
and slowly cast away to sea ;). It is too heavy and complicated and just
about anything inherited (extends) truly causes heartache[Favor Composition
over inheritance: Effective Java]. The current seam home has a few super
classes above the home and when you try to unit test it (the standard
definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it
is tightly coupled with the application. But not to be hard on Home, I do
realize the history of the home object and know it was developed when EL had
no parameters. So I have learned a lot since then and I here are some things
that I can impart to Seam 3.
>>
>> 1. My "Home" now is a "ServiceBean", and I have one for each
"Major"
entity, see below. I have really stewed over this over months and months,
and the "Home" of "ServiceBean" should be kept small, focused,
reusable,
tested and untouched. It's only task is to update, persist, possibly remove,
or some other functions that are required. In my example below I have custom
close action. Notice also that although these beans are stateful that
doesn't mean everything should be, so in these methods I have the parameter
of what is being needed to be updated, and not a field. In other words I
don't have @In private Job job, I opted for public boolean update(job).
Mostly because, again, I want to make this service bean reusable so whether
I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of
job I need to work on I only need one jobServiceBean to cater to all my
jobs, in whatever conversation I am using. I also fire events from here if I
need to do that. !
> After this is tested, and what I need I usually don't touch it anymore.
If I need to enhance I either use a decorator pattern around it, or enhance
it in an @Observer. I'll email about that later.
>>
>> @Name("jobServiceBean")
>> @Scope(ScopeType.CONVERSATION)
>> public class JobServiceBean implements JobService {
>> private EntityManager entityManager;
>> private StatusMessages statusMessages;
>>
>> @In
>> public void setEntityManager(EntityManager entityManager) {
>> this.entityManager = entityManager;
>> }
>>
>> @In
>> public void setStatusMessages(StatusMessages statusMessages) {
>> this.statusMessages = statusMessages;
>> }
>>
>> public boolean update(Job job) {
>> this.entityManager.flush();
>> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
updated job {0}", job.getName());
>> return true;
>> }
>>
>> public boolean close(Job job) {
>> job.setJobStatus(JobStatus.CLOSED);
>> this.entityManager.flush();
>> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
closed job {0}", job.getName());
>> return true;
>> }
>> }
>>
>> 2. One thing you may have noticed from above that there is no
'instance'
field with corresponding getters or setters like the old 'Home'. So the
ServiceBean in my case is not a full crud, but CUD + your own business
methods. That's because that too should be decoupled because we never know
the source of the object is. Is the object created from a factory? from a
copy? is it a mapped component, a managed component? Creation of objects or
loading of objects, or the manufacturing of objects from factories should be
separate from the "home" or in my case the "ServiceBean".
>>
>> (end feedback)
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
10:57 a.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
I prefer the idea that there's a class that manages one instance and that's all it
does, and another object (or objects) to handle collections of those objects. I think
separating them out makes for better reusability. If we'd like to have a save method
I'm okay with that, but don't really see the need.
Sent from my iPhone
On Sep 27, 2011, at 7:32, José Rodolfo Freitas <joserodolfo.freitas(a)gmail.com>
wrote:
Sorry for not being able to post my gist. After writting some
"sketches", I realized that I don't have it very clear in my mind yet.
just to move from zero I posted something:
https://gist.github.com/1245041
It's a really simple example on how we could avoid inheritance, but it's not
contemplating a lot of needed features,
so I'm not even near to be convinced with that gist.
btw, the @AutoHome approach seems very nice.
On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Exactly. flush() has a specific purpose and really doesn't belong in boilerplate
code.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers and developers
On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
wrote:
> just one comment:
>
> Calling .flush() on every alteration really should not be promoted as a good
practice.
>
> /max
>
> On Sep 22, 2011, at 24:22, Dan Allen wrote:
>
>> Here's some additional feedback I received from a community member a while
back...to merge it into this thread.
>>
>> (begin feedback)
>>
>> ...from being burned from 3 seam based customers with apps and maintenance. The
"Home" or any other name should be just be put into a grave and slowly cast away
to sea ;). It is too heavy and complicated and just about anything inherited (extends)
truly causes heartache[Favor Composition over inheritance: Effective Java]. The current
seam home has a few super classes above the home and when you try to unit test it (the
standard definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it is tightly
coupled with the application. But not to be hard on Home, I do realize the history of the
home object and know it was developed when EL had no parameters. So I have learned a lot
since then and I here are some things that I can impart to Seam 3.
>>
>> 1. My "Home" now is a "ServiceBean", and I have one for each
"Major" entity, see below. I have really stewed over this over months and
months, and the "Home" of "ServiceBean" should be kept small, focused,
reusable, tested and untouched. It's only task is to update, persist, possibly remove,
or some other functions that are required. In my example below I have custom close action.
Notice also that although these beans are stateful that doesn't mean everything should
be, so in these methods I have the parameter of what is being needed to be updated, and
not a field. In other words I don't have @In private Job job, I opted for public
boolean update(job). Mostly because, again, I want to make this service bean reusable so
whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I
need to work on I only need one jobServiceBean to cater to all my jobs, in whatever
conversation I am using. I also fire events from here if I need to do that. !
> After this is tested, and what I need I usually don't touch it anymore. If I
need to enhance I either use a decorator pattern around it, or enhance it in an @Observer.
I'll email about that later.
>>
>> @Name("jobServiceBean")
>> @Scope(ScopeType.CONVERSATION)
>> public class JobServiceBean implements JobService {
>> private EntityManager entityManager;
>> private StatusMessages statusMessages;
>>
>> @In
>> public void setEntityManager(EntityManager entityManager) {
>> this.entityManager = entityManager;
>> }
>>
>> @In
>> public void setStatusMessages(StatusMessages statusMessages) {
>> this.statusMessages = statusMessages;
>> }
>>
>> public boolean update(Job job) {
>> this.entityManager.flush();
>> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated
job {0}", job.getName());
>> return true;
>> }
>>
>> public boolean close(Job job) {
>> job.setJobStatus(JobStatus.CLOSED);
>> this.entityManager.flush();
>> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed
job {0}", job.getName());
>> return true;
>> }
>> }
>>
>> 2. One thing you may have noticed from above that there is no 'instance'
field with corresponding getters or setters like the old 'Home'. So the
ServiceBean in my case is not a full crud, but CUD + your own business methods. That's
because that too should be decoupled because we never know the source of the object is. Is
the object created from a factory? from a copy? is it a mapped component, a managed
component? Creation of objects or loading of objects, or the manufacturing of objects from
factories should be separate from the "home" or in my case the
"ServiceBean".
>>
>> (end feedback)
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
11:55 a.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
don't use save or saveOrUpdate - those are old Hibernate API methods which doesn't
do the same as what update/persist does.
The semantics are similar but different enough to not overload the words since it requires
a different usage of the API.
My 2 cents ;)
/max
On Sep 27, 2011, at 17:57, Jason Porter wrote:
I prefer the idea that there's a class that manages one instance
and that's all it does, and another object (or objects) to handle collections of those
objects. I think separating them out makes for better reusability. If we'd like to
have a save method I'm okay with that, but don't really see the need.
Sent from my iPhone
On Sep 27, 2011, at 7:32, José Rodolfo Freitas <joserodolfo.freitas(a)gmail.com>
wrote:
> Sorry for not being able to post my gist. After writting some "sketches", I
realized that I don't have it very clear in my mind yet.
>
> just to move from zero I posted something:
>
> https://gist.github.com/1245041
>
> It's a really simple example on how we could avoid inheritance, but it's not
contemplating a lot of needed features,
> so I'm not even near to be convinced with that gist.
>
> btw, the @AutoHome approach seems very nice.
>
>
> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> Exactly. flush() has a specific purpose and really doesn't belong in boilerplate
code.
>
> - Dan Allen
>
> Sent from my Android-powered phone:
> An open platform for carriers, consumers and developers
>
> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen"
<max.andersen(a)redhat.com> wrote:
> > just one comment:
> >
> > Calling .flush() on every alteration really should not be promoted as a good
practice.
> >
> > /max
> >
> > On Sep 22, 2011, at 24:22, Dan Allen wrote:
> >
> >> Here's some additional feedback I received from a community member a
while back...to merge it into this thread.
> >>
> >> (begin feedback)
> >>
> >> ...from being burned from 3 seam based customers with apps and maintenance.
The "Home" or any other name should be just be put into a grave and slowly cast
away to sea ;). It is too heavy and complicated and just about anything inherited
(extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The
current seam home has a few super classes above the home and when you try to unit test it
(the standard definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it is tightly
coupled with the application. But not to be hard on Home, I do realize the history of the
home object and know it was developed when EL had no parameters. So I have learned a lot
since then and I here are some things that I can impart to Seam 3.
> >>
> >> 1. My "Home" now is a "ServiceBean", and I have one for
each "Major" entity, see below. I have really stewed over this over months and
months, and the "Home" of "ServiceBean" should be kept small, focused,
reusable, tested and untouched. It's only task is to update, persist, possibly remove,
or some other functions that are required. In my example below I have custom close action.
Notice also that although these beans are stateful that doesn't mean everything should
be, so in these methods I have the parameter of what is being needed to be updated, and
not a field. In other words I don't have @In private Job job, I opted for public
boolean update(job). Mostly because, again, I want to make this service bean reusable so
whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I
need to work on I only need one jobServiceBean to cater to all my jobs, in whatever
conversation I am using. I also fire events from here if I need to do that. !
> > After this is tested, and what I need I usually don't touch it anymore. If I
need to enhance I either use a decorator pattern around it, or enhance it in an @Observer.
I'll email about that later.
> >>
> >> @Name("jobServiceBean")
> >> @Scope(ScopeType.CONVERSATION)
> >> public class JobServiceBean implements JobService {
> >> private EntityManager entityManager;
> >> private StatusMessages statusMessages;
> >>
> >> @In
> >> public void setEntityManager(EntityManager entityManager) {
> >> this.entityManager = entityManager;
> >> }
> >>
> >> @In
> >> public void setStatusMessages(StatusMessages statusMessages) {
> >> this.statusMessages = statusMessages;
> >> }
> >>
> >> public boolean update(Job job) {
> >> this.entityManager.flush();
> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
updated job {0}", job.getName());
> >> return true;
> >> }
> >>
> >> public boolean close(Job job) {
> >> job.setJobStatus(JobStatus.CLOSED);
> >> this.entityManager.flush();
> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully
closed job {0}", job.getName());
> >> return true;
> >> }
> >> }
> >>
> >> 2. One thing you may have noticed from above that there is no
'instance' field with corresponding getters or setters like the old
'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own
business methods. That's because that too should be decoupled because we never know
the source of the object is. Is the object created from a factory? from a copy? is it a
mapped component, a managed component? Creation of objects or loading of objects, or the
manufacturing of objects from factories should be separate from the "home" or in
my case the "ServiceBean".
> >>
> >> (end feedback)
> >>
> >> --
> >> Dan Allen
> >> Principal Software Engineer, Red Hat | Author of Seam in Action
> >> Registered Linux User #231597
> >>
> >> http://www.google.com/profiles/dan.j.allen#about
> >> http://mojavelinux.com
> >> http://mojavelinux.com/seaminaction
> >>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> > /max
> > http://about.me/maxandersen
> >
> >
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
/max
http://about.me/maxandersen
11:59 a.m.
New subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3
good point.
Naming was not my focus here though, it was just a quick example.
On Tue, Sep 27, 2011 at 1:55 PM, Max Rydahl Andersen <
max.andersen(a)redhat.com> wrote:
don't use save or saveOrUpdate - those are old Hibernate API
methods which
doesn't do the same as what update/persist does.
The semantics are similar but different enough to not overload the words
since it requires a different usage of the API.
My 2 cents ;)
/max
On Sep 27, 2011, at 17:57, Jason Porter wrote:
> I prefer the idea that there's a class that manages one instance and
that's all it does, and another object (or objects) to handle collections of
those objects. I think separating them out makes for better reusability. If
we'd like to have a save method I'm okay with that, but don't really see the
need.
>
> Sent from my iPhone
>
> On Sep 27, 2011, at 7:32, José Rodolfo Freitas <
joserodolfo.freitas(a)gmail.com> wrote:
>
>> Sorry for not being able to post my gist. After writting some
"sketches", I realized that I don't have it very clear in my mind yet.
>>
>> just to move from zero I posted something:
>>
>> https://gist.github.com/1245041
>>
>> It's a really simple example on how we could avoid inheritance, but
it's not contemplating a lot of needed features,
>> so I'm not even near to be convinced with that gist.
>>
>> btw, the @AutoHome approach seems very nice.
>>
>>
>> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <dan.j.allen(a)gmail.com>
wrote:
>> Exactly. flush() has a specific purpose and really doesn't belong in
boilerplate code.
>>
>> - Dan Allen
>>
>> Sent from my Android-powered phone:
>> An open platform for carriers, consumers and developers
>>
>> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" <
max.andersen(a)redhat.com> wrote:
>> > just one comment:
>> >
>> > Calling .flush() on every alteration really should not be promoted as
a good practice.
>> >
>> > /max
>> >
>> > On Sep 22, 2011, at 24:22, Dan Allen wrote:
>> >
>> >> Here's some additional feedback I received from a community member
a
while back...to merge it into this thread.
>> >>
>> >> (begin feedback)
>> >>
>> >> ...from being burned from 3 seam based customers with apps and
maintenance. The "Home" or any other name should be just be put into a grave
and slowly cast away to sea ;). It is too heavy and complicated and just
about anything inherited (extends) truly causes heartache[Favor Composition
over inheritance: Effective Java]. The current seam home has a few super
classes above the home and when you try to unit test it (the standard
definition of unit-testing including isolation) you get the "No Active
Application Context Found (if I remember it right). That happens because it
is tightly coupled with the application. But not to be hard on Home, I do
realize the history of the home object and know it was developed when EL had
no parameters. So I have learned a lot since then and I here are some things
that I can impart to Seam 3.
>> >>
>> >> 1. My "Home" now is a "ServiceBean", and I have one
for each "Major"
entity, see below. I have really stewed over this over months and months,
and the "Home" of "ServiceBean" should be kept small, focused,
reusable,
tested and untouched. It's only task is to update, persist, possibly remove,
or some other functions that are required. In my example below I have custom
close action. Notice also that although these beans are stateful that
doesn't mean everything should be, so in these methods I have the parameter
of what is being needed to be updated, and not a field. In other words I
don't have @In private Job job, I opted for public boolean update(job).
Mostly because, again, I want to make this service bean reusable so whether
I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of
job I need to work on I only need one jobServiceBean to cater to all my
jobs, in whatever conversation I am using. I also fire events from here if I
need to do that. !
>> > After this is tested, and what I need I usually don't touch it
anymore. If I need to enhance I either use a decorator pattern around it, or
enhance it in an @Observer. I'll email about that later.
>> >>
>> >> @Name("jobServiceBean")
>> >> @Scope(ScopeType.CONVERSATION)
>> >> public class JobServiceBean implements JobService {
>> >> private EntityManager entityManager;
>> >> private StatusMessages statusMessages;
>> >>
>> >> @In
>> >> public void setEntityManager(EntityManager entityManager) {
>> >> this.entityManager = entityManager;
>> >> }
>> >>
>> >> @In
>> >> public void setStatusMessages(StatusMessages statusMessages) {
>> >> this.statusMessages = statusMessages;
>> >> }
>> >>
>> >> public boolean update(Job job) {
>> >> this.entityManager.flush();
>> >> this.statusMessages.add(StatusMessage.Severity.INFO,
"Successfully
updated job {0}", job.getName());
>> >> return true;
>> >> }
>> >>
>> >> public boolean close(Job job) {
>> >> job.setJobStatus(JobStatus.CLOSED);
>> >> this.entityManager.flush();
>> >> this.statusMessages.add(StatusMessage.Severity.INFO,
"Successfully
closed job {0}", job.getName());
>> >> return true;
>> >> }
>> >> }
>> >>
>> >> 2. One thing you may have noticed from above that there is no
'instance' field with corresponding getters or setters like the old
'Home'.
So the ServiceBean in my case is not a full crud, but CUD + your own
business methods. That's because that too should be decoupled because we
never know the source of the object is. Is the object created from a
factory? from a copy? is it a mapped component, a managed component?
Creation of objects or loading of objects, or the manufacturing of objects
from factories should be separate from the "home" or in my case the
"ServiceBean".
>> >>
>> >> (end feedback)
>> >>
>> >> --
>> >> Dan Allen
>> >> Principal Software Engineer, Red Hat | Author of Seam in Action
>> >> Registered Linux User #231597
>> >>
>> >> http://www.google.com/profiles/dan.j.allen#about
>> >> http://mojavelinux.com
>> >> http://mojavelinux.com/seaminaction
>> >>
>> >> _______________________________________________
>> >> forge-dev mailing list
>> >> forge-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> > /max
>> > http://about.me/maxandersen
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
/max
http://about.me/maxandersen
4804
days inactive
4811
days old
7 comments
4 participants
participants (4)
-
Dan Allen -
Jason Porter -
José Rodolfo Freitas -
Max Rydahl Andersen