You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2007/09/08 02:12:38 UTC
Two small questions
Hi,
I am trying to display a date in my own format in Wicket 1.3.0 beta 3,
and the JavaDocs at
http://people.apache.org/~tobrien/wicket/apidocs/index.html list a
DateLabel component, however I cannot find it in my version of wicket.
Is it removed, or is it going to be added to the next version? How can I
make sure my Label formats the date model object the way I want it to
appear?
Second question that I have is the following. I want to display a label
with a link around it (a href), but the link should only be active if
the href is not empty or null. Thus if there is anything in it, the link
should be active, otherwise not. The href is a property of a model
object (which can change on form submit, so choosing between a fragment
with the link and a fragment without the link at construction time would
not work).
Thanks in advance,
Sebastiaan
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Thanks guys for the quick answers! :-)
Regards,
Sebastiaan
Martijn Dashorst wrote:
> On 9/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> Nope, add wicket-datetime.
>
> Hmm, memory needs reboot at 2:30 am.
>
> Martijn
>
Re: Two small questions
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Nope, add wicket-datetime.
Hmm, memory needs reboot at 2:30 am.
Martijn
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
> Best Regards,
>
> Korbinian
>
> PS: does wicket-datetime somehow depend on yoda-time? sorry, for asking
> but I'm bit confused lately with the Date/ Locale/ pattern/ long chaos
> in Java
http://www.mvnrepository.com/artifact/org.apache.wicket/wicket-datetime/1.3.0-beta3
:-)
wicket-datetime depends on wicket, wicket-extensions, and yoda-time.
Regards,
Sebastiaan
> Eelco Hillenius schrieb:
>> On 9/7/07, Martijn Dashorst <ma...@gmail.com> wrote:
>>> On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>>> DateLabel component, however I cannot find it in my version of wicket.
>>> Add wicket-extensions to your project.
>>
>> Nope, add wicket-datetime.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Two small questions
Posted by Eelco Hillenius <ee...@gmail.com>.
> Any ideas what you'd want to aim for here? Separate
> components/converters for date and datetime or a single one that
> supports both?
I think I'd like a single one that supports date, datetime and long
transparently if possible. WDYT?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Eelco Hillenius <ee...@gmail.com>.
>
> Is this related to this task:
> http://issues.apache.org/jira/browse/WICKET-466
It is. Not sure whether that patch is the best solution though, so I
need some time to look into it.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Oliver Henlich <ol...@mangospice.com>.
Eelco Hillenius wrote:
> On 9/8/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
>> So wicket-extensions shouldnt be used for dates now?
>
> You can, and there is another DateTextField in that project. The
> question was where the DateLabel component resides, which is in
> wicket-datetime.
>
>> If so, how can I pursuade the DateTextField from there to use a long
>> (classic unix timestamp) instead of a Date inside a model? (without
>> overiding getModelObject/ setModelOject as its an inner class and I cant
>> have the model beeing final?)
>
> In that case, you should use that particular component. Or provide a
> patch so that it works with both (another outstanding issue is to let
> it work with DateTime objects from yoda time).
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Hi Eelco,
Is this related to this task:
http://issues.apache.org/jira/browse/WICKET-466
Would be great to have DataTime supported. At the moment i keep having
to add methods to our DTOs that return java.util.Date instead of DateTimes.
Cheers
Oliver
Re: Two small questions
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/8/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> Hi Eeclo,
>
> thanks for pointing this out. Ive come to a solution and created a
> MultiPatternDateConverter - it accepts long/Long, Date and DateTime
> (joda). Maybe you can use it for wicket-datetime.
>
> Code is here: http://pastebin.com/m43b5e339
>
> Let me know what you think, its based on the original PatternDateConverter.
Thanks. I probably want to go in a direction like that, but I'd like
to look at revising the converter and components in one go. Hope to
find time soon for that, and I'll keep the longs in the back of my
mind.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi Eeclo,
thanks for pointing this out. Ive come to a solution and created a
MultiPatternDateConverter - it accepts long/Long, Date and DateTime
(joda). Maybe you can use it for wicket-datetime.
Code is here: http://pastebin.com/m43b5e339
Let me know what you think, its based on the original PatternDateConverter.
best,
Korbinian
> On 9/8/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
>> So wicket-extensions shouldnt be used for dates now?
>
> You can, and there is another DateTextField in that project. The
> question was where the DateLabel component resides, which is in
> wicket-datetime.
>
>> If so, how can I pursuade the DateTextField from there to use a long
>> (classic unix timestamp) instead of a Date inside a model? (without
>> overiding getModelObject/ setModelOject as its an inner class and I cant
>> have the model beeing final?)
>
> In that case, you should use that particular component. Or provide a
> patch so that it works with both (another outstanding issue is to let
> it work with DateTime objects from yoda time).
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/8/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> So wicket-extensions shouldnt be used for dates now?
You can, and there is another DateTextField in that project. The
question was where the DateLabel component resides, which is in
wicket-datetime.
> If so, how can I pursuade the DateTextField from there to use a long
> (classic unix timestamp) instead of a Date inside a model? (without
> overiding getModelObject/ setModelOject as its an inner class and I cant
> have the model beeing final?)
In that case, you should use that particular component. Or provide a
patch so that it works with both (another outstanding issue is to let
it work with DateTime objects from yoda time).
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
So wicket-extensions shouldnt be used for dates now?
If so, how can I pursuade the DateTextField from there to use a long
(classic unix timestamp) instead of a Date inside a model? (without
overiding getModelObject/ setModelOject as its an inner class and I cant
have the model beeing final?)
e.g.:
public static class LongDateTextFieldEditor extends Fragment {
public LongDateTextFieldEditor(String id, IModel model,
IModel labelModel, final String pattern) {
super(id, "dateEditor");
add(new Label("label", labelModel));
add(new DateTextField("edit", model, new
PatternDateConverter(pattern, false)).add(new DatePicker()));
}
}
model.getModelObject here just returns 124922732 (long unix timestamp)
Best Regards,
Korbinian
PS: does wicket-datetime somehow depend on yoda-time? sorry, for asking
but I'm bit confused lately with the Date/ Locale/ pattern/ long chaos
in Java
Eelco Hillenius schrieb:
> On 9/7/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>> DateLabel component, however I cannot find it in my version of wicket.
>> Add wicket-extensions to your project.
>
> Nope, add wicket-datetime.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/7/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > DateLabel component, however I cannot find it in my version of wicket.
>
> Add wicket-extensions to your project.
Nope, add wicket-datetime.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Gerolf Seitz <ge...@gmail.com>.
On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>
> Hi,
>
> Gerolf Seitz wrote:
> > sebastiaan,
> >
> > sorry for not saying that in my first post: thank you for your
> contribution.
> > could you also attach this file to the issue WICKET-949?
>
> No problem, you guys are welcome. :-)
> I will attach it to issue.
>
> > as you said, you'd probably subclass the behavior anyway to provide an
> > application wide implementation.
>
> Yes, and the more I think about it, the more I like it the way you
> suggested...
>
> > it's just that it seems to be the wicketier way with overriding the
> methods.
>
> Yes, and it makes the component have that nice wicketty "lightweight"
> feel... :-))
cool, alright then ;)
gerolf
Regards,
> Sebastiaan
>
> > anyway, again thanks...
> >
> > gerolf
> >
> > On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >> Hi,
> >>
> >> Thanks for you constructive comments. Silly of me to not see the
> >> AbstractBehavior class, though I'm new to Wicket so I'm not too
> familiar
> >> with the API yet. :-) Thanks for the tip.
> >>
> >> As for returning the string constants in the
> >> get(Before|After)DisabledLink, I'm wondering if memory is that big an
> >> issue? AbstractLink also has these member fields. Futhermore, a one
> liner:
> >>
> >> externalLink.add(new DisableLinkBehavior("<b>", "</b>"));
> >>
> >> suddenly becomes much more verbose:
> >>
> >> externalLink.add(new DisableLinkBehavior() {
> >> @Override
> >> public String getBeforeLinkDisabled() {
> >> return "<b>";
> >> }
> >> @Override
> >> public String getAfterLinkDisabled() {
> >> return "</b>";
> >> }
> >> }
> >>
> >> And it only saves 4 bytes of memory in the latter case because it
> >> contains a hidden (unnecessary) reference to the outer class due to the
> >> fact it isn't a static inner class.
> >>
> >> Of course the obvious solution is to just create a subclass of
> >> DisableLinkBehavior with the (before|afterLinkDisable) fields and call
> >> it something like CustomLinkDisableBehavior or some such (especially
> >> since you would probably would use such a customization over an entire
> >> site). I'm still split on the issue though. :-)
> >>
> >> Anyway, I decided for now to take your approach.
> >>
> >> Here's the new class.
> >>
> >> Regards, and thanks again for the comments!
> >> Sebastiaan
> >>
> >> Gerolf Seitz wrote:
> >>> hi sebastiaan,
> >>>
> >>> what you could do instead of having the beforeDisabledLink and
> >>> afterDisabledLink properties as members of the class,
> >>> let the methods get(Before|After)DisabledLink return "<li>" and
> "</li>".
> >>> in case the user wants to provide different before/after tags, they
> just
> >>> override the methods and let them return something else.
> >>> to quote eelco (see WICKET-661): "It's a bit cheaper on memory like
> >> that."
> >>> you might also want to extend AbstractBehavior instead of implementing
> >>> IBehavior from scratch. saves a few "// do nothing" methods.
> >>>
> >>> any objections to that?
> >>>
> >>> cheers,
> >>> gerolf
> >>>
> >>> On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >>>> Hi,
> >>>>
> >>>> I decided to wrote a behavior to do what I want. Just in case anybody
> >> is
> >>>> interested, I will attach it to this email. You can use it like so:
> >>>>
> >>>> ExternalLink externalLink = new ExternalLink("externalLink",
> >>>> "http://www.google.com");
> >>>> externalLink.add(new DisableLinkBehavior());
> >>>> externalLink.setEnabled(enabled);
> >>>> add(externalLink);
> >>>>
> >>>> The output is exactly the same as with Link. You can also specify
> >>>> "beforeDisabledLink" and "afterDisabledLink" strings in the
> constructor
> >>>> of DisableLinkBehavior if you don't like the default <i> </i>.
> >>>>
> >>>> Regards,
> >>>> Sebastiaan
> >>>>
> >>>>
> >>>>
> >>>> Sebastiaan van Erk wrote:
> >>>>> Hi,
> >>>>>
> >>>>> It indeed looks more like an omission than a bug. I'll make a
> feature
> >>>>> request out of it. :-)
> >>>>>
> >>>>> Regards,
> >>>>> Sebastiaan
> >>>>>
> >>>>> Jonathan Locke wrote:
> >>>>>> yeah, more like an omission, but this is definitely a problem so
> far
> >> as
> >>>> i
> >>>>>> recall.
> >>>>>>
> >>>>>>
> >>>>>> Kent Tong wrote:
> >>>>>>> Sebastiaan van Erk wrote:
> >>>>>>>> Ok, to answer my own question, it seems that ExternalLink does
> not
> >>>>>>>> have the ability to be disabled like Link.
> >>>>>>>>
> >>>>>>> Looks like a bug to me. I'd suggest that you submit a JIRA issue
> at
> >>>>>>> http://issues.apache.org/jira/browse/WICKET
> >>>>>>>
> >>
> >
>
>
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
Gerolf Seitz wrote:
> sebastiaan,
>
> sorry for not saying that in my first post: thank you for your contribution.
> could you also attach this file to the issue WICKET-949?
No problem, you guys are welcome. :-)
I will attach it to issue.
> as you said, you'd probably subclass the behavior anyway to provide an
> application wide implementation.
Yes, and the more I think about it, the more I like it the way you
suggested...
> it's just that it seems to be the wicketier way with overriding the methods.
Yes, and it makes the component have that nice wicketty "lightweight"
feel... :-))
Regards,
Sebastiaan
> anyway, again thanks...
>
> gerolf
>
> On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>> Hi,
>>
>> Thanks for you constructive comments. Silly of me to not see the
>> AbstractBehavior class, though I'm new to Wicket so I'm not too familiar
>> with the API yet. :-) Thanks for the tip.
>>
>> As for returning the string constants in the
>> get(Before|After)DisabledLink, I'm wondering if memory is that big an
>> issue? AbstractLink also has these member fields. Futhermore, a one liner:
>>
>> externalLink.add(new DisableLinkBehavior("<b>", "</b>"));
>>
>> suddenly becomes much more verbose:
>>
>> externalLink.add(new DisableLinkBehavior() {
>> @Override
>> public String getBeforeLinkDisabled() {
>> return "<b>";
>> }
>> @Override
>> public String getAfterLinkDisabled() {
>> return "</b>";
>> }
>> }
>>
>> And it only saves 4 bytes of memory in the latter case because it
>> contains a hidden (unnecessary) reference to the outer class due to the
>> fact it isn't a static inner class.
>>
>> Of course the obvious solution is to just create a subclass of
>> DisableLinkBehavior with the (before|afterLinkDisable) fields and call
>> it something like CustomLinkDisableBehavior or some such (especially
>> since you would probably would use such a customization over an entire
>> site). I'm still split on the issue though. :-)
>>
>> Anyway, I decided for now to take your approach.
>>
>> Here's the new class.
>>
>> Regards, and thanks again for the comments!
>> Sebastiaan
>>
>> Gerolf Seitz wrote:
>>> hi sebastiaan,
>>>
>>> what you could do instead of having the beforeDisabledLink and
>>> afterDisabledLink properties as members of the class,
>>> let the methods get(Before|After)DisabledLink return "<li>" and "</li>".
>>> in case the user wants to provide different before/after tags, they just
>>> override the methods and let them return something else.
>>> to quote eelco (see WICKET-661): "It's a bit cheaper on memory like
>> that."
>>> you might also want to extend AbstractBehavior instead of implementing
>>> IBehavior from scratch. saves a few "// do nothing" methods.
>>>
>>> any objections to that?
>>>
>>> cheers,
>>> gerolf
>>>
>>> On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>>> Hi,
>>>>
>>>> I decided to wrote a behavior to do what I want. Just in case anybody
>> is
>>>> interested, I will attach it to this email. You can use it like so:
>>>>
>>>> ExternalLink externalLink = new ExternalLink("externalLink",
>>>> "http://www.google.com");
>>>> externalLink.add(new DisableLinkBehavior());
>>>> externalLink.setEnabled(enabled);
>>>> add(externalLink);
>>>>
>>>> The output is exactly the same as with Link. You can also specify
>>>> "beforeDisabledLink" and "afterDisabledLink" strings in the constructor
>>>> of DisableLinkBehavior if you don't like the default <i> </i>.
>>>>
>>>> Regards,
>>>> Sebastiaan
>>>>
>>>>
>>>>
>>>> Sebastiaan van Erk wrote:
>>>>> Hi,
>>>>>
>>>>> It indeed looks more like an omission than a bug. I'll make a feature
>>>>> request out of it. :-)
>>>>>
>>>>> Regards,
>>>>> Sebastiaan
>>>>>
>>>>> Jonathan Locke wrote:
>>>>>> yeah, more like an omission, but this is definitely a problem so far
>> as
>>>> i
>>>>>> recall.
>>>>>>
>>>>>>
>>>>>> Kent Tong wrote:
>>>>>>> Sebastiaan van Erk wrote:
>>>>>>>> Ok, to answer my own question, it seems that ExternalLink does not
>>>>>>>> have the ability to be disabled like Link.
>>>>>>>>
>>>>>>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
>>>>>>> http://issues.apache.org/jira/browse/WICKET
>>>>>>>
>>
>
Re: Two small questions
Posted by Gerolf Seitz <ge...@gmail.com>.
sebastiaan,
sorry for not saying that in my first post: thank you for your contribution.
could you also attach this file to the issue WICKET-949?
as you said, you'd probably subclass the behavior anyway to provide an
application wide implementation.
it's just that it seems to be the wicketier way with overriding the methods.
anyway, again thanks...
gerolf
On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>
> Hi,
>
> Thanks for you constructive comments. Silly of me to not see the
> AbstractBehavior class, though I'm new to Wicket so I'm not too familiar
> with the API yet. :-) Thanks for the tip.
>
> As for returning the string constants in the
> get(Before|After)DisabledLink, I'm wondering if memory is that big an
> issue? AbstractLink also has these member fields. Futhermore, a one liner:
>
> externalLink.add(new DisableLinkBehavior("<b>", "</b>"));
>
> suddenly becomes much more verbose:
>
> externalLink.add(new DisableLinkBehavior() {
> @Override
> public String getBeforeLinkDisabled() {
> return "<b>";
> }
> @Override
> public String getAfterLinkDisabled() {
> return "</b>";
> }
> }
>
> And it only saves 4 bytes of memory in the latter case because it
> contains a hidden (unnecessary) reference to the outer class due to the
> fact it isn't a static inner class.
>
> Of course the obvious solution is to just create a subclass of
> DisableLinkBehavior with the (before|afterLinkDisable) fields and call
> it something like CustomLinkDisableBehavior or some such (especially
> since you would probably would use such a customization over an entire
> site). I'm still split on the issue though. :-)
>
> Anyway, I decided for now to take your approach.
>
> Here's the new class.
>
> Regards, and thanks again for the comments!
> Sebastiaan
>
> Gerolf Seitz wrote:
> > hi sebastiaan,
> >
> > what you could do instead of having the beforeDisabledLink and
> > afterDisabledLink properties as members of the class,
> > let the methods get(Before|After)DisabledLink return "<li>" and "</li>".
> > in case the user wants to provide different before/after tags, they just
> > override the methods and let them return something else.
> > to quote eelco (see WICKET-661): "It's a bit cheaper on memory like
> that."
> >
> > you might also want to extend AbstractBehavior instead of implementing
> > IBehavior from scratch. saves a few "// do nothing" methods.
> >
> > any objections to that?
> >
> > cheers,
> > gerolf
> >
> > On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >> Hi,
> >>
> >> I decided to wrote a behavior to do what I want. Just in case anybody
> is
> >> interested, I will attach it to this email. You can use it like so:
> >>
> >> ExternalLink externalLink = new ExternalLink("externalLink",
> >> "http://www.google.com");
> >> externalLink.add(new DisableLinkBehavior());
> >> externalLink.setEnabled(enabled);
> >> add(externalLink);
> >>
> >> The output is exactly the same as with Link. You can also specify
> >> "beforeDisabledLink" and "afterDisabledLink" strings in the constructor
> >> of DisableLinkBehavior if you don't like the default <i> </i>.
> >>
> >> Regards,
> >> Sebastiaan
> >>
> >>
> >>
> >> Sebastiaan van Erk wrote:
> >>> Hi,
> >>>
> >>> It indeed looks more like an omission than a bug. I'll make a feature
> >>> request out of it. :-)
> >>>
> >>> Regards,
> >>> Sebastiaan
> >>>
> >>> Jonathan Locke wrote:
> >>>> yeah, more like an omission, but this is definitely a problem so far
> as
> >> i
> >>>> recall.
> >>>>
> >>>>
> >>>> Kent Tong wrote:
> >>>>>
> >>>>> Sebastiaan van Erk wrote:
> >>>>>> Ok, to answer my own question, it seems that ExternalLink does not
> >>>>>> have the ability to be disabled like Link.
> >>>>>>
> >>>>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
> >>>>> http://issues.apache.org/jira/browse/WICKET
> >>>>>
> >>
> >
>
>
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
Thanks for you constructive comments. Silly of me to not see the
AbstractBehavior class, though I'm new to Wicket so I'm not too familiar
with the API yet. :-) Thanks for the tip.
As for returning the string constants in the
get(Before|After)DisabledLink, I'm wondering if memory is that big an
issue? AbstractLink also has these member fields. Futhermore, a one liner:
externalLink.add(new DisableLinkBehavior("<b>", "</b>"));
suddenly becomes much more verbose:
externalLink.add(new DisableLinkBehavior() {
@Override
public String getBeforeLinkDisabled() {
return "<b>";
}
@Override
public String getAfterLinkDisabled() {
return "</b>";
}
}
And it only saves 4 bytes of memory in the latter case because it
contains a hidden (unnecessary) reference to the outer class due to the
fact it isn't a static inner class.
Of course the obvious solution is to just create a subclass of
DisableLinkBehavior with the (before|afterLinkDisable) fields and call
it something like CustomLinkDisableBehavior or some such (especially
since you would probably would use such a customization over an entire
site). I'm still split on the issue though. :-)
Anyway, I decided for now to take your approach.
Here's the new class.
Regards, and thanks again for the comments!
Sebastiaan
Gerolf Seitz wrote:
> hi sebastiaan,
>
> what you could do instead of having the beforeDisabledLink and
> afterDisabledLink properties as members of the class,
> let the methods get(Before|After)DisabledLink return "<li>" and "</li>".
> in case the user wants to provide different before/after tags, they just
> override the methods and let them return something else.
> to quote eelco (see WICKET-661): "It's a bit cheaper on memory like that."
>
> you might also want to extend AbstractBehavior instead of implementing
> IBehavior from scratch. saves a few "// do nothing" methods.
>
> any objections to that?
>
> cheers,
> gerolf
>
> On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>> Hi,
>>
>> I decided to wrote a behavior to do what I want. Just in case anybody is
>> interested, I will attach it to this email. You can use it like so:
>>
>> ExternalLink externalLink = new ExternalLink("externalLink",
>> "http://www.google.com");
>> externalLink.add(new DisableLinkBehavior());
>> externalLink.setEnabled(enabled);
>> add(externalLink);
>>
>> The output is exactly the same as with Link. You can also specify
>> "beforeDisabledLink" and "afterDisabledLink" strings in the constructor
>> of DisableLinkBehavior if you don't like the default <i> </i>.
>>
>> Regards,
>> Sebastiaan
>>
>>
>>
>> Sebastiaan van Erk wrote:
>>> Hi,
>>>
>>> It indeed looks more like an omission than a bug. I'll make a feature
>>> request out of it. :-)
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>> Jonathan Locke wrote:
>>>> yeah, more like an omission, but this is definitely a problem so far as
>> i
>>>> recall.
>>>>
>>>>
>>>> Kent Tong wrote:
>>>>>
>>>>> Sebastiaan van Erk wrote:
>>>>>> Ok, to answer my own question, it seems that ExternalLink does not
>>>>>> have the ability to be disabled like Link.
>>>>>>
>>>>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
>>>>> http://issues.apache.org/jira/browse/WICKET
>>>>>
>>
>
Re: Two small questions
Posted by Gerolf Seitz <ge...@gmail.com>.
hi sebastiaan,
what you could do instead of having the beforeDisabledLink and
afterDisabledLink properties as members of the class,
let the methods get(Before|After)DisabledLink return "<li>" and "</li>".
in case the user wants to provide different before/after tags, they just
override the methods and let them return something else.
to quote eelco (see WICKET-661): "It's a bit cheaper on memory like that."
you might also want to extend AbstractBehavior instead of implementing
IBehavior from scratch. saves a few "// do nothing" methods.
any objections to that?
cheers,
gerolf
On 9/13/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>
> Hi,
>
> I decided to wrote a behavior to do what I want. Just in case anybody is
> interested, I will attach it to this email. You can use it like so:
>
> ExternalLink externalLink = new ExternalLink("externalLink",
> "http://www.google.com");
> externalLink.add(new DisableLinkBehavior());
> externalLink.setEnabled(enabled);
> add(externalLink);
>
> The output is exactly the same as with Link. You can also specify
> "beforeDisabledLink" and "afterDisabledLink" strings in the constructor
> of DisableLinkBehavior if you don't like the default <i> </i>.
>
> Regards,
> Sebastiaan
>
>
>
> Sebastiaan van Erk wrote:
> > Hi,
> >
> > It indeed looks more like an omission than a bug. I'll make a feature
> > request out of it. :-)
> >
> > Regards,
> > Sebastiaan
> >
> > Jonathan Locke wrote:
> >>
> >> yeah, more like an omission, but this is definitely a problem so far as
> i
> >> recall.
> >>
> >>
> >> Kent Tong wrote:
> >>>
> >>>
> >>> Sebastiaan van Erk wrote:
> >>>> Ok, to answer my own question, it seems that ExternalLink does not
> >>>> have the ability to be disabled like Link.
> >>>>
> >>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
> >>> http://issues.apache.org/jira/browse/WICKET
> >>>
> >>
>
>
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
I decided to wrote a behavior to do what I want. Just in case anybody is
interested, I will attach it to this email. You can use it like so:
ExternalLink externalLink = new ExternalLink("externalLink",
"http://www.google.com");
externalLink.add(new DisableLinkBehavior());
externalLink.setEnabled(enabled);
add(externalLink);
The output is exactly the same as with Link. You can also specify
"beforeDisabledLink" and "afterDisabledLink" strings in the constructor
of DisableLinkBehavior if you don't like the default <i> </i>.
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
> Hi,
>
> It indeed looks more like an omission than a bug. I'll make a feature
> request out of it. :-)
>
> Regards,
> Sebastiaan
>
> Jonathan Locke wrote:
>>
>> yeah, more like an omission, but this is definitely a problem so far as i
>> recall.
>>
>>
>> Kent Tong wrote:
>>>
>>>
>>> Sebastiaan van Erk wrote:
>>>> Ok, to answer my own question, it seems that ExternalLink does not
>>>> have the ability to be disabled like Link.
>>>>
>>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
>>> http://issues.apache.org/jira/browse/WICKET
>>>
>>
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
It indeed looks more like an omission than a bug. I'll make a feature
request out of it. :-)
Regards,
Sebastiaan
Jonathan Locke wrote:
>
> yeah, more like an omission, but this is definitely a problem so far as i
> recall.
>
>
> Kent Tong wrote:
>>
>>
>> Sebastiaan van Erk wrote:
>>> Ok, to answer my own question, it seems that ExternalLink does not have
>>> the ability to be disabled like Link.
>>>
>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
>> http://issues.apache.org/jira/browse/WICKET
>>
>
Re: Two small questions
Posted by Jonathan Locke <jo...@gmail.com>.
yeah, more like an omission, but this is definitely a problem so far as i
recall.
Kent Tong wrote:
>
>
>
> Sebastiaan van Erk wrote:
>>
>> Ok, to answer my own question, it seems that ExternalLink does not have
>> the ability to be disabled like Link.
>>
>
> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
> http://issues.apache.org/jira/browse/WICKET
>
--
View this message in context: http://www.nabble.com/Two-small-questions-tf4404428.html#a12576156
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Kent Tong <ke...@cpttm.org.mo>.
Sebastiaan van Erk wrote:
>
> Ok, to answer my own question, it seems that ExternalLink does not have
> the ability to be disabled like Link.
>
Looks like a bug to me. I'd suggest that you submit a JIRA issue at
http://issues.apache.org/jira/browse/WICKET
--
View this message in context: http://www.nabble.com/Two-small-questions-tf4404428.html#a12570244
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
Ok, to answer my own question, it seems that ExternalLink does not have
the ability to be disabled like Link.
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
> I have the following code:
>
> final ExternalLink link = new ExternalLink("link",
> model.bind("website")) {
> @Override
> public boolean isEnabled() {
> return Strings.isEmpty((String) getModelObject());
> }
> };
> // some more code to add the body of the link
> // like link.add(new Label(...))
>
> add(link);
>
> However, the link gets rendered enabled no matter what. I put a
> breakpoint on the line with the "return" in the "isEnabled" method, but
> it never gets hit... The breakpoint where I do add(link) does get hit
> though.
>
> Anybody know what I'm doing wrong?
>
> Regards,
> Sebastiaan
>
>
> Martijn Dashorst wrote:
>> On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>> DateLabel component, however I cannot find it in my version of wicket.
>>
>> Add wicket-extensions to your project.
>>
>>> Second question that I have is the following. I want to display a label
>>> with a link around it (a href), but the link should only be active if
>>> the href is not empty or null. Thus if there is anything in it, the link
>>> should be active, otherwise not. The href is a property of a model
>>> object (which can change on form submit, so choosing between a fragment
>>> with the link and a fragment without the link at construction time would
>>> not work).
>>
>> new Link("foo", model) {
>> @override boolean isenabled() { Foo foo = getModelObject(); return
>> foo.getUrl() != null; }
>> }
>>
>> Should do the trick?
>>
>> Martijn
>>
Re: Two small questions
Posted by Sebastiaan van Erk <se...@sebster.com>.
I have the following code:
final ExternalLink link = new ExternalLink("link",
model.bind("website")) {
@Override
public boolean isEnabled() {
return Strings.isEmpty((String) getModelObject());
}
};
// some more code to add the body of the link
// like link.add(new Label(...))
add(link);
However, the link gets rendered enabled no matter what. I put a
breakpoint on the line with the "return" in the "isEnabled" method, but
it never gets hit... The breakpoint where I do add(link) does get hit
though.
Anybody know what I'm doing wrong?
Regards,
Sebastiaan
Martijn Dashorst wrote:
> On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>> DateLabel component, however I cannot find it in my version of wicket.
>
> Add wicket-extensions to your project.
>
>> Second question that I have is the following. I want to display a label
>> with a link around it (a href), but the link should only be active if
>> the href is not empty or null. Thus if there is anything in it, the link
>> should be active, otherwise not. The href is a property of a model
>> object (which can change on form submit, so choosing between a fragment
>> with the link and a fragment without the link at construction time would
>> not work).
>
> new Link("foo", model) {
> @override boolean isenabled() { Foo foo = getModelObject(); return
> foo.getUrl() != null; }
> }
>
> Should do the trick?
>
> Martijn
>
Re: Two small questions
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/8/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> DateLabel component, however I cannot find it in my version of wicket.
Add wicket-extensions to your project.
> Second question that I have is the following. I want to display a label
> with a link around it (a href), but the link should only be active if
> the href is not empty or null. Thus if there is anything in it, the link
> should be active, otherwise not. The href is a property of a model
> object (which can change on form submit, so choosing between a fragment
> with the link and a fragment without the link at construction time would
> not work).
new Link("foo", model) {
@override boolean isenabled() { Foo foo = getModelObject(); return
foo.getUrl() != null; }
}
Should do the trick?
Martijn
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org