Hi,
On 19/05/14 13:50, Nick Burch wrote:
On Mon, 19 May 2014, Sergey Beryozkin wrote:
I've just looked at the source, unfortunately adding a new Path value
will affect the request URIs, UnpackerResource has 2 methods accepting
path segments starting from "/unpacker" and "/all".
So if we updated then the users would have to modify URIs to contain
"/unpack/unpacker1", etc, as opposed to the current "unpacker1".
I think it might be good to push them into a common path prefix. Though
/unpack/unpacker seems a bit unwieldy...
If we do introduce "/unpack" then may be we can drop "/unpacker", and
have two methods with "/" & "/all", so users will work with "/unpacker"
& "/unpack/all"
If it only had 1 resource method then we'd just push that method's
Path up and update the method's Path to "/", but it has 2 methods.
I suppose worst case we could create an abstract parent, put most of the
logic there, then have two classes one per method?
Introducing the inheritance will not change the target URI
I'm not sure how used is UnpackerResource. If no one uses it or very
few users use it then may be it is the right time to introduce a
class-level Path and document the possible migration task.
Maybe we should post to users@, and see if anyone says they do?
Sounds good, please ask or I can do it, let me know please
Thanks, Sergey
Thanks
Nick
