<div dir="ltr">Hello, important change for the Spec users.<div><br></div><div>In "The Spec UI Framework" book you can read:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Considering the construction and orchestration of the different widgets in<br>a user interface, Spec is inspired by the Model-View-Presenter pattern. The<br>model that is defined in Spec corresponds to a presenter in the MVP triad.<br>Note that because of this, future versions of Spec may rename the ComposableModel into ComposablePresenter for naming consistency.</blockquote><div><br></div><div>This change was done in the Pharo 7 development images by this pull request:</div></div><div><a href="https://github.com/pharo-project/pharo/pull/344">https://github.com/pharo-project/pharo/pull/344</a><br></div><div><br></div><div>All other Spec presenters that use suffix -Model were renamed too to end with -Presenter suffix. This is the complete list:</div><div><br></div><div><div>AbstractFormButtonModel</div><div>AbstractWidgetModel</div><div>ButtonModel</div><div>CheckBoxModel</div><div>ComposableModel</div><div>ContainerModel</div><div>DateModel</div><div>DialogWindowModel</div><div>DiffModel</div><div>DropListModel</div><div>DynamicComposableModel</div><div>FastTableModel</div><div>IconListModel</div><div>ImageModel</div><div>LabelModel<br></div><div>ListModel</div><div>ListSelectionModel¬†<br></div><div>MenuGroupModel</div><div>MenuItemModel</div><div>MenuModel</div><div>MultiColumnListModel</div><div>PickListModel</div><div>RadioButtonGroupModel</div><div>RadioButtonModel</div><div>SliderModel</div><div>TabManagerModel</div><div>TabModel</div><div>TableContainerModel</div><div>TestingComposableModel<br></div><div>TextInputFieldModel</div><div>TextModel</div><div>TickingWindowModel</div><div>TransferModel</div><div>TreeColumnModel</div><div>TreeModel</div><div>TreeNodeModel</div><div>WindowModel</div><div>WorldModel</div></div><div><br></div><div>To be sure that most of the current code which uses the old name will work, we created for every renamed class a subclass with the old name. These subclasses are moved (mostly) into Spec-Deprecated package. Currently such deprecation does not make any action so no exception is generated nor no code is rewritten. We will add such mechanisms in future as soon as most users and documentation will adopt his change.</div><div><br></div><div>This deprecation can cause problems in two cases: you use code like 'isKindOf:' or if your package adds extension methods to the basic Spec classes.¬†</div><div><br></div><div>To rename these classes was only the first step. We need to rename some Spec tests classes and mainly touch methods like <b>instantiateModels:</b>¬†and later make them deprecated.</div><div><br></div><div>We are sorry for troubles that these changes can cause but it is necessary to make the Spec code less confusing.</div><div><br></div><div>Cheers,</div><div>-- Pavel</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>