Closed Daniel-Svensson closed 3 weeks ago
For manual setting:
The settings class will probably be called
UriShchem - really need a better name but unknown
fyi: I added a short section about having an assembly level attribute and try to have it affect both the server and client without any other public api changes
The current Uri schema of "NAMESPACE-TYPENAME.csv/binary/MethodName" is quite long/verbose and can be simplified.
Some of the current issues are that
Proposed Solution
1. Manual service paths
A: Allow specifying paths at startup configration
Uri
to the DomainContextB; Allow specifying name via attributes
similar to now AspNetMvc allows name to be configured for
[Route("Name")]
This approach means we should/can also
2. New Naming schemes
We add 2 new url naming options
With the following additional variants for backwards compatibility
Configuration
1. Server side
Should we do a "builder" api?
2. And/or options
If so
Action<**Option>
parameter or by aConfigure[Options](Action<**> )
on a build class3. Attribute based
Add an (assembly level) attribute that specify the endpoint scheme.
Attribute name should probably be something like:
[Default]DomainService[Endpoint][Route][***]Attribute
Possible enum names
Pros:
Cons:
Questions:
Client Side
1. manual setting on BinaryHttpDomainClientFactory
Should we add a setting similar to below ? it would have to "rewrite" any url passed into DomainContext constructor
2. Should we add a setting to the code generation =
If we add a msbuild parameter (or maybe assembly attribute in server project) we can change to code generation to emit the new kind of UrlScheme
1. Manual service paths
Should we allow both A and B ?