Я бы использовал Conductor.AllActive
, потому что иначе жизненный цикл ваших подэкранов не будет соблюдаться должным образом. Вы можете обнаружить, что подэкраны не активированы должным образом. Будет ли использование Conductor.AllActive
исправить утечку памяти, я не знаю. Очень легко выяснить, будет ли он использоваться или нет, я все еще буду использовать Conductor.AllActive
, ваш сценарий - это именно тот сценарий, для которого он был разработан.
Я наконец понял это и хотел передать то, что я сделал, на случай, если кто-то другой столкнется с этим .
Когда я генерировал представления для Team, блок формы в edit.gsp выглядел так:
<input type="hidden" name="id" value="${teamInstance?.id}" />
<input type="hidden" name="version" value="${teamInstance?.version}" />
<div class="dialog">
<table>
<tbody>
<tr class="prop">
<td valign="top" class="name">
<label for="mascot">Mascot:</label>
</td>
<td valign="top" class="value ${hasErrors(bean:teamInstance,field:'mascot','errors')}">
<input type="text" id="mascot" name="mascot" value="${fieldValue(bean:teamInstance,field:'mascot')}"/>
</td>
</tr>
<tr class="prop">
<td valign="top" class="name">
<label for="players">Players:</label>
</td>
<td valign="top" class="value ${hasErrors(bean:teamInstance,field:'players','errors')}">
<g:select name="players"
from="${Player.list()}"
size="5" multiple="yes" optionKey="id"
value="${teamInstance?.players}" />
</td>
</tr>
</tbody>
</table>
</div>
<div class="buttons">
<span class="button"><g:actionSubmit class="save" value="Update" /></span>
<span class="button"><g:actionSubmit class="delete" onclick="return confirm('Are you sure?');" value="Delete" /></span>
</div>
</g:form>
но блок формы в create.gsp выглядел так:
<g:form action="save" method="post" >
<div class="dialog">
<table>
<tbody>
<tr class="prop">
<td valign="top" class="name">
<label for="mascot">Mascot:</label>
</td>
<td valign="top" class="value ${hasErrors(bean:teamInstance,field:'mascot','errors')}">
<input type="text" id="mascot" name="mascot" value="${fieldValue(bean:teamInstance,field:'mascot')}"/>
</td>
</tr>
</tbody>
</table>
</div>
<div class="buttons">
<span class="button"><input class="save" type="submit" value="Create" /></span>
</div>
</g:form>
Другими словами, для этого углового случая, в представлении «Создать» по умолчанию виджет не отображается, чтобы правильно отображать список с множественным выбором. Когда я скопировал и вставил отсутствующий код, динамически созданный контроллер подобрал его и сохранил, как и ожидалось. Так что это определенно ошибка в коде генерации представления.
Да, в шаблоне по умолчанию родительский селектор помещается на страницу создания / редактирования дочернего класса.
Я предполагаю, что так им было проще. Однако это не должно быть множественного выбора, а только одиночный выбор из раскрывающегося списка, поскольку это режим «один ко многим».
Как вы объяснили, вы хотели большего количества отношений «многие ко многим», вы может попробовать добавить:
static hasMany = [teams:Team]
в ваш класс Player. Я обнаружил, что Grails лучше справляется с двунаправленными отношениями. Его также полезно иметь при построении поисковых запросов, и при этом не требуется более одной таблицы отношений, которая вам уже нужна.
Если вы используете Grails до версии 1.1, отношения «многие ко многим» отсутствуют. t напрямую поддерживается, поэтому даже добавление статического hasMany выше не будет полным решением, как вы Мне нужно будет управлять добавлением в другой список, когда вы добавляете в одно направление. Я еще не использовал v1.1, поэтому я не могу говорить о том, что необходимо для указания в нем многие-ко-многим.