--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> But the biggest improvement is IMHO the easy ability
> to create special
> maker subclasses to handle the corner cases. Take a
> look at
> IndentPropertyMaker for the calculation of start and
> end-indent and at
> BorderWidthPropertyMaker for the special handling of
> border-width when
> border-style is NONE.
>
Well, I'm not there yet, but I'll be able to
appreciate it in due time.
>
> Initially my new FOPropertyMapping was generated by
> XSLT but that is now
> a long time ago and I have made lots of manual
> changes since then.
OK, no problem, we'll modify the Java source from now
on.
>
> The generic properties are just templates that
> carries default data
> values to be used later on, so I don't fully see how
> we could xslt-
> generate them as anything other than containers of
> default values. Your
> last statement is a bit difficult to parse so I'm
> not sure what exactly
> you are recommending.
>
Umm, never mind. What I was trying to say is that the
generic templates (GenericKeep, GenericSpace, etc., of
the present code) were all autogenerated. *If* you
thought it still useful to keep it as such, it's OK
with me (i.e., going down from 250 autogenerated to
about 8 is still a very nice improvement.) But you no
longer see a need for it, which is absolutely fine
with me.
> > One thing that *does* stick out, however, is the
> 100
> > or so addKeyword() calls for genericColor (the
> largest
> > of the generic properties):
> >
> > genericColor.addKeyword("antiquewhite",
> "#faebd7");
> > genericColor.addKeyword("aqua", "#00ffff");
> > genericColor.addKeyword("aquamarine",
> "#7fffd4");
> > .....
> >
> > I'd like us to have a static array of these
> > values--i.e., something done compile-time, that
> > genericColor can just reference, so we don't have
> to
> > do this keyword initialization.
>
> I probably need an example of what you thinking are
> here. Right now in
> HEAD all the color keywords are stored in a HashMap
> created in
> GenericColor so the keywords initialization is
> already done.
OK--I see, thanks for the enlightenment here. Never
mind again, I was wrong on this point.
> Putting the
> keywords in static array would require us to somehow
> search the array
> and I don't see how that will be much faster.
>
Yes, wasn't thinking of that.
> > 4) I'd also like us to, rather than call
> > setInherited() and setDefault() for each of the
> > properties during initialization, for the
> > Property/Property.Maker classes to just reference
> that
> > information from two (new) static arrays, added to
> > Constants.java. We can also get rid of these two
> > setter methods as well (ideally there shouldn't be
> > setters for these attributes anyway--they should
> > remain inherent to the Property.)
> >
> > This change will allow us to take advantage of the
> > fact that we are now on int-constants.
> > getDefault(PR_WHATEVER), for example, is just
> > Constants.DefaultArray[PR_WHATEVER].
>
> I think 'Default' is a bad example, noone ever tries
> to get the default
> value except for the property maker itself, but your
> argument holds for
> isInherited().
>
No--I don't think you've gotten my point here. I
don't care about the consumers of that
information--even if it is just Property.Maker. But I
don't see the reason to run-time initialize a
PropertyMaker with inherited and default values,
because I can add the whole array in the Constants
interface, or even in Property.Maker directly.
static Boolean inheritedArray[] =
{
false .... // 0
true // PR_PROP_1
true // PR_PROP_2
false // PR_PROP_3
true // ...
....
Once you initialize a Property.Maker with its
PR_XXXXXX constant, *it* (the Maker) can always obtain
these values by accessing inheritedArray[PR_XXXXXX] or
defaultArray[PR_XXXXXX]. No reason to initialize via
setInherited(true) or setDefault("5"). Do you see
what I'm trying to say?
> Still, I disagree. If one want to know is a property
> is inherited, the
> proper way to get the information should be to call
> propertyMapping[PR_WHATEVER].isInherited().
>
OK--we can place these two arrays in a location where
only the Property.Makers can get to it. (Maybe a
protected static array in Property.Maker?) Thoughts
here?
> > Again, getting rid of the useGeneric() function.
> This
> > is for more speed, encapsulation, and also
> shrinking
> > FOPropertyMapping class a bit.
>
> A very good idea. +1.
>
I can probably make the modifications to this--looks
simple.
Thanks,
Glen
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
