date:20090728

Google Analytics and AJAX

2009-07-28 Thread John Armstrong

Is anyone doing this:
http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55519

If so can you share your code? If not I'll build it ;)

John-

Re: Twenty Six Wicket Tricks

2009-07-28 Thread Fernando Wermus

+1 Wicket Cookbook

On Tue, Jul 28, 2009 at 6:04 PM, taha siddiqi  wrote:

> +1
> "26 Wicket Tricks" or "Wicket Cookbook" or "Wicket Recipes"
>
> (Whenever I am trying something new I always try a cookbook, It later
> on acts as a reference too)
>
> taha
>
>
> On Wed, Jul 29, 2009 at 3:38 AM, Matej Knopp wrote:
> > On Tue, Jul 28, 2009 at 11:55 PM, Vladimir K wrote:
> >>
> >>
> >> Matej Knopp-2 wrote:
> >>>
> >>> Modal Window is an ajax component. Submitting it with regular submit
> >>> is not supported and it never was.
> >>>
> >>
> >> But I would like to have AjaxFallbackModalWindow that survives page
> refresh.
> >> Why not author my own if the aims are different? Probably requirements
> we
> >> have are far from being accepted as common.
> > Of course you can. There's nothing wrong with that.
> >>
> >>
> >>
> >>> Again, modal window doesn't support regular submits (by design) so if
> >>> you want to do file upload you'll have to use a hidden iframe or some
> >>> other approach like that.
> >>>
> >>
> >> IMO, Iframe is not an approach it is a work around the limitation (made
> by
> >> design) :)
> > Yes. But from the beginning Modal Window was designed as Ajax Component.
> >>
> >>
> >>
> >>> I just looked at jquery dialog example. The dialog is declared in
> >>> markup but it is then reparented as top level DOM element. Same thing
> >>> wicket modalwindow does.
> >>>
> >>
> >> What is especial in my case is that the page height is limited by the
> window
> >> height and contains a srollable div within. Taking into account that the
> >> browsers we support works well with fixed positioning and assuming that
> the
> >> following excerpt works:
> >>
> >>
> >>
> >>> Fixed positioning is a special case of absolute positioning. For fixed
> >>> elements, the containing block is always taken to be the viewport of
> the
> >>> browser window.
> > This is true. Unfortunately it doesn't apply to IE6 which doesn't
> > support position:fixed. Modal Window was written couple of years ago
> > when IE6 position was quite strong, however even now we can't afford
> > to ignore it. Unfortunately.
> >>>
> >>
> >> It seems to be pretty doable. But it needs investigation. I haven't
> tried
> >> yet.
> > Position:fixed will work in your case if you can afford to ignore IE6.
> > But it's not something we can do in wicket extensions.
> >>
> >>
> >>
> Anyway it is possible to do what the modal.js is doing by Wicket means
> and
> don't have a component tree mismatch with DOM.
> >>>
> >>> Is it really? Mind sharing with me how?
> >>>
> >>
> >> In case if the position:fixed does not help I would subclass a Form and
> make
> >> it a container of ModalWindows. Then by placing the
> >> modal-window-container-form at the body level I would acquire a new
> >> ModalWindow from the container. Does it make sense?
> >>
> > So the ModalWindow would have to be added to the container (which I
> > assume would have to be added to the page itself)? That's rather
> > limiting.
> >
> > -Matej
> >> --
> >> View this message in context:
> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24708596.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus

Re: reuseitems problems

2009-07-28 Thread Martin Makundi

It might also be that it is wickettester related problem, maybe
something goes somehow wrong there. I will try to make a quickstart.

**
Martin

2009/7/29 Vladimir K :
>
> Hmm ... i can imagine the only case - somewhere resolveObject() method is
> called during deserialization.
> But I'm afraid your code don't have such a method and the cause is
> different.
>
>
> MartinM wrote:
>>
>> I do not know exactly what happens, but if I run the debugger I can
>> see thet the page seen by the formcomponents' propertymodels is in a
>> different state than the one actually holding the form components.
>>
>> I wonder if ajax has something to do with this, because only part of
>> the page is refreshed via ajax. Maybe the parent page and the
>> refreshed ajax panel remain in different serialization graphs?
>>
>> **
>> Martin
>>
>> 2009/7/28 Vladimir K :
>>>
>>> trying to undertand what is happening in your case. When the page is
>>> serialized the steam contains the whole graph, including the ListView and
>>> it's items and the page default model and the ListView items models. When
>>> the page is deserialized, the whole graph is restored including page, its
>>> model, items and their models. My understanding is that in your case the
>>> items models are the old ones that was in the previous version of the
>>> page,
>>> how could it be? Or I didn't get what you were saying.
>>>
>>>
>>> MartinM wrote:

 Or session store.. anyways, that's not relevant. The important fact is
 that the copies are different.

 **
 Martin

 2009/7/28 Martin Makundi :
>> why do you get Page instance 2 on page refresh?
>
> Wicket always deserializes page state from diskstore.. so it is a copy.
>
> **
> Martin
>
>>
>>
>> MartinM wrote:
>>>
 please describe the context. I don
>

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/reuseitems-problems-tp24702133p24705851.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/reuseitems-problems-tp24702133p24708835.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: javascript effects before an ajax call

2009-07-28 Thread Antony Stubbs

I have a workaround and it goes a little something like this:

Wicket.replaceOuterHtml=function(element,
text) {


 new $(element.id).fade({ duration: 0.4, afterFinish: function(effect) {

 if (Wicket.Browser.isIE()) {

Wicket.replaceOuterHtmlIE(element, text);

} else if (Wicket.Browser.isSafari() || Wicket.Browser.isOpera()) {

Wicket.replaceOuterHtmlSafari(element, text);

} else /* GECKO */ {

// create range and fragment

var range = element.ownerDocument.createRange();

range.selectNode(element);

var fragment = range.createContextualFragment(text);

 element.parentNode.replaceChild(fragment, element);

}

 $(element.id).appear({ duration: 0.4});

}});

 }




Putting that at the top of the html overrides the wicket function, adds in a
javascript effect, then using the onFinish hook, runs the original Wicket
code, the precedes with another effect. This makes the effects run
immediately after the ajax call has completed...

This adds a fade transition every time wicket replaces a dom element. A
better version would allow you to do it with some hooks, passing in your
transition functions.

2009/7/28 Antony Stubbs 

> (sorry, sent to wrong list before)
> Is it possible to override certain methods in wicketajax.js ? In order to
> modify the behaviour of one of the methods.
>
> but i'd prefer not to run a patched wicket, or have to run on a copy of the
> whole wicketajax.js file - but i will if i have to :/
>
> what i want to do is add pre and post hooks
> processComponent#Wicket.replaceOuterHtml function - as this will solve what
> I want to do - i.e. run an animation on the element to be replaced, after
> the ajax call completes, but before the element is replaced.
>
> p.s. martijn, is there any info available on the plan for the new ajax
> system?
>
> I just found - there is a post animation hook in Scriptaculous, which I
> have working to run the ajax request in, however this doesn't quite get
> there, as there's is of course the delay between when the animation
> finishes, and when the ajax request actually completes - which is too long.
>
> Update:
> I've tried overriding the js functions like this:
>
> 
>
> function newProcessComponent: function(steps, node) {
> alert('replaced!');
> }
>
> Wicket.Ajax.Call.prototype.processComponent = newProcessComponent
>
> 
> Wicket.replaceOuterHtml=function() {alert(
> 'replaceOuterHtml');}
> Wicket.Ajax.Call.prototype.processComponent:
> function(steps, node) {{alert('processComponent');}
>
> but only the replaceOuterHtml functions works, i think because the there's
> a difference because processComponent is  a member of an object...
> I need to replace processComponent so that I can have access to the
>
> Cheers,
> Antony Stubbs,
>
> sharca.com
>
> On 27/07/2009, at 9:31 PM, Martijn Dashorst wrote:
>
> Not 100% sure if it's already done, but I've bugged Matej with this
>
> request for 1.5's new Ajax implementation.
>
>
> Martijn
>
>
> On Mon, Jul 27, 2009 at 9:40 AM, Antony Stubbs
> wrote:
>
> Was this ever implemented / solved?:
>
>
>
>
> Nov 21, 2006; 07:09am Re: Using Javascript Effects Before An Ajax Call
>
> This is possible to do with wicket, however it would require minor
>
> enhancement of the ajax processing code.
>
>
> We already have infrastructure for asynchronously postponing processing
>
> steps.
>
>
> However, I can't do that right now. Maybe in a week or so. So if anyone
>
> really needs to pause between executing scripts from "prependJavascript"
>
> and replacing the elements (which is I understand right this is all
>
> about), keep bugging me, I will eventually implement that. :)
>
>
> -Matej
>
>
> cygnusx2112 wrote:
>
>
> Thanks for the clarification Igor. I ended up achieving the desired affect
>
> by
>
> using an AjaxCallDecarator in combination with a server side pause.
>
> Basically I was trying to do the following:
>
>
>   1) Run animation effect on element
>
>   2) Use Ajax request to replace element
>
>   3) Run another animation effect on the element
>
>
> As you noticed, I needed a way to block so that #2 and #3 would not step
>
> on
>
> #1. As a non-Javascript guru I was unable to find a way to block the
>
> Javascript "thread" without some kind of CPU beating hack loop. However,
>
> the
>
> solution I am using seems to work well.
>
>
> In my efforts to accomplish this I have built some pretty interesting
>
> subclasses of AjaxEventBehavior that might be worth contributing. They
>
> basically allow you to cleanly add pre/post visual effects to components
>
> around an Ajax event.
>
>
> Regards,
>
>
> -MT
>
>
>
>
>
> igor.vaynberg wrote:
>
>
> the effect is clearly executed asynchronously from the rest of the
>
> javascript "thread" so you need to find a way to block until the effect
>
> is
>
> complete.
>
>
> -igor
>
>
>
> ... [show rest of quote]
>
>
>
> -
>
> Take Surveys. Earn Cash. Influence the Future of IT
>

Re: Twenty Six Wicket Tricks

2009-07-28 Thread taha siddiqi

+1
"26 Wicket Tricks" or "Wicket Cookbook" or "Wicket Recipes"

(Whenever I am trying something new I always try a cookbook, It later
on acts as a reference too)

taha


On Wed, Jul 29, 2009 at 3:38 AM, Matej Knopp wrote:
> On Tue, Jul 28, 2009 at 11:55 PM, Vladimir K wrote:
>>
>>
>> Matej Knopp-2 wrote:
>>>
>>> Modal Window is an ajax component. Submitting it with regular submit
>>> is not supported and it never was.
>>>
>>
>> But I would like to have AjaxFallbackModalWindow that survives page refresh.
>> Why not author my own if the aims are different? Probably requirements we
>> have are far from being accepted as common.
> Of course you can. There's nothing wrong with that.
>>
>>
>>
>>> Again, modal window doesn't support regular submits (by design) so if
>>> you want to do file upload you'll have to use a hidden iframe or some
>>> other approach like that.
>>>
>>
>> IMO, Iframe is not an approach it is a work around the limitation (made by
>> design) :)
> Yes. But from the beginning Modal Window was designed as Ajax Component.
>>
>>
>>
>>> I just looked at jquery dialog example. The dialog is declared in
>>> markup but it is then reparented as top level DOM element. Same thing
>>> wicket modalwindow does.
>>>
>>
>> What is especial in my case is that the page height is limited by the window
>> height and contains a srollable div within. Taking into account that the
>> browsers we support works well with fixed positioning and assuming that the
>> following excerpt works:
>>
>>
>>
>>> Fixed positioning is a special case of absolute positioning. For fixed
>>> elements, the containing block is always taken to be the viewport of the
>>> browser window.
> This is true. Unfortunately it doesn't apply to IE6 which doesn't
> support position:fixed. Modal Window was written couple of years ago
> when IE6 position was quite strong, however even now we can't afford
> to ignore it. Unfortunately.
>>>
>>
>> It seems to be pretty doable. But it needs investigation. I haven't tried
>> yet.
> Position:fixed will work in your case if you can afford to ignore IE6.
> But it's not something we can do in wicket extensions.
>>
>>
>>
Anyway it is possible to do what the modal.js is doing by Wicket means and
don't have a component tree mismatch with DOM.
>>>
>>> Is it really? Mind sharing with me how?
>>>
>>
>> In case if the position:fixed does not help I would subclass a Form and make
>> it a container of ModalWindows. Then by placing the
>> modal-window-container-form at the body level I would acquire a new
>> ModalWindow from the container. Does it make sense?
>>
> So the ModalWindow would have to be added to the container (which I
> assume would have to be added to the page itself)? That's rather
> limiting.
>
> -Matej
>> --
>> View this message in context: 
>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24708596.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

[problem] http://dliu-pc:8080/WB/../brainSideBar?wicket:interface=:1:comments:post::IFormSubmitListener::

2009-07-28 Thread Dapeng Liu

Hi,
I am a rookie to Wicket and need help here. The problem may be easy for you
but the detailed introduction is tedious.
In one shortest sentence, the URL shown in the subject should be
http://dliu-pc:8080/WB/brainSideBar?wicket:interface=:1:comments:post::IFormSubmitListener::
instead (i.e., parent folder sign .. eliminated), in my opinion.

The underneath is about details:

Environment:
Tomcat 6.0.18
Wicket 1.3.6
JRE 1.6 update 13

Web app:
WB maintained by Tomcat and the url is http://dliu-pc:8080/WB.
(Actually, on local machine.)

Problem:
The involved url is http://dliu-pc:8080/WB/brainSideBar.
WebPage brainSideBar contains a Wicket Panel Comments.
In one case, Comments throws one RestartResponseAtInterceptPageException
to let the users log in. The address bar shows
http://dliu-pc:8080/WB/?wicket:interface=:2 thereafter. Login page shows
normally.
After the user log in, we cannot go back to
http://dliu-pc:8080/WB/brainSideBar since the url is wrong as shown in the
subject, which was revealed by a HTTP sniffer tool. This url is interpreted
by FireFox 3.5 and Chrome as
http://dliu-pc:8080/brainSideBar?wicket:interface=:1:comments:post::IFormSubmitListener::.
There is nothing in page source.
If now we ask the browser to go to the correct url
http://dliu-pc:8080/WB/brainSideBar?wicket:interface=:1:comments:post::IFormSubmitListener::,
brainSideBar will be correctly shown while the url shown in the address bar
becomes http://dliu-pc:8080/WB/?wicket:interface=:1:1:::.

One fact that may matter:
Previously, WicketFilter was used for url-pattern /app/*; the url
returned under the same scenario was (only important segments shown here:)
...WB/app/../app/brainSideBar?, so that the correct url
...WB/app/brainSideBar?...was finally composed.

77 matches

Mail list logo