Re: Fragment's markup identifier change proposals for Wicket 8

[Martin Grigorov <mg...@apache.org>]

On Sun, Aug 28, 2016 at 12:19 PM, Pedro Santos <pe...@gmail.com> wrote:

> 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.:
>

I wasn't aware of this.
If it is true then the same is valid for <wicket:container wicket:id="">
could be simplified to <wicket:container id="...">.
I hope our XmlPullParser supports this


>
> 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">
>

If 'id' is auto-namespaced and has different meaning than XML's id
attribute (i.e. there is no requirement for uniqueness in the whole
document) then I'm fine with <wicket:fragment id="...">


> ...
>
> 1 - https://www.w3.org/TR/REC-xml/#id
>
> Pedro Santos
>


More opinions ?



>
> On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov <mg...@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 <pe...@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
> > >
> >
>