Andrew C. Oliver wrote:
Being the big moron I am, I don't see any of these issues to be asA good project, I think it was the passed over db.apache project would be to unify the persistence API.
important as: 1. Do they develop in "the apache way", 2. Is it a
vibrant robust community, 3. Is there any point at all. . .
I see little point in having 30 persistence APIs or 30 connection pools,
etc...apparently some people do... But 5 web app frameworks even if
they are all "pull" seems reasonable... There are certainly MORE than 5
ways to roll a webapp.... (even if I haven't found one I actually like
yet...)
Similar to commons logging API.
Like a DAO api that lets you implement in any of the 30 way (same as one should be able to change the presentation layer, one should be able to change the persistence layer)
I tried to do this with:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/commons/DAO/BasicDAO.java?rev=1.2&content-type=text/vnd.viewcvs-markup
but I do not have the clout of Jakarta.
If we can come up with a persistence API that is the lowest common denominator for all API.... that would be real nice.
Also JSF currently has a "model expression interfaces" or something like that it requires of DAO, but induced that JDO, ORB, Simper, RowSet, EJB, Torqe, Castor, Scaffolding, Doclets, etc. etc.
So if we can have a small JAKARTA api that we encourage all subprojects to implement, but make it light, one ex:
public interface BasicDAO extends Iterator (or Collection)
{
public void retrieve(long i) throws Exception;
public void update() throws Exception;
public void insertRow() throws Exception;
public void delete() throws Exception;
public boolean setProperty(String name, Object value) throws Exception;
public Object getProperty(String name) throws Exception;
public void beforeFirst() throws Exception;
public void first() throws Exception;
public void commit() throws Exception;
public void rollback() throws Exception;
}
I have a SourceForge project that needs to use RowSet, or JDO persistence, and I am using this, but...
Anyway, I wish, I wish....
.V
-AndyOn Sat, 2002-10-19 at 20:31, John McNally wrote:I have taken a closer look at Tapestry and it does provide a quite a different strategy for web application development than Turbine and probably also Struts. It's very well documented and the code looks well written also. I would be willing to drop my -1; I would like to hear a comparison with the failed spfc project though. <http://cvs.apache.org/viewcvs.cgi/java-spfc/docs/index.html?rev=1.10&content-type=text/vnd.viewcvs-markup> It seems like a similar idea, or am I wrong? I liked the idea of spfc. Though the change in perspective needed to think of a webapp in terms of event driven components was considered too great a stretch, I guess. Is such an approach gaining more acceptance, or have I missed the point of Tapestry? john mcnally On Sat, 2002-10-19 at 16:22, Pier Fumagalli wrote:On 19/10/02 19:49, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:So could someone clarify that for me... We're here to promote community software development....as long as they don't overlap? sorry I totally misunderstood the apache way. (especially with all the overlapping projects to the contrary)I want to start a new project for a new Servlet Container that is not Tomcat! :-) Let's see how many fans I'm going to get! :-) Pier -- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>-- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>