Re: [ve-dev] Re: [Design] Init string parsing

[Rich Kulp <richkulp@xxxxxxxxxx>]

Processors:

We've decided on the processor structure.
These are the classes that will instantiate or create an init string for
code generation or create the parse tree from AST tree.

For instantiation, there will be an
interface with a method where the JavaAllocation is passed in along with
the IBeanProxyDomain (this is an object that bean proxies need to determine
the domain, i.e. how to access the remote vm, etc). This will return the
new allocation as an IBeanProxy.

In the EditDomain, under a key (maybe
"AllocationProcessor"), will be an instance that implements this
interface. This instance is an editor wide instance. It will need to understand
each of the allocation types and then process them appropriately. 

Each BeanProxyAdapter has the IBeanProxyDomain
stored in it. For performance reason, so that we don't need to keep looking
up the AllocationProcessor by key, the IBeanProxyDomain will have an accessor
method that returns the AllocationProcessor from the EditDomain, but it
caches it. This is OK because the processor instance should never change
during the lifetime of the editor. Bean proxies can be used in different
types of editors, besides the Java visual editor, so that is why this extensibility
is needed here.

There is then the code generation step.
This is when the model creates a property setting and now the codegen has
to create the init string to place into the Java code itself. Code generation
will know how to handle the two different types of allocations to produce
the actual string. It'll be isolated into a CodegenUtility class. For InitStringAllocations
it is quite simple, just return the init string. It will be more complicated
for the parse tree.

The question came up that isn't this
kind of restrictive? It doesn't allow for extensions of new JavaAllocation
types. We've discussed this and feel that for a particular VE editor that
there are so many intrusive places that need to be extended that for new
JavaAllocation types it would have to be different code or the code changed
drastically. One example is creating the Java allocations from the Java
code, the code gen parser is very specific to the Java editor and it would
be difficult to dynamically have it parse the code differently and create
a different kind of Java allocation. The current idea is that it will always
produce parse tree allocations. Our feeling is that for the Java editor
this should be sufficient, that parse trees are complete enough for any
kind of Java code generation.

This is different than the EMF model
and Bean proxies themselves. The EMF model is adaptable to other cases
than just a Java editor, so it needs a little flexibility in the instantiation.
However we don't feel that dynamically new types of allocations will be
inserted at runtime. An editor will have a specific set associated with
it.

The codegen is not that general. It
is for taking Java code into the Java model, and Java model code back into
Java code.

Rich