On Tue, Feb 5, 2013 at 12:59 PM, Rupert Westenthaler < [email protected]> wrote:
> On Tue, Feb 5, 2013 at 11:59 AM, Reto Bachmann-Gmür <[email protected]> > wrote: > > 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 > ). > > > > I would rather use the {main}-{sub} as this is already used by some modules > > The folder > > commons/web/viewable > commons/web/viewable-ldpath > > are mapped to > > o.a.stanbol.commons.web.viewable > o.a.stanbol.commons.web.viewable.ldpath > > > > 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. > > > > Ok than I suggest to keep RdfViewable in the commons.web.viewable > module. IMO Viewable is OK for most of the things it is used by Apache > Stanbol (e.g. RESTful service documentation). For pages that visualize > entity information I agree. > If it wouldn't be mixed in the classes providing the actual services the pojo-based rendering would be so bad but de-facto is mixed with the service. Apart that its good to established the same best practices and not have sepcial cases unless this realy provides an advantage it seems that having the RDF here would indeed be useful: the documentation is mainly static content the non-static part are mainly the URIs of the services. This information is also need for machines discovering the services. So if we want stanbol to be a rest service this information must be available in a machine readable fashion. If stanbol becomes a rest service and the documentation is generated from the discovery data we also reduce the risk of having inconsistency between documentation and implementation (as we have a history of [1]). > I suggest also move the two Viewable classes to the > 'org.apache.stanbol.commons.web.viewable' package and keep deprecated > version in the original pakcage for backward compatibility. > Not sure if the renaming is needed. After all this is just tuple of a resource and an abstract rendering instruction, this can be used for the web as well as for other purposes such as e.g. for email. Cheers, Reto 1. http://wiki.iks-project.eu/index.php/Netlabas_Proposal/validation > > best > Rupert > > > > 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 > >> > > > > -- > | Rupert Westenthaler [email protected] > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen >
