On Wed, Mar 10, 2010 at 7:55 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi all, > > We currently have a multi-faceted issue: We have the Sling API bundle > containing a number of utility classes (HtmlResponse, ResourceUtil). In > addition there are two utility classes in the Engine bundle > (RequestUtil, ResourceUtil) which are of general interest. > > The problem with the locations of these classes are (1) mixing > implementations into an API bundle is problematic, (2) extending > implementations means increasing the API version, (3) using the Engine > bundle utilities creates a dependency on the Engine bundle. > > I think we should create a new Utilities bundle which will host these > utility classes. > > The classes are simply copied and then further developed in the new > utilities bundle while the old classes are simply deprecated and removed > in future versions. This will keep the classes distinct and not create a > dependency to the new util bundle in the API bundle. > > WDYT ?
In general, when a class/package/bundle is named something *Util, I usually suspect that it is a catch-all for stuff that doesn't naturally belong anywhere else. So perhaps we should find a better name, and possibly divide it into multiple units. In the case of RequestUtil, ideally, those methods would be moved to SlingHttpServletRequest, but I guess there are reasons why they're not already there. That said, I'm all for moving util stuff out of Engine. I think moving HtmlResponse will be hard, since it is used as parameter for SlingPostOperations, so there will be huge backward compatibility trouble. If we are to move it anyway, I'd really like to rewrite it to an interface "PostResponse", which will be implemented by a (new) HtmlResponse class and the newly-introduced JsonResponse. -- Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
