The OnLoadJavascriptBehavior below example works perfectly in wicket-1.2
branch. Is there a similar implementation for this in wicket-1.3?
Thank you!
igor.vaynberg wrote:
>
> i agree its not seamless and can be improved on, perhaps you should open
> an
> rfe to have ajaxrequesttarget properly
John, sorry for not being helpful. But I think that this kind of posts (this
is my code, why it doesn't work?) will not help you to find the problem. My
suggestion is, try to debug your code, and if you have a more specific
question, post it and somebody for sure will give you an answer. Otherwise
That is exactly what the JIRA issue states (substitute all special selector
characters). The implementation is up to the assignee of the task. Also, I
do not think that any non wicket-core-developer should participate on the
vote. Anyway, you know my choice :)...
Ryan Holmes wrote:
>
>
>> [ x]
In this case here is my vote:
[X] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
igor.vaynberg wrote:
>
> anyone can participat
> .. my main opposition to this was based on the fact that it was filed as
> a bug.
>
I also initially considered this issue as a feature request, this is the
reason why the topic is called "[RFE] getMarkupId()"... my mistake was to
file this as a bug and not enhancement..
> If you're goin
; On 9/28/07, Alex Objelean <[EMAIL PROTECTED]> wrote:
>> But as you see, the main drawback of this example is that I cannot access
>> the DOM element mapped to wicket component, because the
>> $("#quantity.unit123") has a different meaning than
>> docume
I like this idea.. :)
In wicket 1.2.x branch, when markup id mirrored the component hierarchy, the
generated DOM was huge due to long id names
(page_body_panel_tab_form_component_quantity_unit)... I was very happy to
see a change in 1.3.x branch. Minimizing it even more, seems to be a great
idea.
ust implement IRequestTargetUrlCodingStrategy & IRequestTarget
interfaces. Then, mount your implementation in wicket Application class,
like this:
[code]
protected void init() {
mount(new MyRequestTargetUrlCodingStrategy("api"));
//..
}
[code]
Hope it helps.
Alex Objelean
Bruno Borges wrote:
>
t;
class.
I would keep this as it is, in order to support integration with largely
used js libraries.
Alex Objelean.
Martijn Dashorst wrote:
>
> The "." (dot) is an accepted, and widely used part of component
> identifiers: CompoundPropertyModel makes heavy use of this fe
. it would be nice if the fix would be
>> included in 1.4-rc5. It is a 10 minutes job, and still it is quite
>> important. Thank you!
>>
>> Alex Objelean
>>
>
>
--
View this message in context:
http://www.nabble.com/WICKET-2244-status-tp23634634p23639337.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
rst way is much less likely to create a bug.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Wed, May 20, 2009 at 11:50 AM, Alex Objelean
> wrote:
>>
>> I need to support some legacy resource keys... also, for some situations
>>
I would be happy to see a new release, because it contains a very important
fix:
http://issues.apache.org/jira/browse/WICKET-1912 StatelessForm problems with
query string . This issue prevents me to make the page stateless and this is
quite critical.
Thank you!
Alex Objelean
Jeremy
Could it be fixed in wicket-1.4-rc5 release?
Thanks!
Alex Objelean
Jeremy Thomerson-5 wrote:
>
> Sounds feasible to me. Definitely add a JIRA so that it gets tracked.
> A patch will get it committed even sooner.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
JIRA issue created: https://issues.apache.org/jira/browse/WICKET-2307
https://issues.apache.org/jira/browse/WICKET-2307
Thank you!
Alex Objelean
Jeremy Thomerson-5 wrote:
>
> Sounds feasible to me. Definitely add a JIRA so that it gets tracked.
> A patch will get it committed ev
Hi Igor,
I can't see how this fix would break anything as long as
DecodeRuntimeException is still a WicketRuntimeException.
Your suggestion, to override the WebRequestCodingStrategy isn't an option,
just because WebRequestCodingStrategy#decode(Request) method is final.
Thank you!
Ale
You're right, forgot about this option :) So, if it will not be included
in rc5, I will use a decorator as a workaround. Still, I hope it will be
included :)
Thanks!
Alex Objelean
igor.vaynberg wrote:
>
>> Your suggestion, to override the WebRequestCodingStrategy isn&
Patch attached..
Alex Objelean
Jeremy Thomerson-5 wrote:
>
> Provide a patch and it is much more likely to be included.
>
> Igor, do you see a problem with including it in rc5 now that you saw
> the additional information?
>
> --
> Jeremy Thomerson
> ht
Hi,
when the new build will be available on public maven repo? I would start use
it straight away & report problems if there are any.
Thanks!
Alex Objelean
Jeremy Thomerson-5 wrote:
>
> Devs,
> I built the rc5 release tonight, but as previously mentioned, had
> one problem
Unfortunatelly I cannot migrate to unreleased version... Btw, why some
versions (like rc2, rc4) can be found at maven repo and others (like rc3,
rc5) can't?
Thanks!
Alex
igor.vaynberg wrote:
>
> mvn clean install worked
> examples worked
>
> -igor
>
> On Sun, Jun 7, 2009 at 8:34 PM, Jeremy
>
> On Tue, Jun 9, 2009 at 9:57 AM, Alex Objelean
> wrote:
>>
>> Unfortunatelly I cannot migrate to unreleased version... Btw, why some
>> versions (like rc2, rc4) can be found at maven repo and others (like rc3,
>> rc5) can't?
>>
>> Thanks!
>> A
I've installed the latest version from svn (SNAPSHOT). Beside the build
problem with SignIn2Test ... there seems to be everything ok. I've deployed
my application with this snapshot and everything seems to be ok.
Alex
Jeremy Thomerson-5 wrote:
>
> Devs,
> I built the rc5 release tonight, but
Add a Jira Issue with patch attached...
Max Bowsher-5 wrote:
>
> Max Bowsher wrote:
>> Today I noticed I could in fact have a single implementation of
>> IChoiceRenderer which would work for most of my different persistent
>> classes, which all implement INamedPersistentObject exposing primary
Could you, please, include WICKET-2846 into 1.4.8? I would need it ASAP.
Thanks!
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Re-vote-release-wicket-1-4-8-tp2065468p2065689.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
I still don't see why using InheritableThreadLocal would introduce memory
leaks when dealing with threads. Do you have a good example to prove it? I
don't see any difference...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/WICKET-2846-Store-Application-in-Inheritabl
Since you've never needed the Application instance in threads you had
created, why would you need it from now on? The only problem related to
memory leaks may be caused by your custom implementation, not with the fact
of using InheritableThreadLocal.
--
View this message in context:
http://apach
Please, correct me if I'm wrong, but the Application won't become the root of
child threads. Using InheritableThreadLocal will only make Application
available from the threads created during a request cycle. There is
absolutely no memory related problem with it.
Alex
--
View this message in cont
Reading the entire thread regarding WICKET-2846, shows that only one person
is against this feature without even having a good reasoning. I don't think
that this is enough to remove the feature from 1.4.9 release. I was the
person who requested it and have a good use-case for it. Anyway, as many
o
I do not agree...
Maybe you didn't understand completely the use-case:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button click
onClickButton() {
new Thread() {
run() {
service.execu
Thanks for the hint. It is good to know about it.
But how can you get the state of the task when using Async? When creating
the thread myself, I can get an instance of Future and poll its state
whenever I need.
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/
Hi Adriano!
Since you are the person who is started the Anti-2847 movement :), and since
the new release 1.4.9 is out with 2846 included, I think that there is a
good chance for you and for all those who voted +1 for reverting it to prove
the problem.. I am still not convinced in validity of your
My vote is -1. Unless we have a good way to prove the problem, not only
theoretical presumption, we shouldn't revert it in next release.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2229151.html
Sent from the Wicket - Dev mailing l
Hi Adriano again!
I know you have no time for creating the quickstart. That is why I am trying
to reproduce it. I want to make a quickstart to prove if the problem
reported by you is true or false and will publish it when it is ready.
I need some help from you. Could you give a simple example of
OK, then just give me whatever code you use which causes the memory leak...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230020.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
That is exactly what I am trying to do. To make a simple example that cause
the leak and monitor it... By quickstart I mean the simplest project which
helps to cause the leak.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230043.ht
Thanks!
It is enough for me. I'll do the rest from here..
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230086.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
#x27;t increase the heap memory usage. The memory usage comes back to
normal after each restart.
I do not want to draw the conclusion, because I could have a wrong
understanding of what a 'memory leak' is and how to prove it correctly. That
is why, I'm kindly asking you (or anybody
Jeremy, I've tried with redeploy... same story. I'm not insisting on bringing
the issue back. If is the willing of the majority, I'm ok. It is just to
help me understand something that I'm not find that obvious.
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/v
I'm glad we finally came to a conclusion. Do you think it would be useful to
update the task description in JIRA? Even if it will remain 'WON"T FIX', I
don't care, at least we have a proof and learn a little bit more from this
experience.
Thanks!
Alex
--
View this message in context:
http://apa
38 matches
Mail list logo
