Home » Eclipse Projects » Eclipse Scout » Form Generator based on DB Table layout(Form Generator based on DB Table layout)
|
Re: Form Generator based on DB Table layout [message #900123 is a reply to message #899960] |
Sat, 04 August 2012 10:12 |
Jeremie Bresson Messages: 124 Registered: November 2010 |
Senior Member |
|
|
Thanks for asking the question (I think it is the first time, that it is asked on this forum).
I totally agree with you, having a such generator, would be a great tool for eclipse scout scout (even if, as you said, it is only used for a first raw version). I am not aware of a such tool for the moment, but I can imagine, that we are not the first developers that wonder if this possible.
Personally, I really would like to have time to investigate Eclipse EMF. To my mind, it is the only good approach for a such generator. The Modeling Platform of Eclipse provides a lots of greats tools (model to model transformation, model to text generator, different editors, tools to query or represent the model ...). If you do not use their tools, you are reinventing the wheel or you get a collection of generation scripts that will only work ones (for a specific problem).
For the moment, I am lacking of time to investigate EMF (there is a steep learning curve). I also need to clarify the perimeter of my project (the idea is not to rewrite the whole scout application model, or to write Xpand template that will do exactly the same as the Scout SDK wizard).
|
|
| | | | |
Re: Form Generator based on DB Table layout [message #1433739 is a reply to message #1433352] |
Mon, 29 September 2014 07:30 |
Dennis Geesen Messages: 46 Registered: June 2014 |
Member |
|
|
Hey,
I was also looking for something like that, but didn't found anything. I also investigated EMF, but in my opnion the handling was too complex for this scenario.
So, I've written some kind of a very simple tools to do some of the mentioned jobs:
a) A schema generator class, which is a description of the database schema. It automatically creates the sql statements including primary/foreign key constraints. This creates the tables into the database using simple "JDBC":
accounts = table("accounts",
column("account_id", Type.INTEGER, true, true, true),
column("name", Type.VARCHAR),
column("type_id", Type.INTEGER));
createTable(accounts);
accountitem = table("accountitems",
column("accountitem_id", Type.INTEGER, true, true, true),
hasOne(accounts),
column("amount", Type.DOUBLE),
column("valid", Type.BOOL));
createTable(accountitem);
b) Since I use ORMlite for my application, I have a second tool for creating the annotated ORM-classes (e.g. "Account" and "Accountitem") that are used by ORMlite. This also me to run the following in my scout service class (here for create):
@Override
public AccountFormData create(AccountFormData formData) throws ProcessingException {
if (!ACCESS.check(new CreateAccountPermission())) {
throw new VetoException(TEXTS.get("AuthorizationFailed"));
}
try {
Account account = new Account();
account.setAccountId(formData.getNumber().getValue());
account.setName(formData.getName().getValue());
account.setType(formData.getType().getValue());
account.create();
}
catch (SQLException e) {
throw new ProcessingException(e.getMessage(), e);
}
return formData;
}
Furthermore it creates some basic IDs and getters/setters to the model class to avoid misspelling in SQL-statements by using constants. A small statementbuilder can be used to create the SQL statements like here for the getTableData:
SelectBuilder sb = SQLBuilder.select(Account.getTable(), Account.ACCOUNT_ID_FIELD);
sb.select(Accountitem.getTable(), Accountitem.AMOUNT_FIELD, Accountitem.VALID_FIELD);
sb.from(Account.getTable(), Accountitem.getTable());
Object[][] res = SQL.select(sb.toString(), formData);
c) then I have a third tool to create the contents of the CRUD-Methods in the service class. For this I define the form data class and a set of "possible matching" model classes like this:
build(AccountFormData.class, Account.class, Accountitem.class);
Like the binding of scount SQL class, this tool uses the field ids of the form and tries to map them to the fields that are defined in the account. For example: the AccountFormData has a field "name". The tool looks into the account class if it has a field also called "name". If it is not found in "account", it searches in "accountitem".
As you might see, I do not have a 1 to 1 relationship between database tables and forms.
One reason was due to the following example: I have two tables (e.g. clients and admins) that use a third common table (e.g. user). Another reasong was the simple fact that I have a lot of forms that do not have a certain table, e.g. when I want to update some data.
I also tried out JPA (eclipse link) before, but I used ORMlite, because it is not so complex and the configuration is very simple. ORMlite reuses the connection from the AbstractSqlService, so that I only have one single JDBC-definition.
If someone is going to implement some of the "generation" stuff, I would really like to help!!!
|
|
|
Goto Forum:
Current Time: Fri Mar 29 10:03:58 GMT 2024
Powered by FUDForum. Page generated in 0.03882 seconds
|