The problem is then that you have to do it for ALL the links we have
For example ResourceLink is also a pretty nice one. new
ResourceLink("mypdf", mypdfresource).setLabel("My Pdf"));
Just one simple method (we could do only a getter) is so much simpler and
then i have it for all the different kind of links
And there are a lot of them.
I am not talking about servoy how users use servoy. But how we had to build
it.
And i am already complaining about this from day 1. And pretty much all the
first time users all have the same problem
Because it is just not logical. The text of the link (if dynamic) is a
property of that link. Thats how i (and i guess many others) just see it.
i am -1 for a special link class, then we will keep busy adding more and
more because users also want it for that or this kind.
johan
On 10/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i really want a new class for this in extensions.
you cant compare this to a formcomponent.label - that serves a completely
different purpose and doesnt display it for you anywhere even if set.
is it really that hard to build a new SimpleLink and
SimpleBookmarkablePageLink in your code or in extensions?
-Igor
On 10/25/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> Thats why i dont like a new class, but just a new method on link.
> Just like FormComponent.getLabel() (that is a method i never have yet
> used... and the Link.getLabel() i would use all over the place)
>
>
> On 10/25/06, Frank Bille <[EMAIL PROTECTED]> wrote:
> >
> > +1 on keeping core as clean as possible. Even though conveinience
> > classes is a good thing (most of the time) they tend to clutter the
> > API.
> >
> > I like having them in extensions and I personally don't mind if
> > (having really checked) extensions is larger than core (LOC,
> > #classes).
> >
> > Frank
> >
> > On 10/25/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > whatever you guys end up doing this should most definetely NOT be in
> > > BookmarkablePgeLink! leave that g e n e r i c.
> > >
> > > add a convinience subclass into extensions if its really bugging you
> > that
> > > much.
> > >
> > > as martijn pointed out 99% of usecases there is either a text/a
> > > wicket:message/or a collection of components not a label in there.
> > >
> > > core should be a framework not a bunch of convinience classes.
> > >
> > > yes we have those requiredtextfield, etc. nothing we can do about it
> > now. we
> > > can remove them in 2.0, i would be +1 for that - move them into
> > extensions.
> > >
> > > -Igor
> > >
> > >
> > > On 10/25/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > as i said we could doe
> > > >
> > > > add(new BookmarkablePageLink("Link1", Page1.class
> > ).setLabel("String"));
> > > >
> > > > but that means directly mem usage (and empty reference)
> > > > (or should i reuse meta data for that, we already have that
> reference
> > > > anyway
> > > > :))
> > > >
> > > > johan
> > > >
> > > >
> > > > On 10/25/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > But as you have proposed it, Korbinians example would look like:
> > > > >
> > > > >
> > > > > add(new BookmarkablePageLink("Link1", Page1.class) {
> > > > > protected String getLabel() {
> > > > > return "Blabla";
> > > > > }
> > > > > });
> > > > > add(new BookmarkablePageLink("Link2", Page2.class) {
> > > > > protected String getLabel() {
> > > > > return "Blabladsafa";
> > > > > }
> > > > > });
> > > > > add(new BookmarkablePageLink("Link3", Page3.class) {
> > > > > protected String getLabel() {
> > > > > return "afafafaf";
> > > > > }
> > > > > });
> > > > > add(new BookmarkablePageLink("Link4", Page4.class) {
> > > > > protected String getLabel() {
> > > > > return "awer342";
> > > > > }
> > > > > });
> > > > >
> > > > > Which is in my view cluttered beyond recognition. Again, it is
> > trivial
> > > > > to add to your own application using the technique you prefer:
> > trading
> > > > > session size versus lazy evaluation.
> > > > >
> > > > > I think
> > > > > - this bloats our api with very small benefit
> > > > > - makes working with Wicket unnecessary hard
> > > > > - forces you to subclass
> > > > > - adds magic to link handling
> > > > > - doesn't entice users to create their own custom components
when
> > > > > they need to scratch their itch
> > > > > - it is not necessary as I haven't felt the need for this
feature
> in
> > > > > over 200+ pages created with thousands of links.
> > > > >
> > > > > Thus it receives my -1. However voting is on majority.
> > > > >
> > > > > Martijn
> > > > >
> > > > > On 10/25/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > > > > On 10/25/06, Martijn Dashorst <[EMAIL PROTECTED]>
> wrote:
> > > > > > > I hate that I have to call setRequired on form components,
yet
> I
> > > > don't
> > > > > > > introduce RequirecDropDownChoice, and vote to remove
> > > > RequiredTextField
> > > > > > >
> > > > > > > probably same for: Component.setResponsePage() vs.
> > > > > > > RequestCycle.get().setResponsePage()
> > > > > > >
> > > > > > > It is bloating our api, and doesn't give anything extra you
> > can't
> > > > > > > already achieve by creating your own, custom component that
> does
> > > > > > > exactly as you wish. And Wicket is advocating creating
custom
> > > > > > > components.
> > > > > > >
> > > > > > > BTW How often do you *really* have to add the label to the
> link?
> > > > Only
> > > > > > > once in a menu panel? How often do you just have some text
in
> > the
> > > > > > > markup?
> > > > > > >
> > > > > > > What is the benefit of doing so if you can just add a
> > > > <wicket:message>
> > > > > > > in the markup?
> > > > > > >
> > > > > > > We use links on and around all kinds of stuff, including:
> <tr>,
> > > > <td>,
> > > > > > > <div> <span> <img> etc.
> > > > > > >
> > > > > > > Laziness is a bad motivator for expanding an api as has been
> > said
> > > > time
> > > > > > > and time again on these mailinglists
> > > > > >
> > > > > > Sure. My problem with the whole thing is that is has been
> applied
> > very
> > > > > > selectively. There have been a zillion ajax methods and
> > convenience
> > > > > > classes in the last few months for instance, which weren't
> > extensively
> > > > > > discussed, and thus no-one cried about it.
> > > > > >
> > > > > > Is this a really big thing? To Johan, me and some users it is.
> > Does it
> > > > > > have a big impact on the API? No, not like I proposed it, as
it
> is
> > > > > > something you specifically have to look for.
> > > > > >
> > > > > > 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>
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
