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