On Fri, Mar 23, 2012 at 9:25 AM, Vincent Massol <[email protected]> wrote: > > On Mar 23, 2012, at 8:41 AM, Thomas Mortagne wrote: > >> On Fri, Mar 23, 2012 at 7:55 AM, Vincent Massol <[email protected]> wrote: >>> Hi devs, >>> >>> I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see >>> http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So >>> resending as a VOTE and adding ToStringBuilder >>> >>> For ToStringBuilder the idea is to create a XWikiStyle (see >>> https://gist.github.com/2164507 ) >> >> What about a XWikiToStringBuilder (or just ToStringBuilder since it's >> in a XWiki package which makes it different already) which extends >> ToStringBuilder and set XWikiStyle as default style ? > > Yep good idea, done here: > https://github.com/xwiki/xwiki-rendering/commit/bf7e97690685a7864eae592a508ba1f0bbb1a574 > >>> And then to use it as in: >>> >>> @Override >>> public String toString() >>> { >>> ToStringBuilder builder = new ToStringBuilder(this, new >>> XWikiStyle()); >>> builder = builder.append("Typed", isTyped()) >>> .append("Type", getType().getScheme()); >>> >>> if (getReference() != null) { >>> builder = builder.append("Reference", getReference()); >>> } >>> >>> if (!getBaseReferences().isEmpty()) { >>> builder = builder.append("Base References", getBaseReferences()); >>> } >>> >>> Map<String, String> params = getParameters(); >>> if (!params.isEmpty()) { >>> builder = builder.append("Parameters", params); >>> } >>> >>> return builder.toString(); >>> } >>> >>> For the record this generates stuff like the following which is based on >>> our current practices: >>> "Typed = [true] Type = [doc] Reference = [reference] Base References = >>> [[baseref1], [baseref2]] Parameters = [[name1] = [value1], [name2] = >>> [value2]]" >>> >>> The rationale for using ToStringBuilder is: >>> * It reduces our boilerplate code by at least 50% >>> * It makes all our toString implementation consistent and easy to write >>> >>> Now all that remains is to decide where to put the XWikiStyle class. Of >>> course it has to go in XWiki Commons somewhere but where? >>> >>> I'm proposing several possibilities: >>> * xwiki-commons-logging (existing module): the rationale would be that the >>> toString() is usually used for logging. The package would be >>> org.xwiki.logging.text. I'm wondering if we should make this class internal >>> too. >>> * xwiki-commons-text (new module): I'm not sure what else we would put in >>> there >>> * xwiki-commons-util (new module): I don't like to have a module with no >>> specific domain but it could be temporary till there are more stuff that >>> make a domain >> >> * xwiki-commons-lang (new module): to follow the same logic as Apache >> commons naming. >> >>> >>> So here's my +1. >> >> +1, I'm already using HashCodeBuilder and EqualsBuilder when the >> equals is starting to be complex (I tough I had answered to the mail >> actually :)) >> >>> My only doubt is where to put it. Right now I'd be tempted to put it in >>> xwiki-commons-logging so that we don't create a new module. >> >> I'm not sure either. I would say +1 for xwiki-commons-lang with as >> less dependencies as possible (probably only apache commons-lang), if >> we want all module to use it as standard toString lets make it as >> light as possible. Right now there is very few modules that need >> logging-api (it's not required to log) so I would prefer avoid having >> to put it in dependency only for a toString. It would also avoid >> circular dependency issues if for example we want to us XWiki >> ToStringBuilder in any of logging-api dependencies like >> observation-api or components-api. >> >> Other possibility is xwiki-commons-component-api since everything >> already depends on it but it's not really component domain so I don't >> like it too much. > > Ok for xwiki-commons-lang for now but I'm not sure I like it that much. When > it starts to grow and there will be several classes for a given domain I > think I'll prefer to move the code to its own module. Like we do with > xwiki-commons-xml for example. Which is why I had suggested > xwiki-commons-text … > > It looks better to me to have xwiki-commons-xml and xwiki-commons-text side > by side. > > BTW the reason for "text" is because that's the package used by commons-lang > for this ;)
I'm ok with xwiki-commons-text too, I'm mostly against putting it in a module which depends on other commons modules. > > WDYT? > > Thanks > -Vincent > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
