cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: AW: CForms and Modular Database Actions
Date Mon, 20 Jun 2005 06:07:00 GMT
Tony

Thanks for sharing that... it *always* helps to see code.  But
(there's always a but!) all the samples that I have seen tend to
be either very simple (selects only) or highly intricate... and very
hard to establish how they were built -up.  The ideal approach 
would match a draft I put on the wiki site for learning Hibernate:
a graduated set of samples, each either dealing with a specialist
area, or building up on what has gone before - either way you get
to be able to assimilate reasonable (but very useful and workable)
chunks of information... leading in the end to a complete (but
understandable) solution.  Oh well, I can but dream.

Derek

>>> tedwards@civica.com.au 2005/06/16 02:48:11 AM >>>
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
>
>  
>
>>>>uv@odoko.co.uk 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: users-unsubscribe@cocoon.apache.org 
>For additional commands, e-mail: users-help@cocoon.apache.org 
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org 
>For additional commands, e-mail: users-help@cocoon.apache.org 
>
>
>  
>

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


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


Mime
View raw message