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>
>> >
>>
>>
>
