Den 4. mars. 2008 kl. 14.46 skrev Paul Sandoz:
> We have different expectations on how implicit views work :-)
Probably :)
> Say for example the package of the class "TestResource" is "foo",
> then if there is a resource that can be loaded from the location "/
> foo/TestResource/index.<tp_suffix>" then the template processor
> associated with "<tp_suffix>" will get called with the model being
> the instance of TestResource.
>
> The reason why i did this is because i did not want the semantics of
> HTTP methods to change if there was a template present or not.
> Namely HTTP methods override any implicit behaviour and such methods
> need to be explicit about the template they want to use. This is why
> you get the exception that Jersey does not know what to do with the
> instance of Test, it deliberately does not look for a template
> processor to process a model that is an instance of Test it looks
> for a message body writer that understands what to do with the type
> Test.
Ok, am not quite sure I will need the implicit feature. And I think I
may be following your logic, but I must admit I still don't quite get
where the logic that implicitly maps to the jsp templates in bookstore
but not to my ftl ones are hidden. The viewablerule should treat my
template processor the same as the jsp one, so maybe I need to
understand the rule matching better?
>> I attached the processor, in case it tells you anything.
>>
>> <FreemarkerTemplateProcessor.java>
>
> Nice, very compact. All looks OK. You might be able to put the
> initialization code in the constructor and avoid the synchronized
> init method and the null check in the resolve method.
Your're right. It was actually a downsized version of an earlier
spring assembled prototype, and I think I will go in the spring
direction when I need a more complete version (to enable proper
configuration).
I've made a sample xslt version as well, and it works fine. The
template provider does the jaxb marshalling itself. I'm a bit worried
this might be a problem if the default jaxb context and this
provider's context differs, since it's important to have a well
defined and viewable xml to transform. Do you see any potential
problems here, is it easy to get access to the standard jaxb context
from this provider?
Jo