Ok, let me try to explain another way.
If you create a page where you use the radio component. The radios represent
various kinds of datasets(OLAP cubes in this case but it does not really
matter).
On monday the 1. march you record with jmeter your test case(jmeter only
records the http
I'm not sure I fully understand what you're trying to do, but CheckGroup/Check
components are a nice solution for managing the selection of multiple objects.
No need to introduce a boolean property in your domain objects.
Please take a look at FormInput.java from wicket examples:
CheckGroup
Is it possible to store the HTML markup in a separate directory that is
not part of the web app or web server directory structure?
If necessary I could mimic the classpath in the separate directory so
the HTMLs are stored in similarly named directories to their
corresponding Java classes.
I've
http://cwiki.apache.org/WICKET/custom-resource-paths.html
Eelco
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
Is it possible to store the HTML markup in a separate directory that is
not part of the web app or web server directory structure?
If necessary I could mimic the classpath in the
Hi
I'm playing with Ajax and Wicket, which is quite fun, but I've an
issue with AjaxSubmitButton and FormComponentFeedbackBorder.
I guess I should use target.addComponent(Component) ; to declare in my
AjaxSubmitButton that I want the feedback border to be updated.
However, I'm using a
Hi,
I have a panel A that is replaced by another panel B over Ajax using
Component.replaceWith(). Panel B contains a few Links.
Say I navigate to this Page and trigger the event that causes panel B to
replace Panel A. Then I click one of the Link(s) within Panel B that brings
up another page.
Which repoints readers to
http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
Got a minute to do a quick comment on the two of them?
/Gwyn
On 28/03/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
http://cwiki.apache.org/WICKET/custom-resource-paths.html
Eelco
On
Quick update :
I've found some help here :
http://www.nabble.com/FeedbackPanel%2C-Form%2C-which-component-is-caousing-feedback--tf2427268.html#a6767963
but I'm still looking for how to tell the FormComponentFeedbackBorder
to render itself..
++
ZedroS, digging in !
On 3/28/07, ZedroS Schwart
I think I found one solution, what I did was to add the normal textfield
an AjaxFormComponentUpdatingBehavior associated to the onchange event. In the
code of onUpdate() I add an AttributeModifier that replaces the value of the
value attribute, then I replace the textfield in the form and use
Peter, are you using 1.x? this can be caused by ajax requests being
non-versioned in 1.2. In 1.x, the changes should be merged to latest
version.
On 3/28/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
matej didnt you fix this in 1.x svn?
-igor
On 3/28/07, Peter Thomas [EMAIL PROTECTED] wrote:
you should be able to write your own behavior that does what you want
easily. just look at how formcomponentupdating one works.
-igor
On 3/28/07, ChuckDeal [EMAIL PROTECTED] wrote:
Is there a way to store the value of multiple form components using
AjaxFormComponentUpdatingBehavior? Is
How do I go about setting what image to use? I have:
/images/green-check.png
/images/yellow-alert.png
And I want to choose which one of these to display on page creation time. I
though it could be something simple like:
add(new Image(image, images/green-check.png));
img wicket:id=image/
but
use a visitor to visit all form component feedback borders and add them to
the target.
-igor
On 3/28/07, ZedroS Schwart [EMAIL PROTECTED] wrote:
Quick update :
I've found some help here :
so this would associate my object with a checkbox? how do i place the select
objects in a collection from there?
-B
svenmeier wrote:
I'm not sure I fully understand what you're trying to do, but
CheckGroup/Check components are a nice solution for managing the selection
of multiple
search the list for StaticImage
-igor
On 3/28/07, Jason Roelofs [EMAIL PROTECTED] wrote:
How do I go about setting what image to use? I have:
/images/green-check.png
/images/yellow-alert.png
And I want to choose which one of these to display on page creation time.
I though it could be
Hmm, thanks, that does help, but the resulting output does not get processed
by Wicket's rendering engine like other img tags.
This means that while the image tags I manually write out end up saying
img src=/app/images/green-check.png/
the output from StaticImage ends up being
img
what wicket version are you using?
-igor
On 3/28/07, Jason Roelofs [EMAIL PROTECTED] wrote:
Hmm, thanks, that does help, but the resulting output does not get
processed by Wicket's rendering engine like other img tags.
This means that while the image tags I manually write out end up saying
Wow, that's even for version 1.0. :) I guess we should have just one
page, explaining 1.3 and as a note mentioning the difference for 1.2.
I think we can ditch anything pre 1.2
Eelco
On 3/28/07, Gwyn Evans [EMAIL PROTECTED] wrote:
Which repoints readers to
Wicket 1.3, pulled from the apache incubator.
Jason
On 3/28/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
what wicket version are you using?
-igor
On 3/28/07, Jason Roelofs [EMAIL PROTECTED] wrote:
Hmm, thanks, that does help, but the resulting output does not get
processed by Wicket's
wicket 1.3 uses relative urls. we are working on building context-path
support for this right now. should be done sometime this week. then all you
will have to do is
add(new ContextImage(img, images/foo.gif)); and wicket will build the
proper path from anywhere, even if the page is mounted.
there is also an example in wicket-examples
-igor
On 3/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Wow, that's even for version 1.0. :) I guess we should have just one
page, explaining 1.3 and as a note mentioning the difference for 1.2.
I think we can ditch anything pre 1.2
Eelco
On
Are you using mvn to build? I changed the wicket dependency in the
WICKET_1_2 branch from SNAPSHOT to 1.2.5, so maybe this will help you.
Let me know if it doesn't.
best,
jim
On 3/27/07, Andrew Berman [EMAIL PROTECTED] wrote:
Can this only be built against version 1.3 of Wicket? I'm unable to
CheckGroup selectedPensCheckGroup = new CheckGroup(selectedPens,
selectedPensModel);
add(selectedPensCheckGroup);
ListView pensList = new ListView(pens, pensModel)
{
protected void populateItem(ListItem item)
{
item.add(new Check(check, item.getModel()));
thank you...I just figured it out..with help from the IRC
-B
svenmeier wrote:
CheckGroup selectedPensCheckGroup = new CheckGroup(selectedPens,
selectedPensModel);
add(selectedPensCheckGroup);
ListView pensList = new ListView(pens, pensModel)
{
protected void
there is a reason why some of the stuff is done where it is. now,
I believe that with the minor change that I have made everything is
still being done in the exact same order so there should be no
consequences of this change. It's just that all the stuff done in
commonInit is now being slightly
Awesome, builds now.
Thanks,
Andrew
On 3/28/07, James McLaughlin [EMAIL PROTECTED] wrote:
Are you using mvn to build? I changed the wicket dependency in the
WICKET_1_2 branch from SNAPSHOT to 1.2.5, so maybe this will help you.
Let me know if it doesn't.
best,
jim
On 3/27/07, Andrew Berman
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
there is a reason why some of the stuff is done where it is. now,
I believe that with the minor change that I have made everything is
still being done in the exact same order so there should be no
consequences of this change. It's just that
https://issues.apache.org/jira/browse/WICKET-432
-igor
On 3/28/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
there is a reason why some of the stuff is done where it is. now,
I believe that with the minor change that I have made everything
i'm not sure what i think about this yet. can you show us the
exact code modifications and use cases you have coded up?
(boiled down to the important parts, if possible) also, it would
be good if you could explain how this solves any problems
other than getVariation().
Chris Colman wrote:
there is also an example in wicket-examples
-igor
On 3/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Wow, that's even for version 1.0. :) I guess we should have just one
page, explaining 1.3 and as a note mentioning the difference for
1.2.
I think we can ditch anything pre 1.2
i'm not sure what i think about this yet. can you show us the
exact code modifications and use cases you have coded up?
(boiled down to the important parts, if possible)
Ok, here's the changed bits you requested. Only 3 Java classes need
minor changes in the framework:
[I added the deferred
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
i am against this because i do not think the value it brings is worth the
complexity it adds.
you can persuade me by coming up with examples that actually demonstrate the
advantage. it is common practice in wicket to use imodel to deffer lookup
I believe that with the minor change that I have made everything is
still being done in the exact same order so there should be no
consequences of this change. It's just that all the stuff done in
commonInit is now being slightly deferred so that it uses completely
constructed objects
the fact remains that getvariation() call from webpage constructor is a bug
we need to fix.
further we already have listener methods you can use - onattach and ondetach
what you want can be just as easily accomplished on every component
class mypage extends webpage {
private boolean
Also take a look at wicket.examples.customresourceloading in
wicket-examples. Maybe nothing you didn't know yet... but maybe :)
Eelco
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
there is also an example in wicket-examples
-igor
On 3/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi all,
I'm migrating a spring-mvc project to wicket. In this project domain objects
are directly exposed to the ui (without DTOs in between). The objects are
validated using the spring bean validation framework (part of
springmodules). This module creates a unique Validator (a spring interface)
the fact remains that getvariation() call from webpage constructor is
a
bug we need to fix.
Yeah, that's my numero uno motivation at this point also.
further we already have listener methods you can use - onattach and
ondetach
what you want can be just as easily accomplished on every
On 3/28/07, Chris Colman [EMAIL PROTECTED] wrote:
Easy if you deal with the parameters in the constructor and deal with
adding children, accessing markup etc., in the overridden init (or
commonInit) method.
In cases where people have a number of constructors they normally create
their own
Matej - I am using wicket-1.3-incubating-SNAPSHOT.jar dated 2007-03-12
Let me know if you need any more details. On the Page in question I had
tried setVersioned with both true and false, same result.
Thanks,
Peter.
On 3/28/07, Matej Knopp [EMAIL PROTECTED] wrote:
Peter, are you using 1.x?
peter can you try updating to the lastest snapshot and trying again?
-igor
On 3/28/07, Peter Thomas [EMAIL PROTECTED] wrote:
Matej - I am using wicket-1.3-incubating-SNAPSHOT.jar dated 2007-03-12
Let me know if you need any more details. On the Page in question I had
tried setVersioned
Igor,
I now see that there is a 1.3.0-incubating-SNAPSHOT (as opposed to
1.3-incubating-SNAPSHOT which I was using earlier).
I assume this is the latest version and just switched. But Looks like
wicket.markup.html.form.validation.AbstractValidator has disappeared. I
don't see a mention of
hmm, it is briefly mentioned under
Validation Changesi dont remember if we still have abstract validator or
not, see the source of other alidators and if they extend something.
-igor
On 3/28/07, Peter Thomas [EMAIL PROTECTED] wrote:
Igor,
I now see that there is a 1.3.0-incubating-SNAPSHOT
Ok, my bad - the documentation does mention the package change to
wicket.validation.validator.AbstractValidator
But the API looks a lot different, can you quickly point me to the online
Javadoc corresponding to 1.3.0-incubating-SNAPSHOT - also if it is
downloadable as a zip or something.
http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3.0-incubating-SNAPSHOT/wicket-1.3.0-incubating-SNAPSHOT-javadoc.jar
It would be good if someone could write a couple of scentences on how
to migrate from the old to the new ones. It's not difficult, but
indeed a bit different.
we only have an unofficial release for it that is a zip. search the list for
it, it is in martijn's dir somewhere.
other then that all the jars/src/and javadocs are available from that
wicketstuff.org maven repo.
all the new classes in wicket.validator package have pretty good javadocs so
that
Thanks Eelco Igor I got the api and src and made the changes for
AbstractValidator - will also try to add some stuff to the wiki page as soon
as I finish refactoring.
But I have a big problem with the usage of wicket:message attribute (tag
works fine). This is the error:
auto is something from 2.0, are you sure you have the right jars?
-igor
On 3/28/07, Peter Thomas [EMAIL PROTECTED] wrote:
Thanks Eelco Igor I got the api and src and made the changes for
AbstractValidator - will also try to add some stuff to the wiki page as soon
as I finish refactoring.
47 matches
Mail list logo
