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

[Rich Kulp <richkulp@xxxxxxxxxx>]

We now have basic init string processing
working. We have a subclass of JavaAllocation that contains the init string.
This init string is the simple stand-alone kind of string the VE always
used.

When instantiating a proxy, we have
a processor (currently it is an adapter on the InitStringAllocation object,
but this will probably change because it is too complicated to get the
factory for this adapter registered correctly) that understands the InitStringAllocation
and will use the old init string process that we've always used. 

When putting a new object out in codegen
to the .java file, the codegen will just use the init string as is and
put it, just as it did in the past. This will need to change when parse
tree allocation is available. We will need a processor which can visit
the type of allocation and produce the correct string for codegen.

We are maintaining this initstring allocation
method because for simple strings it is more efficient and easier to code
to than a parse tree. However, we are not going to further enhance the
init string parser for creating the live beans. If any strings more complicated
than what can currently be handled are required, then parse trees will
need to be used. Actually the initstring allocation process can handle
80% of the cases.

The two outstanding points which will
be resolved with the parse tree implementation will be:

1. Instantation adapter/processor for handling the instantiation of live objects needs to be fixed up so as not so complicated. It needs to be able to figure out (thru a factory of some kind, probably) what kind of instantiation object to use, either for initstring or parse tree.
2. Along the same lines is we need a different kind of adapter/processor for generating the actual code in the java file. The parse tree will need a different way of figuring out the code then a straight init string.

There are several broken things right
now. For example the image stuff (.gif files) as properties is not working.
This is because this code is hard-coded to look into the init string to
try to find the gif file. It could only handle a very narrow pattern. With
the introduction of parse trees, this will change. Also not working is
in strings from message bundles. For the same reason as gif files, it looked
directly into the init string to try find out what message bundle it is.

There will be further mail as we design
the parse tree part.

Rich Kulp