On Mon, Feb 18, 2013 at 6:37 AM, Rupert Westenthaler < [email protected]> wrote:
> On Thu, Feb 14, 2013 at 2:43 PM, Reto Bachmann-Gmür <[email protected]> > wrote: > > Hi, > > > > I did some re-refactoring yesterday to me there's one open point with > > STANBOL-910 which I described in the latest comment. If I don't get any > > feedback I'll go for the suggested approach of merging the two > > viewable-writer modules but I can live perfectly well we the other > > described approach (separate rdfviewable-writer module). > > > > I am -1 for making the Stanbol UI depending on LDpath. Simple because > I do not see a good reason why one would need such an dependency. > As I said I can live with the variant where the RDF Writer is separater from the legacy Vieawable. But for your dependency reduction argument I would like to point to your attention that with the version previous to my refactoring every stanbol component was depending on freemarker. This was the independently on wheter it would use this capabilities or not. Now a module depends only on the rendering mechanism it actually needs. Also note that ldpathtemplate is very small, especially considering that we use ldpath anyway. > > I also think that commons.ldpathtemplate should be removed as soon as > we switch to a newer LDpath version for that the ldpathtemplate code > is available as bundle in maven central. No. like commons.freemarker this is not supposed to mainly be a bundle providing ldpathtemplate as a bundle. It only does so because no usable bundle was available. Its main purpose it provide a service for simple access to this rendering avoiding code duplication. > I plan to work on the upgrade > to the newest LDpath version as soon as the first version with the > org.apache.marmotta.ldpath packages is released. This was also the > reason why I tried to remove all other functionality out of this > bundle. Now with the new LdRenderer this will be no longer possible - > but maybe thats ok as I do not see an other module where the > LdRenderer fits well. > Neither on http://incubator.apache.org/marmotta which doesn't exist nor on http://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201302.mbox/browserI find any reference to the package your preparing for its release. So I'm afraid this might have more to do with a Salzburg research agenda than with the community process. > > Having an own commons/freemaker module is IMO a good ides, as it > solves the issue that commons.web.core embeds and exports freemaker. > It can also be handy if we want to seperate the WebUI from the RESTful > services at a later point in time. > Tha's not to be postponed to a later point in time. I'm working on the archetype which shows how RESTfull services can be build. Stanbol was always about REST, yet we are not yet providing a single REST service. With the RDF based frontend we get closer to this. As standard RDF formats and well defined ontologies will satisfy the hypermedia requirement of REST. The infrastructure is there, the task is remove the usage of Viewable and use RDF to describe the service to its client (with RDFVieablw this RDF can be converted to a human friendly representation if the respective bundles are present). Cheers, Reto > > best > Rupert > > > Cheers, > > Reto > > > > On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ < > [email protected] > >> wrote: > > > >> Hi, > >> > >> I agree that we should avoid to work on many things in parallel. Try > >> to implement and commit things step by step. Otherwise things are hard > >> to follow and not easy to revert if discussion come up. > >> > >> To the situation at hand: I can not say anything on the technical > >> level to the concrete problem. Are you now in the position Reto to > >> work around the refactoring and make the usermanager work again for > >> you? Once it runs again - we should find a consensus how things should > >> be changed. > >> > >> Best, > >> - Fabian > >> > >> 2013/2/13 Reto Bachmann-Gmür <[email protected]>: > >> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler > >> > <[email protected]> wrote: > >> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür < > [email protected]> > >> wrote: > >> >>> > >> >>> Please just restore the original LdRenderer service an the > >> >>> corresponding version of the UserManager. We can add an > >> >>> RdfViewablRenderer service later, I think its overarchitecture to > >> >>> separate out the LDVieable implementation. But first things first: > >> >>> restore the better status quo ante with the Ldrenderer. > >> >> > >> >> LDRenderer was in ldpathtemplate; I created a new module, added those > >> >> to bundlelists (both in trunk and a branch); changed exports and > >> >> import statements that are now conflicting with an lot of additional > >> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I > >> >> think reverting is no longer an option as it would take longer as > >> >> implementing the service as suggested above. > >> > > >> > I think we should avoid working on an issue while dependent issues > >> > aren't resolved. > >> > > >> > Also removing the LDRenderer service was not something which was clear > >> > that this would happen neither from the description of the issue nor > >> > from the discussion on the list. > >> > > >> > As you refuse to do it, I'll read the LdRenderer service (using your > >> > new TemplateLoader service) so that UserManager can be reverted to > >> > where the code was both more elegant and working. > >> > > >> > Reto > >> >> > >> >> best > >> >> Rupert > >> >> > >> >> -- > >> >> | Rupert Westenthaler [email protected] > >> >> | Bodenlehenstraße 11 ++43-699-11108907 > >> >> | A-5500 Bischofshofen > >> > >> > >> > >> -- > >> Fabian > >> http://twitter.com/fctwitt > >> > > > > -- > | Rupert Westenthaler [email protected] > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen >
