The good thing about bodymodifier is that it would be consistent with
attribute modifier. The big problem though is that using a
bodymodifier in a markup container has the same problems as with my
earlier patch. What are you going to do? Putting it in front/ after or
replace and throw an exception when other components are nested?
In this specific case, it would save users from writing the extra
markup tag, so that's good.
Eelco
On 10/26/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
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>
