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