Hi Matthias,
I've added some javadocs that may help to enlighten devs about how to do
some of the URI schema features you were asking about. As a potential user,
if you could take a look and let me know whether it's clear enough, I'd be
very grateful. I always find hard to know how much information to put in a
javadoc...
Thanks
Mehdi
On 26 July 2012 08:48, mehdi houshmand <med1...@gmail.com> wrote:
> That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
>
>
> On 26 July 2012 08:46, mehdi houshmand <med1...@gmail.com> wrote:
>
>> Hi Matthias,
>>
>> Don't be so quick to thank us for this work, you may retract that once
>> you start using it ;).
>>
>> 1. Good question. The way it works is that you give the FopFactory
>> (either in a constructor or via the EnvironmentProfile) a base-URI, this
>> will become the default base URI should a "<font-base>" not be given.
>>
>> 2. Yes, you can use a relative URI and it resolves against the default
>> base URI described in 1). What I've tried to do is make all URIs resolve to
>> against single base URI that is given in the constructor of the FopFactory.
>> Interestingly though, I just noticed something we didn't consider. What if
>> the URI given to the FopFactory isn't an absolute URI? We don't check at
>> any point to ensure it is absolute... I think it would resolve against "new
>> URI(".")" where-ever that may be. Maybe we want throw an
>> IllegalArgumentException? I don't know.
>>
>> 3. There is some documentation as to how to do this, though I think we
>> could have probably done better in publishing more detailed explanation as
>> to what we've done here. So we have created a mechanism for handling URI
>> schemes, since it's an integral part of the URI spec, and it's almost the
>> raison d'etre. Look at the o.a.f.apps.io.ResourceResolverFactory and its
>> unit test (o.a.f.apps.io.ResourceResolverFactoryTestCase) the static inner
>> class "TestCreateSchemaAwareResourceResolverBuilderHelper" (say that
>> quickly 20 times) does what you're looking for.
>>
>> Essentially do the following:
>> ResourceResolverFactory.SchemaAwareResourceResolverBuilder builder =
>> ResourceResolverFactory.createSchemaAwareResourceResolverBuilder(<DEFAULT
>> RESOLVER>);
>> builder.registerResourceResolverForSchema(<SCHEMA>, <RESOLVER GIVEN
>> SCEHMA>);
>> ... // you can add any number of schemas with their corresponding
>> resolvers
>> ResourceResolver resolver = builder.build();
>> // resolver is then used as the resolver given to either the
>> FopFactoryBuilder or FopConfParser, either directly or via the
>> EnvironmentProfile.
>>
>> I'd play around with this mechanism, it can be very powerful once you
>> play around with URIs. You can define the the font-base as "font://" and
>> use "font" as the schema and thus have much finer control as to where the
>> fonts are. This brings the full power of the URI spec to all resource
>> acquisition. All you have to do is implement the ResourceResolver interface.
>>
>> Also, an FYI for you and anyone else that uses FOP in systems that
>> require fine-grained control over I/O and file access; you can now control
>> where FOP writes/reads from temporary files (scratch files used to save on
>> memory.) By implementing the o.a.f.apps.io.TempResourceResolver, you can
>> mitigate any security risks from leaking information or any worries one may
>> have. (Though realistically, the way FOP uses scratch files, that's not
>> very likely, but it's always better safe than sorry.)
>>
>> I hope all that makes sense, if not, please feel free to ask me to
>> clarify.
>>
>> Mehdi
>>
>> On 25 July 2012 21:25, Matthias Reischenbacher <matthias8...@gmx.at>wrote:
>>
>>> Hi Mehdi,
>>>
>>> thanks for your explanation. Some questions:
>>>
>>> 1. What's the default font base directory? The same as the normal base
>>> directory?
>>>
>>> 2. Can I use a path relative to the normal base directory for the font
>>> base directory?
>>>
>>> 3. Back to URI resolving: I'm a bit afraid of breaking something if I
>>> implement my own URI resolver. What does the default resolver do? It would
>>> be nice if the default resolver would be part of the public API so that I
>>> can sub class it and just inject the authentication params (like before).
>>>
>>> Btw... it's really nice that all data is loaded now through the new URI
>>> resolver. In the near future I'd like to use a custom scheme (e.g.
>>> myscheme://imageid) in order to load images instead of using HTTP. That
>>> wouldn't be possible without your change. So thanks!
>>>
>>> Best regards,
>>> Matthias
>>>
>>>
>>> On 24.07.2012 04:23, mehdi houshmand wrote:
>>>
>>>> Sorry Matthias, I'm an idiot. Not defining a font-base wasn't an over
>>>> sight at all; I was just implementing a font-base injection mechanism
>>>> and I remembered why we didn't allow this programmatically. You have to
>>>> define the font-base using the "<font-base>" element in the fop-conf,
>>>> that's the only way to do it and it's intentional.
>>>>
>>>> I'll take this opportunity to explain why we've done what we've done for
>>>> the sake of the community, if you're not interested feel free to ignore
>>>> the next section:
>>>> Some of the problems we were seeing when dealing with a lot of these
>>>> configuration classes was that people were adding new parameters and
>>>> functionality to them incrementally, as is the case with open-source.
>>>> The problem was that there were several ways of doing the same thing and
>>>> getters/setters all over the place. So what we did was try and ask "what
>>>> would a user want to do? And how do we make that as easy as possible
>>>> while still maintaining some encapsulation and immutability in these
>>>> classes?"
>>>>
>>>> How does relate to the font-base? Well, it seems like an abuse of
>>>> encapsulation to allow users to set the font-base-URI directly onto the
>>>> FontManager. Users shouldn't need to care about these internal
>>>> mechanisms, they should be able to just configure it and it works. So we
>>>> decided to enforce a single parameter to set the font-base
>>>> ("<font-base>" in the fop-conf) because th only reason someone would
>>>> want to define a font-base-URI would be if they had custom fonts setup,
>>>> and in order to do so they'd need a fop-conf anyways. So we might as
>>>> well enforce a single point of entry for the font-base-URI, otherwise
>>>> you'll have to do "if (x != null)" checks all over the place and how
>>>> would you decide which parameter overrides which? Why should a
>>>> programmatically set font-base override the one found in the font-base?
>>>> How do we document this so that users it's abundantly obvious to users?
>>>> We asked ourselves "is there a use case for setting this
>>>> programmatically rather than through the fop-conf?" We couldn't see why
>>>> anyone would want to do that.
>>>>
>>>> We have tried to reduce the number of entry points for injecting
>>>> configuration parameters, for two reasons; 1) because it wasn't
>>>> documented and certainly wasn't obvious which parameters overrode which,
>>>> when two of the same config parameters were used; 2) for the sake of
>>>> developers, so that once the FopFactory hand been created, its state is
>>>> mostly immutable (it has mutable members) and we can make certain
>>>> assertions on the immutability of the members.
>>>>
>>>> Hope that makes our intentions clear,
>>>>
>>>> Mehdi
>>>>
>>>> On 24 July 2012 07:35, mehdi houshmand <med1...@gmail.com
>>>> <mailto:med1...@gmail.com>> wrote:
>>>>
>>>> Hi Matthias,
>>>>
>>>> The way we've implemented the interface, you can be completely in
>>>> control of how HTTP is authenticated by implementing
>>>> o.a.f.apps.io.**ResourceResolver[1] and giving it to the
>>>> FopFactoryBuilder/**FopConfParser[2].
>>>>
>>>> As for the base URI for fonts, you can set this in the fop-conf, we
>>>> haven't created a way to set this programmatically, that was an
>>>> oversight on our end. I'll enable a way to do this and get back to
>>>> you.
>>>>
>>>> [1]
>>>> http://wiki.apache.org/**xmlgraphics-fop/URIResolution<http://wiki.apache.org/xmlgraphics-fop/URIResolution>
>>>> [2] http://wiki.apache.org/**xmlgraphics-fop/**
>>>> FopFactoryConfiguration<http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration>
>>>>
>>>> Hope that helps,
>>>>
>>>> Mehdi
>>>>
>>>>
>>>> On 24 July 2012 00:01, Matthias Reischenbacher <matthias8...@gmx.at
>>>> <mailto:matthias8...@gmx.at>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I just tried to upgrade to latest trunk and noticed two
>>>> compatibility issues with my application which I couldn't fix on
>>>> my own:
>>>>
>>>> * The fontManager has no setBaseURL method anymore. How is the
>>>> base URL set now?
>>>>
>>>> * The FOURIResolver class doesn't exist anymore. Sub classing it
>>>> for applying HTTP basic authentication parameters is therefore
>>>> not possible.
>>>> See also:
>>>> http://wiki.apache.org/__**xmlgraphics-fop/HowTo/__**
>>>> BasicHttpAuthentication<http://wiki.apache.org/__xmlgraphics-fop/HowTo/__BasicHttpAuthentication>
>>>>
>>>> <http://wiki.apache.org/**xmlgraphics-fop/HowTo/**
>>>> BasicHttpAuthentication<http://wiki.apache.org/xmlgraphics-fop/HowTo/BasicHttpAuthentication>
>>>> >
>>>> How is HTTP authentication handled now?
>>>>
>>>> Thanks for your help,
>>>> Matthias
>>>>
>>>> ------------------------------**__----------------------------*
>>>> *--__---------
>>>> To unsubscribe, e-mail:
>>>>
>>>> fop-users-unsubscribe@__xmlgra**phics.apache.org<http://xmlgraphics.apache.org>
>>>>
>>>> <mailto:fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org>
>>>> >
>>>> For additional commands, e-mail:
>>>> fop-users-help@xmlgraphics.__a**pache.org <http://apache.org>
>>>>
>>>> <mailto:fop-users-help@**xmlgraphics.apache.org<fop-users-h...@xmlgraphics.apache.org>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail:
>>> fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org>
>>> For additional commands, e-mail:
>>> fop-users-help@xmlgraphics.**apache.org<fop-users-h...@xmlgraphics.apache.org>
>>>
>>>
>>
>
