Thoughts on component ids

[Jesse Long <jp...@unknown.za.net>]

Hi Wicket Developers,

I have a few thoughts regarding component ids.

First, requiring the component to know, at constructor time, the 
wicket:id of the tag it will be added to makes creating components 
difficult and clumsy. What do you think about changing this pattern:

add(new MyComponent("theIdInMarkup"));

to this:

add("theIdInMarkup", new MyComponent());

This allows us to separate the construction of the components from the 
populating of the markup. I can think of one downside, 
Component#replaceWith() will need some re-working.

Second, regarding the request listener urls: Would it be feasible to 
encode the IRequestListener URLs and form component names using the 
output markup ids rather than the component ids? This would require all 
all components to have a output markup id, but would not require all 
components to actually output the output markup id. Reasoning: the 
component ids are often much, much longer than the generated output 
markup id. Also, component ids are like variable names - private and 
internal to the application. I dont want to expose inner working and 
terminology in the form of the component id name hierarchy to my 
customers. I want the freedom to use all sorts of offensive language in 
my component ids :-)

We could change urls like:

?5-1.ILinkListener-body-content-someMenu-menuItems-link-2

to

?5-1.ILinkListener-id1-id4-id6-id23-id30-id89

I assume (without looking at the code) that using the whole path in 
these urls and form component names is to make finding the target 
component more efficient. If it is not used to speed up finding the 
target component, then we could simply set the URL to:

?5-1.ILinkListener-id89

Since the output markup id should always be unique in the page, which 
the component id is only unique in the parent.

What do you think?

Thanks,
Jesse

Re: Thoughts on component ids

[Jesse Long <jp...@unknown.za.net>]

On 03/07/2013 14:07, Martijn Dashorst wrote:
> On Wed, Jul 3, 2013 at 11:35 AM, Jesse Long <jp...@unknown.za.net> wrote:
>> First, requiring the component to know, at constructor time, the wicket:id
>> of the tag it will be added to makes creating components difficult and
>> clumsy.
> What is clumsy about it? What is difficult to creating components currently?


I have a base page. It has a div that usually contains some certain 
information. Sometimes, in response to form submits etc, this div will 
be replaced by something else. I cant do:

this.replaceMySpecialDiv(new MyPanel("Oh damn, what was the component id 
here again?"));

Also, I practice "Only the abc.java may be required to know the 
component ids in abc.html". Having subclasses of the base page need to 
know the component id is untidy.

it would be better:

this.replaceMySpecialDiv(new MyPanel());

protected void replaceMySpecialDiv(Component c)
{
     replace("component id ... I am in BasePage.java, so I am allowed to 
know component ids in BasePage.html", c);
}

You end up with "public static final String SOMETHING_COMPONENT_ID" 
which gets passed into component constructors. The next evolution is to 
create a needless subclass that does little other than always pass the 
same component id to the super class, like:

public class MySpecialDivPanel
     extends Panel
{
     public MySpecialDivPanel(IModel.....)
     {
          super("hardcoded component id", model);
     }
}

Look at wicket-bootstrap. 
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/navbar/NavbarButton.java

super(Navbar.componentId(), ......

Its clumsy.


>
>> What do you think about changing this pattern:
>>
>> add(new MyComponent("theIdInMarkup"));
>>
>> to this:
>>
>> add("theIdInMarkup", new MyComponent());
>>
>> This allows us to separate the construction of the components from the
>> populating of the markup.
> What is the benefit of this? What are the upsides?

Upside is "less clumsy".

>> I can think of one downside,
>> Component#replaceWith() will need some re-working.
> I can think of one other: a minor breakage in a little used part of our API.

:-) very important point. However, I'm not pushing this for 6.9.1. I'm 
happy to wait for 6.9.2 :-)

No harm in discussing it though. I think its about as disruptive as the 
changes proposed in Wicket 2. It need not be black and white, we may be 
able to accommodate both approaches. Either way, if the only down side 
is API breakage, and generally accepted as a good thing, then maybe we 
can implement it one day when something else causes API breakage.

Cheers,
Jesse

Re: Thoughts on component ids

[Martijn Dashorst <ma...@gmail.com>]

On Wed, Jul 3, 2013 at 11:35 AM, Jesse Long <jp...@unknown.za.net> wrote:
> First, requiring the component to know, at constructor time, the wicket:id
> of the tag it will be added to makes creating components difficult and
> clumsy.

What is clumsy about it? What is difficult to creating components currently?

> What do you think about changing this pattern:
>
> add(new MyComponent("theIdInMarkup"));
>
> to this:
>
> add("theIdInMarkup", new MyComponent());
>
> This allows us to separate the construction of the components from the
> populating of the markup.

What is the benefit of this? What are the upsides?

> I can think of one downside,
> Component#replaceWith() will need some re-working.

I can think of one other: a minor breakage in a little used part of our API.

Martijn