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