I was already thinking along the line Igor mentioned:

I'm thinking of a BodyModifier. A BodyModifier is added to a
component, and alters the body in a similar fashion as an attribute
modifier:

<a href="#" wicket:id="link">dummy</a>

new Link(this, "link").add(new IBodyModifier() {
   public CharSequence onComponentBody(CharSequence body) {
       return "<em> + body + "</em>";
   }
});

or

new Link(this, "link").add(new IBodyModifier() {
   public CharSequence onComponentBody(CharSequence body) {
       return "My new contents";
   }
});

That would be more scalable in terms of api then slapping getLabel()
at random to components where the getLabel() has different semantics
depending on the component.

However I think this one will be misused by beginners of the framework
to things they could do in a more component oriented way.

Martijn

On 10/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> This is so crap


those are my thoughts exactly on adding that property :)


People don't see links as containers.. they could be but for 99% of the
> cases they are not used like this


well, they are in html and i use them as containers often. i have plenty of
links that have an icon and text, etc. im sure im not the only one out
there.

furthermore you just wont convince me that even if the link is just a label
setting the text for it pragmatically is a widespread enough usecase to
warrant this. the text is either in markup or in wicket:message tag most of
the time.


> Yes we let them do that because we say that you have to make a label for
> that.
> But again it is completely component oriented what i say... I see the
> label
> as a property of the link!!

How much more component oriented can that be????? It is and will always be
> in my eyes the display value of a link.


only if the link is not a container

what you are trying to make link be here is sometimes a container and
sometimes not - its totally wrong and confusing. why not push this feature
down into the webmarkupcontainer then? you can even get rid of Label then!


> I dislike a complete separate stack of links for that just label. That
> just
> sucks big time.


yes, it is not elegant - but is a lesser of evils.

And adding an extra label for every link is maybe cheap but not that cheap
> as you want it to be
> i have seen sessions dumps of pages with 700KB now and if you see what
> components take the most then it is almost
> always labels. Because those are used all over the place.


and because if you are not careful - they hold the actual text string.

Maybe i just should change this:
>
> public abstract class AbstractLink<T> extends WebMarkupContainer<T>
>
> into this:
>
> public abstract class AbstractLink<T> extends WebComponent<T>


if you make this change then feel free to add the getLabel() property :)

another idea might be to add oncomponenttagbody to ibehavior and let you add
a labelbehavior to the link. dont know how much cheaper that is then the
label.

at the end if we dont see eye to eye on this then lets put it to the vote.

-Igor



:)
>
> johan
>
>
> On 10/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > On 10/25/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > we have a link component - it serves as a container for other
> > > components.
> > > > if you want to display something inside that component you have to
> add
> > > > another component to do that - eg a label.
> > >
> > > Sometimes little things make a big difference. I only have to get back
> > > to SimpleAttributeModifier vs AttributeModifier to 'prove' that, as
> > > that only saved what, the creation of a model.
> >
> >
> > and i will take the fall for that one. in retrospect i shouldve put it
> in
> > extensions. maybe i should fix that mistake in 2.0?
> >
> > but SimpleAM is a bit different story.
> >
> > another thing that bugged me about AttributeModifier was that boolean in
> > the
> > constructor which i could never remember which way it worked - in 2.0 we
> > can
> > make it an enum. so SimpleAM was a bit more then just convinience - it
> > really was a simpler version of the full attributemodifier. it also
> lacks
> > a
> > lot of the methods that the full version has.
> >
> > its like dataview - you can argue that is a convinience because you can
> do
> > the same with a listview - but its just not the case.
> >
> > > i am for adding convinience subclasses for this. yes not as pretty but
> > it
> > > is
> > > > how component oriented frameworks work.
> > >
> > > Yeah, that's probably the best option then.
> >
> >
> > this would be my vote.
> >
> > -Igor
> >
> >
> > Eelco
> > >
> >
> >
>
>




--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/";>Best Stuff in
the World!</a>

Reply via email to