Hi Derek,
I understand your dilemma as I'm not a Java developer by any stretch.
One of the good things about Cocoon is that it allows you to achieve an
objective in many ways.
One of the bad things about Cocoon is that it allows you to achieve an
objective in many ways!
I think the task for most newcomers is to work out the best way to
achieve these objectives in a manner which suits their abilities/time
constraints etc.
When I started coding my first database driven Cocoon app I turned to
the good old Petstore demo application. This was fine until I started
getting right into it and found that I'd jumped in too deep at the
outset (as its pretty complicated to a rank beginner).
What it does show is what can be achieved with flow and cforms alone.
I for one do all my database access through flow BUT I'm aware of its
limitations in terms of scalability and robustness and mixing of concerns.
For the more modest sized applications I find it a great RAD tool.
As it is, we have to ramp a project I'm currently working on up a notch
or two and I find that I'm bumping up against the inclusion of Hibernate
(or Torque or Cayenne etc). What I'm hoping for is that some of my more
Java savvy colleagues at work will be providing me with the DAOs that I
need to do my work (separation of concerns!).
Here's a quick example of how I do databases in flow:
var model = userForm.getModel();
var narNum = model.narNum;
var userName = getUserNarDetails(narNum);
/***********************************************/
function getUserNarDetails(narNum){
var sSql = "";
//Get person details for selected nar_num (read only)
sSql = "SELECT blah from tblBlah where nar_num = " + narNum;
var userNarDetailsRecs = runSQL(sSql);
if((userNarDetailsRecs == null) || (userNarDetailsRecs[0] == null)){
print("No records found in aunrmast)");
message = "No user details found in aunrmast.";
return null;
} else {
return userNarDetailsRecs[0];
}
}
/*********************************************/
function runSQL (psSql){
try {
var result = gDbConn.query(psSql);
} catch (error) {
message = "Error running sql: " + error;
setMessage(message);
print(message);
return null;
}
var resultRows = result.rows;
result.close;
return resultRows;
}
I don't know if this clarifies things or adds to the confusions but I
just thought I'd share!!!
Regards
Tony
Derek Hohls wrote:
Upayavira
I agree with what you say... more than that, I think we should
offer some guidelines as to what constitutes a reasonable cut-off:
I think you're being too modest ito of what can be achieved with
the Java-less route... surely we could extend the sample shown
to allow for filling in forms, adding new records, etc. and keeping
a moderate -sized database (<20 tables?) up-to-date?
Also, if we are going to recommend people really go the OJB /
Hibernate route, then do we not need to demonstrate exactly
how AND where those options fit in with Cocoon, and why one
should use Cocoon as the publishing framework (as opposed to
Struts or even PHP)?
Derek
[EMAIL PROTECTED] 2005/06/15 01:58:14 PM >>>
WHIRLYCOTT wrote:
Askild Aaberg Olsen wrote:
Why is tightly coupling my data access code to Hibernate so much
better then, isn't this yet another framework (like EJBs)?
What if I don't have the need to reuse this code?
What if I'm just a newbie trying to get some data into my webapp?
I should clarify that I'm not necessarily advocating Hibernate or OJB,
because those two particular solutions come with baggage.
What I would recommend is wrapping all of those implementation details
behind DAOs. This way, you're not coupling your application logic to
anything but your own DAOs.
How does one does this in a reusable way while using modular database
actions or the SQL transformer? The answer is that you can't. And that
makes it a bad idea.
Take someone who has a small database of products, and just wants to put
that online. No ecommerce, just a simple publication, maybe with the
option to select some items and send an email with the chosen items listed.
And they're doing it as a favour to their mum.
Now, are you saying that they need to wrap that small database with
DAOs, and then embed hibernate or OJB into those DAOs, and set up all of
the database mappings, and so on, just for this small site? I think
they'll be using PHP pretty quickly at that rate.
I never argued Hibernate/OJB wrong or bad practive, I just outlined an
alternative method to get a simple db-driven app up and running using
a stock Cocoon, without the need to write a single line of Java-code
(not using modular db actions, by the way...).
I'm not sure what the value of this is. This approach seems like it
will get you 20% of the way to something useful really quickly.
The point is, there are different people using Cocoon for different
things. We need a lightweight way to integrate SQL and Cocoon forms. And
on the documentation about it it should say "this is only suitable for
_very_ small sites, and will become impractial quickly. You are
recommended to look at hibernate, or OJB (see the OJB block) and use
Java code to create more scalable and maintainable applications".
As I see it, there's a case for both approaches. Just that we only cater
for the heavyweight approach right now.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
