OpenToro 3.0 is a SourceForge project is web database publisher designed to create web applications that connect directly to a database. OpenToro dispenses the drudgery of having to use JSP and SQL that normal when one is implementing these types of forms based data driven web-based applications.

OpenToro supports the ability to list of database tables and their contents. It also can generate forms that can be used to insert, modify, or delete data. OpenToro works with any SQL-92 compatible database. It currently has been tested to support MySQL, Oracle, Access, and SQL-Server.

In addition to the tutorial, there is a flash demonstration that is avaliable for viewing.

Am I the only one that can't figure out the clever use of English in this post. I've read it 5 times now and am still trying to decipher what it says.

This particular Toro seems to be lacking in the cojones department even though the ability to list the database tables seems appealing. Is Bruce around ? We need him to predict if this will be the Next Big Thing.

This particular Toro seems to be lacking in the cojones department even though the ability to list the database tables seems appealing. Is Bruce around ? We need him to predict if this will be the Next Big Thing.

Typical Java snob attitude.. if it doesn't solve world hunger it sucks.. Maybe the project has more humble ambitions?

Maybe the project has more humble ambitions?

Probably. Note that I'm a full-blown snob, not just a Java snob. Excuse me for using a little dose of sarcasm on a serious site like TSS, but I just think it would be more worthwhile to tackle actual unsolved problems rather than re-invent the proverbial wheel for a problem that has been solved about a million times. Editing database tables ? Call me an Office snob, but I would use MS Access for that.

Editing database tables ? Call me an Office snob, but I would use MS Access for that.

I feel like doing the "beyond java" thing again but have to point out that this approach can be a good start of things. As long as there is a good way of customizing the screens it will save a lot of time as opposed to doing everything by hand. I think there is a huge grey area between a webbased db admin tool and doing it the hard way.

Hi Alain,

Again, We knows that OpenToro is not going to be the next big thing, and it's not going to bring us with the world peace, but I think that it is not exactly equal to other applications: the central idea behind OpenToro is applying Reflective Architectures to database maintenance instead of code generation ( http://www.moisesdaniel.com/wri/racg.html ).

When we build the first version, we were not able to find this type of applications (for this purpose) in java.

if you are interested in a RAD framework that speeds up the development of Web based database applications, i would like to recommend DbForms.

DbForms can be used to create comprehensive database forms, supporting features such as nested forms, client side input validation, sorting, etc. -- blending nicely with JSP and all other parts of the J2EE framework.

here is the web site:

http://jdbforms.sourceforge.net/

user manual can be found at sourceforge as well. Here are some other articles:

http://www.javaworld.com/javaworld/jw-09-2004/jw-0906-unicode_p.html
http://www.onjava.com/pub/a/onjava/2001/07/18/dbforms.html

PS: yes, i am involved in that project :-)

I have used DbForms a few years back and liked it a lot. How does Toro compare to DbForms?

cheers
romen

The central idea behind OpenToro is applying Reflective Architectures to database maintenance instead of code generation ( http://www.moisesdaniel.com/wri/racg.html ). With OpenToro you don't have to code almost nothing. It works like a black box component(with advantages and disadvantages).

I've seen in DBForms' tutorial that you finally, additionally to XML files describing the database, must to code something like this:
.....
<table border="5" width="60%" align="CENTER">
<tr>
<th>ID</th>
<th>Name</th>
<th>Description</th>
<th>Actions</th>
</tr>
</db:header>
<db:body>
<tr>
<td>
<db:textField fieldName="id" size="5"/>
</td>
<td>
<db:textField fieldName="name" size="20"
maxlength="30"/>
</td>
<td>
<db:textField fieldName="description" size="24"
maxlength="255"/>
</td>
<td>
<db:updateButton caption="Update"/>
<db:deleteButton caption="Delete"/>
</td>
</tr>
</db:body>
..........
And that dbforms can do code generation.

OpenToro only need the XML file, that you can basically generates with the web application.

Anyway, I like DbForms too, and at this moment, it have better documentation that us.

The logical conclusion of the RAD hype that has recently emerged. Let's just bypass even ROR and go straight to the database from the web page.

Pass.

The logical conclusion of the RAD hype that has recently emerged. Let's just bypass even ROR and go straight to the database from the web page.Pass.

I'm pretty sure this is just a Java PHPMyAdmin.

The logical conclusion of the RAD hype that has recently emerged. Let's just bypass even ROR and go straight to the database from the web page.Pass.

Well, it is not so crazy as it seems. How about this:

Do all the data access logic in stored procedures and create xml documents right from stored proc calls using DB xml features. Then style it with xslt right to the site as html. The control layer is only a hundred lines of Java code or so for the whole site. The whole site is updated when there are changes to the database using triggers. Session state is kept in a cookie, and all interactive pages are done entirely in Java script including the business logic.

I just know a guy who's thought process of building dynamic database driven sites is exactly like this. Strange? For him it makes perfect sense.

THIS IS the new that I posted yesterday:

OpenToro is a Web Database Publisher, a tool that allows us developing database-driven web applications in an agile and automatic way. Using OpenToro simply means to forget coding countless SQLs and JSPs every time we want to implement a web application with database access.
With Opentoro you will be able to easily:
* Listing Database Tables.
* Visualizing Records.
* Generating Forms for inserting, modifying and deleting records.

OpenToro Works with any SQL-92 compatible database, but if you want to use advanced features of some databases you can use (or develop) specific SQL Engines. OpenToro implements SQL Engines for the following databases:

* MySql.
* Oracle.
* Access.
* SQL-Server.

Do you want to take a fast look? Download the Video Tutorial (1091 kb).

____________________________

Ok, OpenToro is not going to be the next big thing, but I'm sure it is a useful tool.

There are a lot of ocasions where existing databases needs to be published in the web. OpenToro makes it easy.

There are some special characteristis of OpenToro:
 - It don't generates code, so you don't have to maintein code (saves money).
 - It is simple Java, so is easy to deploy, use, and modify. In addition, developers can use it with a medium java knowledge.
 - It has a integrated WebCache, so it is very, very fast.


We are working to develop a tag lib, and a set of JSF components, to make it easier to integrate with other frameworks.


Best Regards!

http://www.moisesdaniel.com

I repeat, this is not the new that I posted yesterday (please read my previous post: http://www.theserverside.com/news/thread.tss?thread_id=37321#189550 ).

TheServerSide.com must to change it.

OpenToro works with any SQL-92 compatible database. It currently has been tested to support MySQL, Oracle, Access, and SQL-Server

I'm not sure I understand why the restriction to SQL-92 compatible databases. There are JSRs for persistence that are either finalised or close to being finalised (JSR 243-JDO 2.0, JSR 220-EJB 3.0) that allow portable query languages, in addition to SQL, to be used to handle data stores and their contents. There are good open-source implementations of these JSRs (JPOX, OpenAccess, Hibernate). Use of these APIs would allow a very wide range of databases and stores to be supported, and the JSR-implementing products generally include schema analysing tools. A lot of work has been put into these JSRs and the products that implement them; it seems a waste not to make use of products that implement them, and their accompanying tools.

Hi Steve,
OpenToro 0.1 was released (not publicly) 3 years ago, so we didn't have the tools that you have mentioned.
We finally got a good SQL generator, so we have not changed the way OpenToro access databases.
Anyway, SQL generation have proportionated us a very simple advantage: all people knows SQL. So if you want to change it, or need special development you can do it easily.

We have tried to leave it simple.

In any case, we have discussed about JDO a lot of times, so perhaps we use it in the future.

Hi Steve,OpenToro 0.1 was released (not publicly) 3 years ago, so we didn't have the tools that you have mentioned.We finally got a good SQL generator, so we have not changed the way OpenToro access databases.Anyway, SQL generation have proportionated us a very simple advantage: all people knows SQL. So if you want to change it, or need special development you can do it easily.We have tried to leave it simple.In any case, we have discussed about JDO a lot of times, so perhaps we use it in the future.

It just seemed to me that it would give you a broader range of databases if you made use of the schema analysis tools and SQL generation capabilities of currently existing JDO 2.0 and EJB 3.0 tools. Targetting, for example, EJBQL (or JDOQL) rather than SQL 92 would potentially allow you to work with a very wide range of relational stores, making your product far more widely applicable.

Although I am a dedicated supporter of JDO, I would personally suggest you look at EJB 3.0, as you appear to be concentrating on relational databases.

Is this simialr to Access forms in functionality for web apps
Thanks,
Siva