From 1409d8df4b2a2bf2c6d1133d348c05ba8c814a95 Mon Sep 17 00:00:00 2001
From: "Alex A. Naanou" <alex.nanou@gmail.com>
Date: Fri, 29 Nov 2019 15:33:48 +0300
Subject: [PATCH] expermenting...

Signed-off-by: Alex A. Naanou <alex.nanou@gmail.com>
---
 ui (gen4)/features/ui-widgets.js | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/ui (gen4)/features/ui-widgets.js b/ui (gen4)/features/ui-widgets.js
index 85587a4d..2acd6e75 100755
--- a/ui (gen4)/features/ui-widgets.js	
+++ b/ui (gen4)/features/ui-widgets.js	
@@ -969,6 +969,11 @@ module.Dialogs = core.ImageGridFeatures.Feature({
 // 			- a context manager API... (REJECTED?)
 // 				- complexity...
 // 		Q: should we add domain specific fields here too???
+// 			...would be nice to be able to add domains to make(..), e.g.:
+// 				make.Domain('ig')
+// 				make.ig.attrToggle = function(..){ ... }
+// 			the goal is to preserve the make(..) context in sub calls, see
+// 			browse.items.Domain(..) implemented below...
 // XXX Q: do we actually need .Field(..), it does everything make(..) 
 // 		does already???
 // XXX Q: should title/value args be optional???
@@ -1112,6 +1117,28 @@ function(title, value, options){
 							: 'off' } }))) }
 
 
+// XXX EXPERIMENTAL...
+// 		this is global domain, can we add field domains to specific contexts???
+// 		...this may pose a problem if we reuse a lib in several contexts within 
+// 		one app...
+// 		...not sure how critical this is at this point...
+// XXX move this to browse???
+browse.items.Domain = function(name, obj){
+	var that = this
+	var sub = function(){
+		return that(...arguments) }
+	sub.__proto__ = that
+	obj
+		&& Object.assign(sub, obj)
+	return that[name] = sub }
+
+
+browse.items.Domain('ig', {
+	attrToggle: function(){
+		// XXX
+	},
+})
+
 
 // XXX like .makeEditor(..) but local to make(..) (i.e. generic)...
 // XXX should this use any fields available to make(..) or just the editor???