roryprimrose / headless Goto Github PK

Developers should be able to return a singular entity using a predicate condition.

Drop down lists by default take the first item as the selected item if no item in the list is explicitly selected.

Creating a PostEntry instance shouldn't require the developer to specifically cast all values to a string. There should be a constructor that takes in object as the value. Other constructor overloads should also be provided for the common value types to avoid boxing/unboxing for the common types.

The extension methods for the dynamic model return the dynamically resolved page type. Browser however does not return this when it stores the last successfully loaded page as it only stores the DynamicResolverPage instance.

Need to allow for access to value and text of individual options within a list.

The code attempts to load all the types from all assemblies in the application domain. A ReflectionTypeLoadException is thrown when one of those assemblies has an assembly reference that is not available.

See http://stackoverflow.com/questions/7889228/how-to-prevent-reflectiontypeloadexception-when-calling-assembly-gettypes for the workaround

There is currently no simple way to select a single element using the selectors determined by the generic constraint. The closest equivalent is Find.All().EnsureSingle().

Any failure from Browser in a request execution should throw HttpOutcomeException to provide a consistent handling scheme.

The NuGet spec allows for framework targeted references. A multi-framework targeted package will be able to produce a lean 4.5 version and then a 4.0 version that pulls in the HttpClient package.

Currently there is only AllByAttribute. Functionality should be provided to search for a singular element by an attribute name/value pair.

Form elements must be submitted with a name, but this should still support ignoring form elements that don't have names (elements that are client side only for example).

There are two issues with the current implementation.

1. Page.IsOn verifies against the current location (which will always be true) whereas it needs to verify against the target location.
2. Paths that only differ by a trailing / are considered different

Browser should have the ability to define the Accept-Language header.

The behaviour of a select element in the browser is that a selected option will submit its text value if there is no value attribute. The current implementation submits value attributes only.

The browser should provide access to the last loaded page rather than that reference only being managed by the developer within a test.

There are two problems with the current location verification.

1. Does not support multiple possible target locations without overriding IsOn
2. Does not support custom data in locations because locations are defined against the page type rather than the page instance

Solutions to this are to provide the framework for validating multiple target locations so that a derived page only has to define the possibilities, not the validation logic.

The second point is already taken care of in terms of navigation because the specific location can be requested via the Browser class. The solution above for #1 will then also solve the validation of custom data in locations.

There is more information about the page that a caller may want to inspect other than just the HttpResult. Exposing this via the exception means that they don't need to consult browser.Page when the exception is thrown.

Searching AllByTagName fails to resolve elements when the html has a default namespace (such as an XHTML document).

Requests to find items in the list should match on the text regardless of whether the option already has a value.

It is helpful to see the full HttpResult set when HttpOutcomeException describes a status failure.

The target location is unreliable because the currently location might be different. The link action should be relative to the current page location rather than the default navigation target of the page model.

Currently the only way to post a file is to use a page that uses a file input type. The api should expose this via code using both file path and stream overloads.

The dynamic model can not resolve extension methods. This means that many of the finder methods are unavailable to the dynamic page model without having to cast to IHtmlPage first.