Oh, good point. Indeed my first idea is pretty much not possible [1].
I meant the snippet with concrete subclasses only to illustrate the idea
since fragments can be created even without a Fragment subclass. My point
here is that even the Fragment being a concrete class, it still is an
abstract Wicket markup container. A concrete Wicket markup container has an
associated markup. When we associate the a markup to a Fragment, we are
creating a concrete Wicket type, and this type needs a name. Therefore the
importance I see in to keeping the "type" word in the identifier attribute.
Regarding the attribute namespace, I'm +1 to default it to Wicket's
namespece (like the "key" attribute in wicket:message tag usually defaults)
rather than to explicitly write the namespace. e.g.:
Given the .java
...
add(new Fragment("myId", "MyFragment", this);
...
I would prefer the following usage in the .xhtml
...
<wicket:fragment type-name="MyFragment">
...
rather than
...
<wicket:fragment wicket:type-name="MyFragment">
...
1 - https://www.w3.org/TR/REC-xml/#id
Pedro Santos
On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> 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
> >
>
