Ok, then at least stick with Niclas suggestion of having a class encapsulating this and not having the MD5 and UnsupportedEncodingExceptiosn leak into all kinds of types of qi4j ...
Michael Am 28.02.2009 2:39 Uhr, schrieb Rickard Öberg: > Michael Hunger wrote: >> I looked at the implementation and would like suggest the following to >> reduce the coupling to MD5 and to >> "UnsupportedEncodingExceptions" (and allow different >> SchemaVersionCalculations). >> >> 1) create an interface SchemaVersion >> 2) rename the methods on ValueType etc. to versionize(SchemaVersion) >> 3.1) add such methods on QualifiedName and TypeName (to be created class) >> 3.2) or have SchemaVersion.update(QualifiedName) and updateFrom(TypeName) >> 4) have methods like update(byte[]), byte[] calculage(), String base64() on >> SchemaVersion >> >> have a subclass of the interface called MD5SchemaVersion which is used in >> EntityType. > > It is essential that all schema calculations be done the same way. If > you plug them, then yes, you have to specify with the schema what > algorithm was used to create them. I fail to see the point of it... why > not just use the default one? What is the gain of pluggability, > considering the increase in complexity? > > /Rickard > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Michael Hunger Independent Consultant Web: http://www.jexp.de Email: [email protected] Enthusiastic Evangelist for Better Software Development Don't stop where you are: http://creating.passionate-developers.org We support Software Engineering Radio (www.se-radio.net) _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
