hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: Help with Interfaces and services
Date Wed, 20 Jul 2005 17:30:22 GMT
Chris is a friend of mine and a fellow director of the Cincinnati Java Users
Group (www.cinjug.org) and he IS doing an amazing job!  Are you looking to
add in the validation stuff that rails includes by default (the
validates_length_of, validates_uniqueness_of, etc.)?  I think that would be
a great addition to Trails.  I'm a developer on the Trails project, but to
be honest I haven't had much time to devote to it, so I don't even know if
that sort of stuff is there or not yet.  I've started diving in recently,
though. 

-----Original Message-----
From: Vinicius Carvalho [mailto:java.vinicius@gmail.com] 
Sent: Wednesday, July 20, 2005 1:22 PM
To: hivemind-user@jakarta.apache.org
Subject: Re: Help with Interfaces and services

Thanks James I did not know that set-object could instantiate a fresh
object for me :D.

I did not make my self clear, sorry. Under the hood I'm using
Hibernate 3.0.5 + Annotations as well, and the cool Hibernate
Annotations validator. My framework (Well I rather not call it that)
only makes things easier, the idea is that you would map only the
pojos and the html templates for Tapestry, it'll do the rest (The
service, the daos, constraints checking) the only thing the developer
should do is the Business Logic (Business Rules are done by the
framework) and those logic should be a aspect ;). I know we have
similar stuff (Aka Trails) but so far it does not meet my
requirements. Just to makeit clear, I think Chris is doing an amazing
job ;)

On 7/20/05, James Carman <james@carmanconsulting.com> wrote:
> So, let me get this straight.  You have one DAO implementation class that
> basically acts upon a single persistent object.  So, your application is
> okay with only being able to operate upon a single persistent object per
> thread (you are using a threaded model for your persistent objects)?  What
I
> would do is make my DAOs threaded and have HiveMind inject a fresh
> persistent object into the DAO when it instantiates them...
> 
> <implementation service-id="CategoryDAO">
>   <invoke-factory>
>     <construct class="com.myco.dao.BaseDAO">
>       <set-object property="persistentObject"
> value="instance:com.myco.domain.Category" />
>     </construct>
>   </invoke-factory>
> </implementation>
> 
> Does that make sense to you?  By the way, why are you writing a CRUD
> framework and not using one that's pre-built for you (such as JDO or
> Hibernate)?  In my experience, it's just easier to go with an existing
> framework.  They've already encountered all of the pitfalls that you are
> going to encounter by trying to write it on your own.
> 
> -----Original Message-----
> From: Vinicius Carvalho [mailto:java.vinicius@gmail.com]
> Sent: Wednesday, July 20, 2005 10:47 AM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Help with Interfaces and services
> 
> Well I'm building a CRUD framework based on Tapestry 4, Hivemind,
> HiveUtils, AspectWerkz and Java 5 :D. I hope It will be a LGPL
> framework one day.
> 
> So here's the point:
> I have only one single DAO class on the entire framework (we already
> succesfully use this approach with spring here)
> On spring we create as many DAO beans as we want, they are all from
> the same type, but differ on their pojo injections. So ProductDAO and
> CategoryDAO would be the same the only difference is that one gets
> Product injected while the other gets Category, got it ;)
> 
> I'm trying to get rid of Spring (please don't understand it wrong, I
> love Spring, but I think Hivemind could handle the problem, so no need
> for spring).
> 
> Hence the need to have my persistent pojos managed by hivemind :D
> 
> PS: I chose AspectWerkz for the same reason, we used SpringAOP on our
> projects...
> 
> On 7/20/05, James Carman <james@carmanconsulting.com> wrote:
> > Why would you have HiveMind manage your persistent objects?
> >
> > -----Original Message-----
> > From: Vinicius Carvalho [mailto:java.vinicius@gmail.com]
> > Sent: Tuesday, July 19, 2005 8:20 PM
> > To: hivemind-user@jakarta.apache.org
> > Subject: Help with Interfaces and services
> >
> > Hello there! I was doing some tests here and found out that even
> > though hivemind no longer requires a interface I can't cast a service
> > to it's implementation class. Someone please correct me here.
> >
> > I have this scenario:
> >
> > <service-point id="produto"
> interface="com.cs.model.persistence.BaseEntity">
> >         <create-instance class="com.cs.model.persistence.Produto"
> > model="threaded"/>
> > </service-point>
> >
> > <service-point id="categoria"
> > interface="com.cs.model.persistence.BaseEntity">
> >         <create-instance class="com.cs.model.persistence.Categoria"
> > model="threaded"/>
> > </service-point>
> >
> > Well those are not "real" services, they're only persistent pojos that
> > I need hivemind to control for me (inject on my DAOs)
> >
> > Well, So I got this test case ok:
> >
> > public class ProdutoServiceTest extends HiveMindTestCase {
> >         private Registry registry;
> >         @Override
> >         protected void setUp() throws Exception {
> >                 registry =
buildFrameworkRegistry("/conf/hivemodule.xml");
> >         }
> >
> >         public void testInsert() throws Exception{
> >                 IProduto produto = (Produto)
> > registry.getService("com.cs.tcrud.produto",BaseEntity.class);
> >
> >         }
> >
> > Well I get an ClassCastException at this point. Well I know program to
> > interface is a good practice, but what about some implementation
> > specific methods? I'm 100% sure I'm doing something wrong ;) Could
> > someone give me a help on this?
> >
> > Thanks
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message