Extending or customising JALSE

Why extend or customise JALSE

JALSE was designed with modular abstraction in mind. Each of the core components can be used to some extent on their own but together create the dynamic Entity tree.

The most common use-case for customisation is the backing Entity and EntityFactory implementation.

Creating a custom AttributeContainer

The default AttributeContainer implementation is DefaultAttributeContainer. AttributeContainer provides a lot of default methods to make creating your own implementation easier.

Creating a custom ActionEngine

The default ActionEngine implementations and creating a custom one is covered in Picking an ActionEngine implementation.

Creating a custom EntityFactory

The default EntityFactory implementation is DefaultEntityFactory - this factory uses the common pool engine (see Picking an ActionEngine implementation) and creates DefaultEntity instances. The factory handles creating, transferring and killing entities so tree control starts here.

Creating a custom Entity

The default Entity implementation is DefaultEntity (supplied by DefaultEntityFactory). It is built using DefaultAttributeContainer, DefaultEntityContainer, DefaultActionScheduler and TagTypeSet - all protected fields.

Creating a custom EntityContainer

The default EntityContainer implementation is DefaultEntityContainer. This is used by JALSE and is the top level container.

Creating a custom EntityProxyFactory

The default EntityProxyFactory implementation is DefaultEntityProxyFactory - this factory uses EntityFunctionResolver and all the annotations under entities.annotations package to resolve Entity types. The default implementation uses a weak key map to cache proxy types to avoid unnecessary GC and dynamic proxy creation.

Creating a custom Taggable

There is no default Taggable implementation but TagTypeSet is provided for handling Tags by type.

Useful utilities

• Attributes (see API docs) for both AttributeType and NamedAttributeType related functionality.
• Actions (see API docs) for a variety of Action related functionality.
• Entities (see API docs) for Entity related functionality.

Using the custom implementations

JALSE takes in both ActionEngine and EntityFactory as arguments so different implementations can be used with minimal effort (see JALSEBuilder). It means that you may change just the bits you care about - such as what executes the Actions or what Entity instance is created without affecting how JALSE is used externally.

Ideas for custom implementations

• RMI ActionEngine
• RMI Entity
• Cached AttributeContainer
• DB AttributeContainer