myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Extensions/Validator/DevDoc" by GerhardPetracek
Date Mon, 07 Sep 2009 00:10:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by GerhardPetracek:
http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc

------------------------------------------------------------------------------
  == StaticConfiguration ==
  
  it's possible to register static configurations for several mechanisms at the startup. the
default implementations of factories cache the mapping. at the first call a factory adds the
static configs to the internal cache.
+ 
+ ----
+ 
+ == storages ==
+ 
+ this concept allows to implement storages with different scopes and functionality but a
generic mechanism to manage them.[[BR]]
+ developers can resolve and reset storages via a generic api. to identify a storage a storage-type
and storage-name is required. so it's possible to have multiple storages with the same type.
+ 
+ e.g. the GroupStorage is request scoped and the MetaDataStorage is application scoped furthermore
both have a different functionality.
+ 
+ resolve a storage:
+ {{{
+ public <T> T getStorage(Class<T> storageType, String storageName)
+ {
+     return (T)getStorageManagerFactory().create(storageType).create(storageName);
+ }
+ }}}
+ reset a storage:
+ {{{
+ public void resetStorage(Class storageType, String storageName)
+ {
+     getStorageManagerFactory().create(storageType).reset(storageName);
+ }
+ }}}
+ resolve the storage manager factory:
+ {{{
+ private static ClassMappingFactory<Class, StorageManager> getStorageManagerFactory()
+ {
+     return (ExtValContext.getContext().getFactoryFinder()
+         .getFactory(FactoryNames.STORAGE_MANAGER_FACTORY, ClassMappingFactory.class));
+ }
+ }}}
+ the storage manager factory works via the name-mapper mechanism of extval. it allows to
map a storage type to the storage manager.
+ 
+ === StorageManager ===
+ a storage manager gets registered in the factory and mapped to the type. it is responsible
to manage multiple storages of the same type. furthermore, it allows to create and reset a
storage with a specific name.[[BR]]
+ storage manager implementations provide a key which allows to store the storages via an
internal key. storage managers can also use name mappers to map from the storage interface
to the storage implementation
+ 
+ === StorageManagerHolder ===
+ allows to get and set storage managers for a given type. it's a factory to create storage
managers (factory name: STORAGE_MANAGER_FACTORY)
+ 
+ === implementing a new storage ===
+  * storage interface with specific storage api (each storage type has a different api)
+  * storage implementation
+  * storage manager implementation (to provide a key to cache storages of the same type in
a given scope)
+  * name mapper (storage interface to storage implementation) – if a storage manager implementation
requires it
+ 
+ === get the storage manager holder ===
+ {{{
+ StorageManagerHolder storageManagerHolder = (ExtValContext.getContext().getFactoryFinder()
+   .getFactory(FactoryNames.STORAGE_MANAGER_FACTORY, StorageManagerHolder.class));
+ }}}
+ 
+ === register custom storage managers ===
+ {{{
+ storageManagerHolder.setStorageManager(MyStorageType.class, new MyStorageManager(), true);
+ }}}
  
  ----
  

Mime
View raw message