--- 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

> 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

> > 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


Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Reply via email to