The overwerk[] field is a subitem yes.
Yes I think definitivly that you should use this way.
But then I didn't tried before for the moment so I can't help you.
When you are using Ajax with cook, In facts everything is ready for that in models. So it is not a big deal.
The only thing you have to do is to catch the ajax call in the view : displayAjax(), so it will stop with a jexit(), and will only return a JSON string.
Even when you are returning nothing, return something in JSON for the error management. This is missing in Cook.
Cook do not handle such Ajax transactions controls, and didn't defined yet a definitive standard way to do it.
for the moment, the prefered format is :
{
data:{}, // Returned JSON
transaction:
{
exceptions: [] //Joomla Exceptions (errors, warnings, notices)
}
}
Then data contain the result. (item, list, complete object... what you want)
Transaction can contain also a lot of informations else as you want, but try to keep this convention OR DISCUSS IT, because it is planned to integrate it in the displayAjax()
For the moment Cook only deals with raw HTML returns in displayAjax().
Note : displayAjax is created in the view files of every view (item or collection) that need to be returned such way.
If you want to create this function, you may add 'ajax' in the array() of accepted layouts (view constructor)
Then something nice to respect my convention is to use the var 'render' which is an unique name for this ajax call, it is a sort of context var, or can be understood like the 'layout' var when using ajax.
Hope it helps.
Last but not least :
I see this topic has derivated from its original purpose...
To answer your initial question :
You are right, I understand.
My opinion is the same than audibeid. You may not have that much redondency.
Your field names are tricky.
A nice app is often using short name vars. Not for optimization, but for readability. If you cannot name them shorter or better, I think it is because your database architecture can be improved.
I will not fix that for the moment.
What you can do is simple :
Remember that all the labels strings are parser in the languages files, so :
-> Use other labels temporaly, with abreviations for instance
-> Rename them in the language file.
And please use shorter field names.
With such var names, when you will start to join with others tables, the aliases names will be so long !!!
