expermenting...

Signed-off-by: Alex A. Naanou <alex.nanou@gmail.com>
This commit is contained in:
Alex A. Naanou 2019-11-29 15:33:48 +03:00
parent 80722e92c4
commit 1409d8df4b

View File

@ -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???