aik099/qa-tools — pull request #48 by aik099 (2014-05-13 09:15:57+00:00)
Title: Introduce `ElementCollection`

Right now we have `RadioGroup` typified element which is initialized off a single radio button given and have methods for operating on a set of radio buttons in a group.

Currently this poses 2 problems:

1. methods, inherited from `TypifiedElement` class (e.g. `getAttribute`) doesn't make any sense, because they will only operate on the radio button that was used to initialize collection (see #46)
2. other radio buttons within a group are located incorrectly (see #47)

We'll also have more problems when #13 will be implemented and when `RadioGroup` class will be used in combination with `[]`, then it will be hard to determine (when `@find-by('name' => 'radio-button')` selector is used) where found elements should go:

1. into AbstractProxy iterator proxy
2. into the RadioGroup

I'm proposing to introduce the `ElementCollection` class (won't be `TypifiedElement` sub-class) that will be initialized off the given array of elements.

It will also have static `generateCollections(array $elements)` method, that would allow to create a logically associated element collections based on given set of unrelated elements.

Then `AbstractProxy` (after change in #13) can, in case if element to create is sub-class of `ElementCollection`, ask it to group elements as it see fit and return back to `AbstractProxy` class to store.

In case of `RadioGroup` (which will extend `ElementCollection` now) we'll have `generateCollections` method implemented the way to:

1. find all radio buttons with same `name` in same form (physically or by the `form` attribute value) and create collection from it
2. find radio buttons without `name` and put each one in it's own collection
3. the `__construct` that accepts array of elements won't have any logic in it

In contrast to current implementation the radio buttons that are added dynamically won't be catched.