[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-bpmn2.dev] Multi-file support
|
Hi Reiner,
that's good news!
2010/8/21 Hille-Doering, Reiner
<reiner.hille-doering@xxxxxxx>
2.
For all those references,
check if the target type is abstract. If yes, remove the abstract flag. If you
like you could extend your Excel to mark those cases.
See the attached document.
3.
It would be good to store
somewhere that the type was originally abstract to avoid users to accidently
create instances of it (e.g. in the editor). But EMF must be able to create
proxies of this type for sure. We could e.g. change use the genModel “image”
flag for keeping the information of former abstract classes.
We could add another details entry to the ExtendedMetadata of these classes (e.g. abstract -> true). Additionally, I suggest to change the template FactoryClass.javajet to the effect that the create method for originally abstract classes does not appear in the interface Bpmn2Factory and is not public in Bpmn2FactoryImpl. Thus it can be created during deserialization (which calls EFactory.create(EClass)) but is somewhat hidden to users.
ItemProvider.javajet will likely have to be adapted as well (@ collectNewChildDescriptors).
If you're OK with that, I'd try to tweak the templates accordingly.
Regards,
Henning
Attachment:
QName_vs_ResolveProxies.xls
Description: MS-Excel spreadsheet
