> sorry ofcourse it is "wouldn't look like that"
>
> 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?)
Both can be easily solved.
1. The name for label can be some constant, you must only make sure it is
accessible (final method getLabelName())
2. You can then add it as one of constructors for Link and
AjaxFallBackLink and any other link you have in mind ...
Probably not what you want, but it can work.
saki
>>
>> 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>
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>
