Il giorno 26/gen/05, alle 22:44, JD Daniels ha scritto:
so I guess my next question would be : would you just forget having a
hibernate factory as a cocoon component? ie, just have yet another
class like package.hibernateFactoryImpl? see I'm thinking it is too
much overhead to be registering
Wait a minute ok I think I see now...
project/java
persistenceFactory.java - interface to cocoon's persistenceFactory,
methods createSession
HibernateFactory.java - implements persistenceFactory, methods
configure, service, initialize, dispose, createSession
Ok so far so good, when cocoon
As a preface, the Cocoon-users list is probably not the best place to
get Hibernate assistance, but here goes
JD Daniels wrote:
Wait a minute ok I think I see now...
project/java
persistenceFactory.java - interface to cocoon's persistenceFactory,
methods createSession
HibernateFactory.java
No, I'm not really writing another bug tracker. I have it so clients can
login and peek at the timesheets for what we have done including stuff
like printers, adsl etc etc. It is just a simple object so they can add
feature requests or fixes for whatever they need. They all hate having
to
Il giorno 27/gen/05, alle 15:16, JD Daniels ha scritto:
right? Or would it be better to have one class such as BugFacade with
all methods dealing with bugs? (save, find, delete etc)
Yes, that is usually preferrable. A class that deals with retrieving
and storing domain objects to a persitent
Ugo Cei wrote:
Il giorno 27/gen/05, alle 15:16, JD Daniels ha scritto:
right? Or would it be better to have one class such as BugFacade with
all methods dealing with bugs? (save, find, delete etc)
Yes, that is usually preferrable. A class that deals with retrieving
and storing domain objects
Heh heh what I want anyway.. still need to find a way to actually *do* it :S
WHIRLYCOTT wrote:
I think you've basically got the hang of this now.
phil.
JD Daniels wrote:
Ugo Cei wrote:
Il giorno 27/gen/05, alle 15:16, JD Daniels ha scritto:
right? Or would it be better to have one class such as
Il giorno 27/gen/05, alle 17:09, JD Daniels ha scritto:
What's changed WRT to the previous version? I can't see the
difference.
var bugSearch = new
Packages.com.kismetsoftware.insecticide.BugSearch();
var bean = bugSearch.findBugById(id);
Ah OK. I'll tell you a story :-) When we started using
+1 on that, Ugo.
JD, there's a decent O'Reilly book called Better, Faster, Lighter Java
or something like that. It covers a lot of the ideas that we have been
telling you about. It doesn't cover any Cocoon stuff, but the part you
are working on shouldn't care about that at all. You might
I sincerley appreciate the info you guys have shared with me :) thank you.
that was where i was stuck - I knew I had to separate my concerns, but
all the tutorials I found had a cocoon component dealing with hibernate
stuff. Hibernate itself is rather nice. I have been doing it for awhile
now
Hi all,
I am trying to add criteria inside a flowscript. Here is what i think
should work:
1var criteria = hs.createCriteria(Bug.class);
2 criteria.add(Expression.eq(status, UNCONFIRMED));
3var bug = criteria.list();
this spits out : missing name after . operator on line 1
I've run into this error before. This usually means that some
function used is a Javascript builtin function (or statement). So
odds are, either add() or eq() are functions or statements in
Javascript.
I ran into this problem with a Java method I called delete(). So I'm
guessing that your
Yeah thats the same problem I'm having I think - except it is the line
above it is dying on:
var criteria = hs[createCriteria](Bug[class]); - Identifier is a
reserved word
var criteria = hs[createCriteria](Bug.class); - missing name after .
operator
arg
Brent Johnson wrote:
I've run into
If you will allow me to offer to you a thought which is only slightly
related to your original question, I would strongly encourage you to
move all of that transactional persistence stuff behind a facade a for a
few reasons, listed in no particular order:
1) you'll be able to write junit tests
I agree - I always write objects specifically designed to be used in
flow that handle all the actual Hibernate calls. The great thing
about this is I can write test classes (or use JUnit as was suggested)
that test the classes themselves to make sure the Hibernate calls are
working correctly.
Il giorno 26/gen/05, alle 16:14, JD Daniels ha scritto:
1var criteria = hs.createCriteria(Bug.class);
2 criteria.add(Expression.eq(status, UNCONFIRMED));
3var bug = criteria.list();
this spits out : missing name after . operator on line 1
Simply use:
1var criteria =
On Wed, 2005-01-26 at 19:23, Brent Johnson wrote:
I've run into this error before. This usually means that some
function used is a Javascript builtin function (or statement). So
odds are, either add() or eq() are functions or statements in
Javascript.
I ran into this problem with a Java
WHIRLYCOTT wrote:
If you will allow me to offer to you a thought which is only slightly
related to your original question, I would strongly encourage you to
move all of that transactional persistence stuff behind a facade a for a
few reasons, listed in no particular order:
1) you'll be able to
I am at the start of a big ol project here heh heh. I would love to make
it so - I have made a class bugSearch, with methods to lookup by status,
etc, as well as take an example bean and do a full search by.
// Create The Form
var form = new Form(forms/bugSearchModel.xml);
Hibernate is concerned only with getting data into and out of a
relational database. As such, it's part of the 'M' in MVC. Your flow
code is the C part. It's job should be to route requests, map data back
and forth from forms to your facade, and generally to act as the glue
between the
20 matches
Mail list logo
