Hi Pedro,

In both examples you make the assumption that there is a concrete class
extending from Fragment.
As with many other cases in Wicket it is quite common to use anonymous
inner class: return new Fragment(...) {....}
In this case the name/id would be something like "MyContainer$1" which is
not so nice and more importantly it is not stable! It will change as soon
as another anonymous inner class is added before the Fragment.

My personal preference would be: <wicket:fragment
wicket:name="myCustomFragmentName">

The problem that I see with <wicket:fragment id="..."> is that 'id' has a
special meaning in XML - it has to be unique in the document.
Most of the time <wicket:fragment>s are defined as top-level elements in
MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
something like:

<wicket;panel>

   <div wicket:id="child">
      <wicket: fragment id="test">
        ....
      </wicket: fragment>
   </div>

  <wicket: fragment id="test">
    .....
  </wicket: fragment>
</wicket;panel>


In this case any XML validation tool will complain that there are two
elements with the same id. The IDE as well.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sun, Aug 28, 2016 at 7:28 AM, Pedro Santos <pedros...@gmail.com> wrote:

> Hi devs,
>
> the "wicket:id" tag attribute is commonly used to identify Component's
> instances and its markup, and IMO it should be reserved to this end for
> clarity.
>
> While fragment's markup is identified by the "associatedMarkupId" attribute
> inside the Fragment class, its associated markup is identified by the tag
> attribute "wicket:id" in the "wicket:fragment" tag. This new case of an
> associated markup being identified for a type rather than an instance would
> benefit from a new identifier name. Therefore some proposals.
>
> 1 - Without changing the Fragment class, a natural tag attribute identifier
> would "wicket:markup-id", matching the class attribute name. Since the
> identifier is already inside a markup, even more natural would be:
> "wicket:id" (yeah, I know). Given that we are already inside a tag in
> Wicket's namespace, a simpler identifier would be: "id".
>
> So instead of the current fragment definition:
>
> class MyFragment extends Fragment {
> ...
> super(id, "myFragmentMarkupId", markupContainer);
> ...
> }
> <wicket:fragment wicket:id="myFragmentMarkupId">
>
> We would have:
>
> <wicket:fragment id="myFragment">
>
> 2 - To change Fragment's "associatedMarkupId" attribute to "typeName". Even
> if the user chooses to not specialize the Fragment class by creating a
> subclass of it, conceptually he is still specializing the markup container
> when associating a markup to it. Following the same logic,"wicket:fragment"
> tag's identifier attribute would be: "type-name". So we would have:
>
> class MyFragment extends Fragment {
> ...
> super(id, MyFragment.class.getSimpleName(), markupContainer);
> ...
> }
> <wicket:fragment type-name="MyFragment">
>
> What are your thought?
>
> Cheers
>
> Pedro Santos
>

Reply via email to