>> There are so many control words in the RTF spec that I tried to
>> simplify the creation of the classes through automating the
>> generation of them. This way new control words (RtfCtrlWordBase_*)
>> can be added through the generation process without disturbing
>> manual coding that may change the RtfCtrlWord_* classes. (I may have
>> caused some confusion because I have generated all RtfCtrlWord_*
>> files without implementing them yet.) If the RtfCtrlWordBase_*
>> classes are eliminated the ability to re-generate the class files
>> without overwriting modified files is also eliminated.
>I'm not quite sure, but wouldn't eliminating the RtfCtrlWordBase_*
>classes only mean that the generation code needs to be a bit smarter,
>not that it cannot be used anymore? That would reduce the number of
>files by 50%, a major saving. As the generation process is only to be
>called on new specification versions, I feel that would be a
>worthwhile improvement.
Yes, I could spend more time on the generator to be better at creating the
classes! I'm still working on it anyways.
In reality, unless an update adds more control words than one would want to
copy/paste/modify classes the regeneration would not happen.
>> Above all, parsing and handling the RTF spec is complicated and I
>> wanted to make the parser easy for others to work with by making
>> classes that perform specific functions. The parser needs to be
>> seperated from the control word handling logic.The control word
>> manager should be responsible for handing off the control word and/
>> or values to the appropriate handler. Having one class that tries to
>> handle unknown different situations through a bunch of logic (if/
>> switch/etc.) statements would be a poor and confusing design in my
>> opinion.
>I definitively agree with this approach. I have tried RTF generation
>in a single and then in a few classes and it becomes unmaintainable
>very quickly, and RTF generation is a lot simpler than parsing it. We
>are stuck with a large and complex parsing component, so possibly it
>is inevitable that we provide at least part of it as a separate jar.
Having to split the parser would not be the end of the world!
Howard
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://itext.ugent.be/itext-in-action/
