On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <[email protected]> wrote:
> We should just has a service that takes an
> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
> first to sencond in the third.
Than define this interface in
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.commons.web.viewable</artifactId>
org.apache.stanbol.commons.web.viewable.RdfViewableRenderer
+ render(RdfVieweble rdfViewable, OutpuStream out, MediaType mt)
and provide an LDpath based implementation in
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
Internally the LdViewableWriter should than be adapted to also use this service.
In the meantime I will commit my current version as the UserManager
does work nice locally
best
Rupert
On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <[email protected]> wrote:
> Hi Rupert
>
> On Wed, Feb 13, 2013 at 2:22 PM, Rupert Westenthaler
> <[email protected]> wrote:
>> Hi Danny, Reto
>>
>> I have not introduced a dependency to Freemaker nor JAX-RS. This
>> dependency was always present - transitive over the LDRenderer and via
>> the dependency to commons.web.base.
>
> I'm talking about the java class. The class was written on higher
> level of abstraction without dependency on these.
>
> Also I think it should be best practice not to rely on transitive
> dependencies. If an artifact is using classes from another artifact we
> should explicitly depend on it. But that's another story.
>
>
>>
>> Also the "org/apache/stanbol/commons/usermanagement/webConsole.ftl"
>> used to render things
>>
>>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>>> javax.ws.rs.WebApplicationException:
>>> com.sun.jersey.api.MessageException: A message body writer for Java
>>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>>> MIME media type application/octet-stream was not found
>>> at
>>> com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>>
>> This could indicates that you are missing
>>
>> <groupId>org.apache.stanbol</groupId>
>> <artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
>> <version>0.12.0-SNAPSHOT</version>
>>
>> in your launcher. But also the mime type "application/octet-stream"
>> mentioned in the exception is not compatible with "text/html"
>> supported by the JAX-RS writer for RdfViewable. Because of that I
>> think that this is more related to the Accept header of your request.
>>
>> I agree that having a direct dependency to an JAX-RS writer class is
>> not a good thing. Because of that I suggest to adapt the
>> WebConsolePlugin so that it can render the Graph itself.
>>
>> private TemplateEngine<Resource> templateEngine;
>>
>> @Override
>> public void activate(BundleContext bundleContext) {
>> super.activate(bundleContext);
>> //use some getter to get the Graph that backups the UserManager
>> //TODO: a direct getter for the graph would be nice to have
>> templateEngine = new TemplateEngine<Resource>(
>> new ClerezzaBackend(userManager.getUserType().getGraph()));
>> templateEngine.setTemplateLoader(templateLoader);
>> }
>>
>> and
>>
>> protected void renderContent(HttpServletRequest req,
>> HttpServletResponse response) throws ServletException,
>> IOException {
>> try {
>>
>> templateEngine.processFileTemplate(userManager.getUserType().getNode(),
>>
>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>> response.getWriter());
>> response.getWriter().flush();
>> } catch (.. handle Exceptions ..){}
>> }
>>
>> WDYT
>
> I think that this is ugly. We should just has a service that takes an
> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
> first to sencond in the third. Or less nice but better than what we
> have now the LdRendere Service taking a GraphNode, a template-path and
> an OutputStream. Havin Both services wouldn't harm either, the first
> abstracting away from LdPathTemplates the latter being LdPath
> specific.
>
> So to recap:
> - http://localhost:8080/system/console/usermanagement was working till
> your refactoring
> - WebConsolePlugin didn't reference any Freemarker class
> - WebConsolePlugin didn't reference any JAX-RS specific class
> - WebConsolePlugin could have been improved by not invoking an LdPath
> specifc rendering service but a service to render RdfViewable (an
> which might in future support different template formats)
>
> In my opinion both the changes you committed as well as the one you
> proposed go in the wrong direction.
>
> Reto
>
>> Rupert
>>
>> On Wed, Feb 13, 2013 at 12:44 PM, Danny Ayers <[email protected]> wrote:
>>> On 13 February 2013 12:29, Reto Bachmann-Gmür <[email protected]> wrote:
>>>> In between Danny you could you write some tests for the Usermanager?
>>>> With a test the trunk version would probably not have been broken.
>>>
>>> Will do.
>>>
>>> --
>>> http://dannyayers.com
>>>
>>> http://webbeep.it - text to tones and back again
>>
>>
>>
>> --
>> | Rupert Westenthaler [email protected]
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
