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