Re: Fragment's markup identifier change proposals for Wicket 8
On Sun, Aug 28, 2016 at 12:19 PM, Pedro Santos 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
could be simplified to .
I hope our XmlPullParser supports this
>
> Given the .java
> ...
> add(new Fragment("myId", "MyFragment", this);
> ...
>
> I would prefer the following usage in the .xhtml
> ...
>
> ...
> rather than
> ...
>
>
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
> ...
>
> 1 - https://www.w3.org/TR/REC-xml/#id
>
> Pedro Santos
>
More opinions ?
>
> On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov
> 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:name="myCustomFragmentName">
> >
> > The problem that I see with is that 'id' has a
> > special meaning in XML - it has to be unique in the document.
> > Most of the time s are defined as top-level elements in
> > MyPanel.html and have unique (wicket:)ids but it is perfectly fine to
> have
> > something like:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> >
> >
> > 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
> 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);
> > > ...
> > > }
> > >
> > >
> > > We would have:
> > >
> > >
> > >
> > > 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);
> > > ...
> > > }
> > >
> > >
> > > What are your thought?
> > >
> > > Cheers
> > >
> > > Pedro Santos
> > >
> >
>
Re: Fragment's markup identifier change proposals for Wicket 8
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
...
...
rather than
...
...
1 - https://www.w3.org/TR/REC-xml/#id
Pedro Santos
On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov
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:name="myCustomFragmentName">
>
> The problem that I see with is that 'id' has a
> special meaning in XML - it has to be unique in the document.
> Most of the time s are defined as top-level elements in
> MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
> something like:
>
>
>
>
>
>
>
>
>
>
> .
>
>
>
>
> 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 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);
> > ...
> > }
> >
> >
> > We would have:
> >
> >
> >
> > 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);
> > ...
> > }
> >
> >
> > What are your thought?
> >
> > Cheers
> >
> > Pedro Santos
> >
>
Re: Fragment's markup identifier change proposals for Wicket 8
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:
The problem that I see with is that 'id' has a
special meaning in XML - it has to be unique in the document.
Most of the time s are defined as top-level elements in
MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
something like:
.
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 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);
> ...
> }
>
>
> We would have:
>
>
>
> 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);
> ...
> }
>
>
> What are your thought?
>
> Cheers
>
> Pedro Santos
>
