Hi Paulo,
I agree with the source size issue. One side note is the size almost tripled
when I added all the license comment blocks.
>Looks like it does exactly the same as the base class.
Yes. I agree that is what it "looks" like at the moment. This is because the
functionality of each control word is not implemented. Pick a couple control
words that are (at least partially) implemented and view the source for those
files. You'll see they very quickly each does a different process depending on
the state of the document. Your choice of files to review are files that do not
have implementations coded.
Please review some of these files.(I just picked a few that are implemented)
[EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED];
or
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I built the RtfCtrlWord_* ->RtfCtrlWordBase_* structure so the
RtfCtrlWordBase_* classes and the RtfCtrlWords class can be generated from a
utility using a file that defines the control words and other details. The
RtfCtrlWord_* and RtfCtrlWordMgr classes are the manually coded files.
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 think that 3600 classes could be eliminated without loss of
>functionality and it would always be possible to extends RtfCtrlWordBase
>for some specific uses. This would probably allow iText to be
>distributed in a single jar.
I think 1/2 of the classes could be eliminated at the cost of not being able to
generate the RtfCtrlWordBase_* layer that handles unimplemented control words.
As for "it would always be possible to extends RtfCtrlWordBase for some
specific uses", each and every keyword has a specific use that is different
from other control words and some control words serve multiple uses depending
on the current document state.
That all being said:
I have found out today, some RTF generators use additional control words as
extensions and/or may not be fully documented and there is a need for a generic
handler for "unknown" control words, at least for the import function. If the
control words that are not implemented yet were handled as "unknown" there is
the possibility to temporarily eliminate more than 1/2 of the classes, but ONLY
until such time as said classes are implemented.
I am looking at ways to create better destination handlers that would work with
dynamic attributes and this would possibly allow for the grouping of types of
control words that might be able to use a specific class. I'm not quite sure
how to explain this yet as I haven't fully worked out if it's possible and the
details. There are basically the following types of control word/tokens:
1. Destination control words - changes where control words and clear text data
is sent to be handled.
2. Toggle control words - boolean, on/off, true/false
3. Value control words - Set/modify some value, usually a property
4. Clear text values - Text that is sent to a destination. Processing depends
on the group and/or previous control word.
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.
Howard
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------------------------------------------------------------------
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/
