This adds a RawRequest object. Rather than passing around line and index we are storing them in this object which will be used for request level data, and data received prior to parsing our line. This fits better in our data model, it gives us a nice default object piggy backing off of our Select overload. Going forward the pattern when working with information received prior to creating our IFrameLine is the data should be stored in RawRequest and passed down as such. This is also currently a dependency of any pre-filters that will be built.
Haven't given this too much thought yet but if we wanted to decouple pre-filters from RawRequest so it's up to the implemented class to define what, if any, data it needs we could do something like register RawRequst as a scoped item and update the values in our select overload. I don't like the idea of having that scoped state and letting those values get mutated at any point in our lifecycle though because it takes a lot of the trust away. Something that might be better is registering a list in RawRequests that we can push up to as we receive our lines _lineBreaker.BreakIntoLines(input).Select((value, i) => RawRequest.PushLine(value, i). At that point we know where the most recent raw request is if we need to access that and a nice side affect is we'd be able to do things like look behinds on previous lines if need be.
In that case our IPreFilter would be identical to IFilter so maybe even just add a "type" property for the inheriting class to implement that takes a FilterType (or FilterLifecycle maybe) enum of Pre or Default. Then it can be left up to a filter runner function to take in the LifeCycle value and run the relevant filters as needed. This isn't super necessary however I thought it could lead to a pattern where we have a single Filter base class that is inherited by all of our filters where we can keep shared logic, such as a static filter runner, and the process for adding additional LifeCycles for a filter is just a matter of adding to the enum rather than creating a new interface and registering it.
xiaomi7732
commented
2 years ago
This adds a
RawRequestobject. Rather than passing around line and index we are storing them in this object which will be used for request level data, and data received prior to parsing our line. This fits better in our data model, it gives us a nice default object piggy backing off of our Select overload. Going forward the pattern when working with information received prior to creating ourIFrameLineis the data should be stored inRawRequestand passed down as such. This is also currently a dependency of any pre-filters that will be built.Haven't given this too much thought yet but if we wanted to decouple pre-filters from
RawRequestso it's up to the implemented class to define what, if any, data it needs we could do something like register RawRequst as a scoped item and update the values in our select overload. I don't like the idea of having that scoped state and letting those values get mutated at any point in our lifecycle though because it takes a lot of the trust away. Something that might be better is registering a list in RawRequests that we can push up to as we receive our lines_lineBreaker.BreakIntoLines(input).Select((value, i) => RawRequest.PushLine(value, i). At that point we know where the most recent raw request is if we need to access that and a nice side affect is we'd be able to do things like look behinds on previous lines if need be.In that case our IPreFilter would be identical to IFilter so maybe even just add a "type" property for the inheriting class to implement that takes a FilterType (or FilterLifecycle maybe) enum of
PreorDefault. Then it can be left up to a filter runner function to take in the LifeCycle value and run the relevant filters as needed. This isn't super necessary however I thought it could lead to a pattern where we have a single Filter base class that is inherited by all of our filters where we can keep shared logic, such as a static filter runner, and the process for adding additional LifeCycles for a filter is just a matter of adding to the enum rather than creating a new interface and registering it.