Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Mars version: Make 'bean based TableData' the new default for table fields.
Mars version: Make 'bean based TableData' the new default for table fields. [message #1512997] Tue, 16 December 2014 06:10 Go to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
As you might know there are 2 possibilities to store the content of a table field in a formData:
* Array based TableData (default with luna)
* Bean based TableData

With Bug 455282 we want to change the default with mars.

Without changing anything, if you use AbstractTableField directly in your form, your FormData will be updated from array based to bean based. For the migration, you will have two possibilities:
* 1. Updating your logic using the formData (in the server probably) to work with the new formData.
* or 2. Configure your tableFields in your form to use array based table data (In this case the generated FormData will be the same as in luna).

For the long term, solution 1 is the preferred one.

Any thought about this change? Please give us feedback.

.
Re: Mars version: Make 'bean based TableData' the new default for table fields. [message #1545943 is a reply to message #1512997] Sun, 04 January 2015 16:36 Go to previous messageGo to next message
Chris Monty is currently offline Chris MontyFriend
Messages: 8
Registered: January 2015
Junior Member
I'm just starting to use this in Luna. Two drawbacks I've noticed so far are:

  1. When renaming columns in the table page (client side), sql binds (server side) have to be renamed using "search-and-replace".
  2. By default, search field bind names will conflict with the table page column they were generated from. e.g. If a columns is called "name", the search field will be called "name" and the required SQL query will be "SELECT name FROM person WHERE name = :name INTO :name". Either a naming convention must be implemented, or the search field binds need to be added as NVPair()s with different bind names.
Re: Mars version: Make 'bean based TableData' the new default for table fields. [message #1546117 is a reply to message #1545943] Sun, 04 January 2015 18:57 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
Chris Monty wrote on Sun, 04 January 2015 17:36
When renaming columns in the table page (client side), sql binds (server side) have to be renamed using "search-and-replace".


This is definitively a big limitation of the small convenience utilities and methods we provide on top of JDBC. You have exactly the same problem with Forms. (If you rename your NameField in FirstName field in a form, you need to update your SQL from "into :name" to "into :FirstName").

For big projects we use JPA (Hibernate) and do no longer rely on SQL written as String.

I have seen some project having some utilities to generate the SQL request. The developer maintains a map:
<database field name, ValueFieldData>
Then a small utility write the select, insert and update statements.

map.put("NAME", formData.getName());
map.put("PERSON_ID", formData.getPersonNr());
//..


I have no idea if it scale and how complex cases are handled.


The point is: introducing Hibernate in a small project is a big overhead.


Something I have on my TODO list would be to investigate QueryDsl. I think that the Querying SQL approach would be a nice way to specify the query and we could add something to define the mapping to the Scout FormData or PageData. This way refactoring of forms or database would produce compilation errors.


Chris Monty wrote on Sun, 04 January 2015 17:36
By default, search field bind names will conflict with the table page column they were generated from. e.g. If a columns is called "name", the search field will be called "name" and the required SQL query will be "SELECT name FROM person WHERE name = :name INTO :name". Either a naming convention must be implemented, or the search field binds need to be added as NVPair()s with different bind names.


Have you read the discussion here: TablePageData and SearchForm. Maybe this is exactly what you do not like?

Notice that even with Mars, we did not deprecate the Object[][] aproach. So you can continue to use it. (but this solution has also some problems: it is not type safe, it breaks when you change the column order in the table, ...). See the thread here:
Deprecate execLoadTableData() in table pages and the Bug 444210.

Last clarification:
Bug 455282 is dealing with the default TableData generated in a FormData corresponding to the TableField in a form. The strucutre that is generated is near to TablePageData, but this is the only relation. Bug 455282 has nothing to do with TablePage. This bug was implemented for Mars and if you are in a Luna version you can override the old default to use the mechanism that will be the default with mars.


Re: Mars version: Make 'bean based TableData' the new default for table fields. [message #1546167 is a reply to message #1546117] Sun, 04 January 2015 19:39 Go to previous message
Chris Monty is currently offline Chris MontyFriend
Messages: 8
Registered: January 2015
Junior Member
Quote:
Have you read the discussion here: TablePageData and SearchForm. Maybe this is exactly what you do not like?

Yes, that is exactly what I meant. I didn't know you can nest the SearchFormData inside a NVPair like that. Doing this solves the ambiguity, and my problem. Thanks.
Previous Topic:Dynamically generating menus
Next Topic:MessageBox shows with quite a delay
Goto Forum:
  


Current Time: Mon Dec 18 09:13:41 GMT 2017

Powered by FUDForum. Page generated in 0.01957 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software