The latest 1.4 snapshot does not define IComponentBorder interface in
addition to disappeared form component persistence.
Is it supposed that 1.4.2 breaks compatibility with 1.4.1?
I see the only way to check the fix in wicket-ajax.js - mix it into wicket
1.4.1 jar.
Vladimir K wrote:
>
> I u
This is because you're not using models correctly. And you apparently are
not using page inheritance either. Both of those things will fix this
"problem" that you describe. Also, Wicket makes it *very* easy to create
reusable code - in your link example, just make a subclass of link as a
concret
If you actually want to redirect them to the other site (with a post, and
not just a get), you will just need to render a form and rely on javascript
to auto-submit it for you (likely with a "click here if not redirected"
link). The hidden fields could be rendered with attribute modifiers on
webma
And, if you want access to the session from within your web service, you can
wrap the wicket session filter around your servlet, service, etc, so that it
has access to Session.get(). There are a quite a few posts on this mailing
list that will steer you in the right direction for that.
--
Jeremy
> > >> this contract is not factored out anywhere, but maybe doing so
may
> be
> > >> worthwhile. can be part of your patch, something like
> > >> ComponentResolvers.resolve(MarkupContainer parent, )
I've tried invoking the application resolvers from many different places
within the Enclosure
> >> this contract is not factored out anywhere, but maybe doing so may
be
> >> worthwhile. can be part of your patch, something like
> >> ComponentResolvers.resolve(MarkupContainer parent, )
Yes looks like this code in MarkupContainer.renderNext would need to be
factored out:
// 3rd
> to resolve the wicket:enclosure tag itself.
>
> the tag handler will assign a wicket:id to the wicket:enclosure tag.
> the component resolver then has to resolve that wicket:id to a
> component.
Ah, ok. At first it seemed strange to need an EnclosureResolver when
wicket already knew that it was
to resolve the wicket:enclosure tag itself.
the tag handler will assign a wicket:id to the wicket:enclosure tag.
the component resolver then has to resolve that wicket:id to a
component.
-igor
On Fri, Sep 18, 2009 at 8:35 PM, Chris Colman
wrote:
>> to make the component a direct child of enclos
Hi All,
I originally posted this message yesterday as a response to the post called
Testing DataView
(see http://www.nabble.com/Testing-DataView-td21863271.html).
For some reason, my response didn't show up in the list as one of the most
recent comments. So I am
posting it again as a new message
This problem is solved. I was smart enough to use setResponsePage in
logic built into onBeforeRender.
Why onBeforeRender? It's a wizard panel whose content changes on every
render and when the wizard finally ends, there was a setResponsePage.
Fix?: use throw new RestartResponseException(NewPage.c
10 matches
Mail list logo
