As we can't seem to find middle ground, how about removing final from
onComponentTagBody?

Btw, I'm not crazy about any onComponentTag/onComponentTagBody being
final. Any fool understands you should should only overwrite that when
you know what you're doing, and sometimes (now?) there actually can be
good usecases.

Eelco



On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
The LinkText would look like that (an label component added auto, what is
the name of that label component then?)

But this doesn't work (having a seperate class), because now i want the same
thing but i want to use the AjaxFallBackLink? what then?
any kind of link we have now in core or extentions i could use the label
part.

johan


On 10/26/06, Petr Sakar <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I do not follow current development on 2.0, but it seems to me, that
> link with label is only 'specific' case of 'generic' link, so extending
> Link class and introducing LinkText class (or whatever name you choose)
> should make the trick.
>
> Something like:
>
> public class LinkText extends Link {
> final Label label;
> public LinkText(String name) {
> add(label = new Label());
> }
>
> and then you can have your methods to access label ...
>
> Probably you would have to change the check if markup for label exists as
> well, but as it is usually text only, it should not be big deal ...
>
> Or did I miss something ?
>
> saki
>
>
>
> > i am against it because i feel it perverts the api and the nature of
> > component orientation.
> >
> > if you think of it as a desktop link component then yeah text makes
> sense
> > there as a property because you cannot put anything else into a link -
> > because most desktop link components dont let you - but in wicket you
> can.
> >
> > just start a vote because obviously there is no middle ground here.
> >
> > -Igor
> >
> >
> > On 10/26/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >>
> >> yuk!
> >> that doesn't help at all
> >> why ohh why would you trade this:
> >>
> >> new Link(this,"link").add(new Label())
> >> for
> >> new Link(this,"link").add(new BodyModifier())
> >>
> >> thats doesn't solve anything.
> >>
> >> Last thing i just say about this. Why do we constantly get this
> >> question??
> >> Because people see link text as the link text. I had exactly that same
> >> reaction from day 1
> >> I know jan blok also had that. I find it always so ugly that you have
> to
> >> add
> >> a span inside a link and then add a label to the link component
> >> So i am +1 for adding getLabel() (and maybe setLabel()) to Link
> >> i am really -1 for introducing a completely seperate hierachy. Then
> just
> >> do
> >> nothing and let it be like it is now and let users implement there own
> >> when
> >> needed.
> >>
> >> I still don't get it why you guys are so against it it doesn't get in
> >> your
> >> way at all. It is just a very nice and handy thing to have for all the
> >> people that think
> >> like me that the text of a link is the property of that link.
> >> And no you also have a lot of text that is dynamic and not i18n like
> >> Listviews with data where an entry is directly a link. (that is used
> all
> >> over the place in my solutions)
> >>
> >> johan
> >>
> >>
> >>
> >> 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>
> >> >
> >>
> >>
> >
>
>


Reply via email to