Hi Rupert, You're right that a restructuring cleaning is needed and useful. You're proposals definitively go in the right direction.
By our current naming/dirctory convention we cannot have o.a.s.commons.web.viewable.ldpath and o.a.s.commons.web.viewable the latter would have to be o.a.s.commons.web.viewable.core (unless we would change our convention as I ssuggested in: http://mail-archives.apache.org/mod_mbox/stanbol-dev/201212.mbox/%3ccalvhueuhyh2ur6ca0vponqdhaq6uttr2m0xsg7qp6acsdzb...@mail.gmail.com%3E). It is not clear to me if RdfViewable and the legacy Viewable should they be moved to the same module as the writer. If so then module name should not be tied to ldpath as RdfViewable is potentially usable with many rendering mechanism. So for the package name I don't think there 's anything wrong with o.a.s.commons.viewable.RdfViewable.Medium-term we should deprecate Viewable as this technique inherited from jersey fosters a tied coupling of application logic and presentation and isn't linked data friendly. Cheers, Reto > > On Mon, Feb 4, 2013 at 6:47 PM, Rupert Westenthaler < [email protected]> wrote: > Hi all > > after a more detailed look I came to the following solution: > > LdRenderer (in o.a.s.commons.ldpathtempate) has several responsibilities: > > (1) loading Freemarker templates from Bundles (basically freemarker > TemplateLoader) > (2) rendering RdfViewable > (3) rendering Viewable > > Other than that the whole module is just a branch of the > ldpath-template module that is compatible to the LDpath version > currently used by Stanbol. > > The suggestion is to: > > * refactor the (1) to BundleTemplageLoader, an OSGI service that > implements TemplateLoader. This service can be provided by the > o.a.s.commons.web.viewable module > * move (3) to the ViewableWriter: > * create a new module o.a.s.commons.web.viewable.ldpath that provides > the LdViewableWriter containing (2). Loading of Templates is provided > by an injected TemplateLoader instance (the BundleTemplageLoader > implementation provided by the commons.web.viewable module) > > The o.a.s.commons.ldpathtempate can be completely removed as soon as > we upgrade to an LDpath version where the ldpath-template module is > available in maven central. > > In addition I would suggest to move the Viewable and RdfViewable > classes to the correct packages but keep the old classes (marked as > @deprecated) for backward compatibility) > > I have already implemented ~80% of the suggestion and to me it feels > much better as the current soltution > > WDYT > Rupert > > > On Mon, Feb 4, 2013 at 3:28 PM, Rupert Westenthaler > <[email protected]> wrote: > > Hi all > > > > While working on the Stanbol Bundlelists I discovered that the > > o.a.s.commons.web.viewable module depends on LDpath. A dependency that > > is IMO unwanted. > > > > The reason for that is that all Stanbol JAX-RS and Web UI modules do > > depend on Viewable to render the Web UI. Because of that all such > > modules depend also on LDpath without actually using it. > > > > I see two alternatives: > > > > 1) moving the LDpath specific Writer to ldpathtemplate module (would > > add JAX-RS dependency there) > > 2) creating an additional module providing LDViewable > > > > In addition the ViewableWriter will need to be changed so that it no > > longer used the LDPath renderer > > > > WDYT > > Rupert > > > > > > -- > > | 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 >
