#91 Collections: observable collections

Suljettu
3 vuotta sitten avasi ranides · 9 kommenttia
ranides kommentoitu 3 vuotta sitten

Create adapters for Collection, List, Map, PrototypeMap, GenericMap

Every adapter will emit events to associated EventRouter

Create adapters for Collection, List, Map, PrototypeMap, GenericMap Every adapter will emit events to associated EventRouter
ranides kommentoitu 3 vuotta sitten
Omistaja

Maybe we should implement observable for:

  • Map
  • PrototypeMap
  • GenericMap
  • BeanModel

And create only one event: PropertyChange(key, prev, value)

Maybe we should implement observable for: - Map - PrototypeMap - GenericMap - BeanModel And create only one event: PropertyChange(key, prev, value)
ranides kommentoitu 3 vuotta sitten
Omistaja

We should support:

  • java.beans.PropertyChangeEvent
  • net.ranides.assira.event.PropertyChangeEvent
We should support: - java.beans.PropertyChangeEvent - net.ranides.assira.event.PropertyChangeEvent
ranides kommentoitu 3 vuotta sitten
Omistaja

At this moment our events model does not support synchronized events: it means we can't cancel event, we can't veto property change, etc

At this moment our events model does not support synchronized events: it means we can't cancel event, we can't veto property change, etc
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
ranides kommentoitu 3 vuotta sitten
Omistaja

We have:

  • Collection
  • List
  • Map
  • PrototypeMap
  • GenericMap
  • observable bean constructor
  • observable bean wrapper

Creating observable BeanModel is pointless essentially, because our "observable model" won't see changes introduced to object by direct calls.

Creation of "wrapper" for existing objects is quite questionable. We shouldn't write subclass which delegates to source, it will consume 2 times more memory. It is almost pointless.

We have: - [x] Collection - [x] List - [x] Map - [x] PrototypeMap - [x] GenericMap - [x] _observable bean constructor_ - [ ] _observable bean wrapper_ Creating observable BeanModel is pointless essentially, because our "observable model" won't see changes introduced to object by direct calls. Creation of "wrapper" for existing objects is quite questionable. We shouldn't write subclass which delegates to source, it will consume 2 times more memory. It is almost pointless.
ranides kommentoitu 3 vuotta sitten
Omistaja

we should be able to instantiate observable bean if there is no public default constructor, or no default constructor at all (by using some memory allocation trick)

we should be able to instantiate observable bean if there is no public default constructor, or no default constructor at all (by using some memory allocation trick)
ranides kommentoitu 3 vuotta sitten
Omistaja

todo: our collections are reused by other structures. In such case they emit "wrong" source:

  • ObservableIterator emits always CollectionEvent. If used by map, it emits event with source pointing to "entrySet", "keySet", "values" instead of MapEvent and corrent enclosing map

  • ObservableMap is used by ObservableGenericMap and ObservablePrototypeMap. It emits event with source pointing to "declaredMap" or event worse some other map inside prototype.

ObservablePrototypeMap is especially complicated. What to do if we change something inside prototype directly? We should emit source as "prototype map" of course. But what if we modified it indirectly? Should we emit source as "enclosing map"? Maybe it is irrelevant question because it is impossible to modifiy prototype indirectly.

Anyway, ObservablePrototypeMap should emit source as enclosing instance, not as internal "declared" map.

todo: our collections are reused by other structures. In such case they emit "wrong" source: - ObservableIterator emits always CollectionEvent. If used by map, it emits event with source pointing to "entrySet", "keySet", "values" instead of MapEvent and corrent enclosing map - ObservableMap is used by ObservableGenericMap and ObservablePrototypeMap. It emits event with source pointing to "declaredMap" or event worse some other map inside prototype. ObservablePrototypeMap is especially complicated. What to do if we change something inside prototype directly? We should emit source as "prototype map" of course. But what if we modified it indirectly? Should we emit source as "enclosing map"? Maybe it is irrelevant question because it is impossible to modifiy prototype indirectly. Anyway, ObservablePrototypeMap should emit source as enclosing instance, not as internal "declared" map.
ranides kommentoitu 3 vuotta sitten
Omistaja

comment about rebinding: it is impossible to set correct binding at construction time (enclosing collection is not constructed yet).

Maybe the best option is to write new type of EventRouter which transforms/rewrites event inside "signalEvent" method?

comment about rebinding: it is impossible to set correct binding at construction time (enclosing collection is not constructed yet). Maybe the best option is to write new type of EventRouter which transforms/rewrites event inside "signalEvent" method?
ranides kommentoitu 3 vuotta sitten
Omistaja

todo: we should fix ObservableIterator in the same way as ObservableMap (we should create subclasses, instead of using simple class)

todo: we should fix ObservableIterator in the same way as ObservableMap (we should create subclasses, instead of using simple class)
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
ranides kommentoitu 3 vuotta sitten
Omistaja

todo: test

todo: test
ranides viittasi tähän ongelmaan commitissa 3 vuotta sitten
Kirjaudu sisään osallistuaksesi tähän keskusteluun.
Ei merkkipaalua
Ei osoitettua
1 osallistujaa
Ladataan...
Peruuta
Tallenna
Sisältöä ei vielä ole.