RequestAdaptor support all fields template

[hhhcj]

Another way to solve #903 , besides #905, #907

[localvar]

hi @hhhcj , thanks for the PRs.
however, as I mentioned in another thread, this is one of the most complex parts of Easegress though it looks simple.

the best practice would be analysis the problem and make a careful design before coding.

[codecov-commenter]

Codecov Report

Base: 73.16% // Head: 73.07% // Decreases project coverage by -0.10% ⚠️

Coverage data is based on head (5bc60a7) compared to base (eec7d77).
Patch coverage: 75.29% of modified lines in pull request are covered.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #910      +/-   ##
==========================================
- Coverage   73.16%   73.07%   -0.10%     
==========================================
  Files         131      131              
  Lines       15007    15055      +48     
==========================================
+ Hits        10980    11001      +21     
- Misses       3403     3427      +24     
- Partials      624      627       +3     

Impacted Files	Coverage Δ
pkg/object/function/spec/function.go	93.75% <ø> (ø)
pkg/filters/builder/responseadaptor.go	64.28% <70.96%> (ø)
pkg/filters/builder/requestadaptor.go	75.37% <77.77%> (ø)
pkg/object/mqttproxy/sessioncache.go	49.49% <0.00%> (-10.11%)	⬇️
pkg/object/mqttproxy/broker.go	73.25% <0.00%> (-0.47%)	⬇️
pkg/object/mqttproxy/topic.go	47.05% <0.00%> (ø)
pkg/tracing/cloudflare.go	90.00% <0.00%> (+0.34%)	⬆️
pkg/filters/validator/basicauth.go	76.53% <0.00%> (+1.53%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[hhhcj]

hi @hhhcj , thanks for the PRs. however, as I mentioned in another thread, this is one of the most complex parts of Easegress though it looks simple.

the best practice would be analysis the problem and make a careful design before coding.

A new commit with template support for ResponseAdaptor. @localvar

[localvar]

hi @hhhcj , path must be handled, this may require redesigning the underlying structure of the template (that's not using the Spec).

[hhhcj]

add another pa in template spec

hi @hhhcj , path must be handled, this may require redesigning the underlying structure of the template (that's not using the Spec).

[localvar]

add another pa in template spec

hi @hhhcj , path must be handled, this may require redesigning the underlying structure of the template (that's not using the Spec).

hi @hhhcj , please do not just solve the problem, we should try to solve it in the better or best way.
using the pathadaptor.Spec directly is not user-friendly, as I have mentioned:

however, we don't need to (and should not) use pathadaptor.Spec for it, because in the template, we can easily do more than pathadaptor.Spec in a more straightforward way.

and

this may require redesigning the underlying structure of the template (that's not using the Spec)

[hhhcj]

I get your point now. For the path, we could use another field eg. PathStr, or rename Path to PathSpec which is not backward compatible and add a field Path string to the spec. So template can shares the structure type with static field, and this will be more straightforward on path field.

But if we define that template to complete replace the static word, changing one of the field name to another or adding a new field that static field doesn't own may confuse the user that someone think the template field may work, but after trying, he found that the field has been renamed to another. We designed it to be straightforward and user-friendly but result to be unstraightforward and user-unfriendly. Is it worth to do this? Though we support the whole pathadaptor.Spec in template, but users can simply use pathadaptor.Spec.replace to modify the path by theirselves. @localvar

add another pa in template spec

hi @hhhcj , path must be handled, this may require redesigning the underlying structure of the template (that's not using the Spec).

hi @hhhcj , please do not just solve the problem, we should try to solve it in the better or best way. using the pathadaptor.Spec directly is not user-friendly, as I have mentioned:

however, we don't need to (and should not) use pathadaptor.Spec for it, because in the template, we can easily do more than pathadaptor.Spec in a more straightforward way.

and

this may require redesigning the underlying structure of the template (that's not using the Spec)

[hhhcj]

I called to @samanhappy last thursday, and knew that there will be two definitions on template, one is defining a glabal uniform structure for template or filter differenced template structure. If the latter one we choosed, the template should realize all of the static field directly.

[localvar]

hi @hhhcj , after think it twice, I think your comments make sense.
however, please don't use the spec of the filter as the template, as many fields of the spec are not needed by the template. the better way is to define the template as a standalone structure and embed it into the spec.