Improved ZMSMetaobjManager GUI

[drfho]

Hello @zmsdev
Intermediate saving on adding new attributes to the content model may not match the user's expectations. Actually it is not very fast. So the ZMI should alllow just a "final" Saving. The code proposal works with JS-cloning of the "add"-row. The cloned TR-element is used as a template that is changed by JS so that it can work like the "old" rows. Thus the backend code can handle it.

About the JS Code:
The crucial point is that the JS-cloning has to be done inside the click-event function and the added TR needs an unique ID, to get it selected in the DOM.
A cloning in advance, means outside the funktion, generates one global object which on button-click will instanciated into itself, so that in the end only one new attribute row can be added.

BTW: the processing of the attributes may hardened against entering identical attribute ids

ZMS/Products/zms/ZMSMetaobjManager.py

Lines 1146 to 1158 in 751c21a

	try:
	attr_id = REQUEST['attr_id_%s'%old_id].strip()
	except:
	if type(REQUEST.get('attr_id_%s'%old_id))==list:
	# Error: doubled attribute ids
	standard.writeLog(self, "[ZMSMetaobjManager.manage_changeProperties Doubled Attribute IDs]: %s"%(REQUEST.get('old_ids', [])))
	message+='IGNORED Doubled ID: attr_id_%s<br/>'%(old_id)
	attr_id = REQUEST['attr_id_%s'%old_id][0].strip()
	continue
	else:
	standard.writeLog(self, "[ZMSMetaobjManager.manage_changeProperties Key Error]: attr_id_%s"%(old_id))
	message+='IGNORED Key: attr_id_%s<br/>'%(old_id)
	continue

[zmsdev]

when can this happen?

[drfho]

attr_id can be not a string but a list if id (unitentionally) occurs 2x by multiple row posting. And strip() does not work on lists, If a list tyoe can be avoided for sure, this exception is not needed, of course.

[zmsdev]

don't we need an individual row-counter for each table?

[drfho]

I do not think so, because counter is need for the ex-ante (temporarily) name unification (that is "corrected" by the ZMSMetaobjManager.manage_changeProperties() applying the old_id-mechanism).
BTW: Maybe we can get rid of the counter at all, when generally changing all the new row's form names on-blur according to the input-value of the meta-id field. The current JS code may be considered as too long ;-)