Yes, this was the idea, the doumentor has a bunch of special options
and messages that might be worth printing for advanced users or
developers but not normal users.
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
Where do I pass in and take advantage of the ProblemQuery.
Clients like MXMLC create a ProblemQuery to handle
enabling/disabling various kinds of problems based on configuration
options like -show-binding-warnings. I think the ProblemQuery also
handles sorting the problems. Do you need to customize the
ProblemQuery to enable and disable documentation problems?
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, September 21, 2012 11:55 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FALCON] Logging in an extension program
Gordon et al,
I've pretty much figured out that using COMPC as a starting
point/inspiration is the way to go.
I also spent half the day studying the Configuration class and it's
siblings. This has shed a lot of light about how to implement
something that will use quite a few compiler arguments.
I've also managed to create my own configuration with flags.
The problems problem, :) also has been solved since the MXMLC class
tracks these. Basically there is a lot of setup to do things using
all the functionality available, that is why subclassing MXMLC is a
good idea from the standpoint of a platform ready to go.
Mike
Quoting Michael Schmalle <apa...@teotigraphix.com>:
Hi,
I'm in the process of porting a documentor using the compiler's model
and just wondered about logging.
I have some logging statements in code etc. and was wondering about
the Problems. I know the main framework uses ICompilerProblem API to
log, so I am asking what is the correct way for me to handle these?
... Where do I pass in and take advantage of the ProblemQuery.
I have been spending so much time on the documentor code that I still
haven't quite figured out when I create a workspace, project and add
source files, SWCs that I set up a problems List correctly to get the
compiler problems and then be able to add documentor problems on top
of the list.
BTW So far not optimized and completely alpha the program parses,
processes and renders the framework, spark projects in 30 seconds
using Velocity templates. I still need to port the metadata renders
but using my old parser and AST we were taking minutes. The parser is
extremely fast.
In the next week or so I will post up the asdocs created(for you to
see) and eventually when I get this thing stable and APIs solid I will
add it to my whiteboard. The asdocs as it stands are complete copies
of the standard asdoc HTML with frames for default.
I think this program will definitely be usable for a lot of mid users
that want a completely extensible documentor solution. The old ASDoc
code really scares me. ;-) Also, using a walker/visitor pattern, it
should no be a problem to add an XML output module mirroring the one
spit out by asdoc so the XSL templates can be used in the future.
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
