Well... several limitations. When a CFC has an extends attribute, how do you find the CFC associated with it since the path is only available at runtime from CF. Same problem applies to methods that return or accept as a parameter a CFC. Further, what is a field in a CFC? Is it a variables scope variable declared in the pseudo-contructor area? If it is, what type is it? Assuming you can figure out the type and it is a CFC, then you're back to the problem of finding the referenced CFC file.What limitations did you encounter when going from the parsed CFC to an EMF object? I'm not all that familiar with EMF, but I did play with forward engineering CFCs from XMI a while ago. I'm guessing that one of the most difficult aspects will be managing method arguments in the context of the actual method body (code), because cfargument is really part of both the method signature and the method body.
The good news is that any EMF model will export to XMI. Further, roundtrip engineering shouldn't be that hard using the various CFC tag meta attribute capabilities.
As far as help goes... I don't know what I am looking for since I don't even know where I am going with this stuff. Right now the code depends on He3's CFML parser, which appears to be a requirement that won't change since there is no other CFML parser available. Then again, we (RichPalette) simply don't have the time to knock out a CFC modeler.
-Matt
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
