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