Ulrich_Laegeler at arburg.com wrote:
>
> the problem is also related to version 4, so i think the code is at least
> similiar.
>
> As i mentioned earlier the problem is not there for insertion the element
> directly.
> In this case the required code for using wildcards in content model is
> available.
>
> Excerpt of CommandUtil.findField
> -----------------------------
> if (name != null) {
> if (name == searchedName) {
> found = field;
> break;
> }
> } else {
> hasWildcards = true;
> }
> }
>
> if (found == null && hasWildcards) {
> for (int i = 0; i < count; ++i) {
> Field field = (Field) fieldList.get(i);
>
> NameClass nameClass = field.getFieldNameClass();
> if (nameClass != null &&
> nameClass.containsName(searchedName)) {
> found = field;
> break;
> }
> }
> }
> --------------------------------
>
> You just have to add a similiar code to FieldChoice.findField(Field[] fields,
> ElementTemplate template,
> Element parent,
> ElementTemplates templateSet)
>
> That's not really difficult, isn't it?
>
Nothing is simple when you work on a product. For example, may be what
you suggest
* is too simplistic,
* or break things in some cases,
* or causes XXE to be noticeably slower.
Because you seem to insist, we'll give a serious look at your specific
problem, but we cannot promise that we'll remove this limitation -- or
call it a bug if you prefer -- in next release.
> BTW every bug is a limitation
>
I'm sorry but I don't agree. Bugs are caused but *errors* made by a
programmer. Limitations on the other hand are *compromises* which can be
tolerated in rarely used cases such as yours (i.e. content models
containing wildcards).
