On Dec 31, 2009, at 1:20 PM, Sergiu Dumitriu wrote: > On 12/31/2009 12:39 PM, Vincent Massol wrote: >> Hi devs, >> >> I'm almost done with my entity reference refactoring and I've just >> realized I have missed something I think. So far the implementation >> only supports Absolute references (i.e the entity reference factory >> always return a reference with all parts filled - you choose to use a >> default factory or a current entity depending on how you wish to >> resolve the names when they have not been provided in the passed >> reference string). >> >> I now think we must also support relative references (i.e. when some >> parts can be null) and that it's up to the user of the api to decide >> if they want to convert a relative reference to an absolute one or >> not. >> >> Here's a use case: renaming of documents. For exemple documents have >> links specified as a string representing the target doc name. If we >> don't have relative references then we need to decide if we want to >> use the default serializer (all parts printed including wiki name) or >> the compact serializer (only parts different from context reference >> printed). This doesn't support printing only what the user had >> decided >> to fill. For ex a user might have specified voluntarily the space and >> page name and right now with my implementation he'll get only the >> page >> name specified if the new space is the same as the space for the >> current doc. >> >> So here's my proposal: >> >> * Entity Reference Factory leaves parts to null when not specified in >> the string representation. >> * We add a EntityReference.getAbsoluteReference(EntityReference base) >> method to return an absolute reference. It's resolved against the >> passed base reference (i.e. parts not specified are taken from it) > > What happens when the passed base is not what should be? Should the > implementation fall back to the current document?
We could throw an IllegalArgumentException for example. That said, I'm still hesitating between having this getAbsoluteReference() API and adding a EntityReferenceResolver interface: EntityReferenceResolver |_ EntityReference resolve(EntityReference) and have several implementations: CurrentEntityReferenceResolver, DefaultEntityReferenceResolver, etc (as I have now for EntityReferenceFactory). Thanks -Vincent >> WDYT? >> >> I'm going to start refactoring my code to do this later today so >> please let me know if you see any pb with it. > > Looks good, +1. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
