Are you using eclipse + wicket bench? Then you can tell the wicket
bench where your css files live.
Martijn
On 3/14/07, Chris Colman [EMAIL PROTECTED] wrote:
I'm using wicket and trying to work out how to set up my directories so
that while editing HTML markups my HTML editor has access to the
On 3/13/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Who is going to attend Apache Con in Amsterdam? We are planning to
host an evening session, but we would like to know how many would be
interested/attend.
I'll be there, and I'd be interested. I've incremented the counter on the
wiki
You can include
wicket:remove
base href=file:///C:/Docs%20and%20Settings/you/your-project/src/webapp/
/
/wicket:remove
in your html head.
2007/3/14, Chris Colman [EMAIL PROTECTED]:
I'm using wicket and trying to work out how to set up my directories so
that while editing HTML markups my
Al Maw wrote
I don't want to do any of A, B or C.
I am not a developer of wicket and it's completely up to yours how you do it,
but why not the following way:
1. Keep Wicket 2 and do the constructor change there. Now you have a java 1.4
branch (wicket 1.x) and a java 5 branch (wicket 2.0 or
* Jean-Baptiste Quenot:
We have DojoTabContainer in Wicket Contrib Dojo that is
client-side only.
See an example at
http://www.demay-fr.net:8080/Wicket-start/app?wicket:bookmarkablePage=:wicket.contrib.dojo.examples.TabContainerSample
Sorry the right URL (more uptodate) was:
* Martijn Dashorst:
Who is going to attend Apache Con in Amsterdam? We are planning
to host an evening session, but we would like to know how many
would be interested/attend.
Me too.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
The whole gest of the discussion is to remove the constructor change.
It hasn't been decided yet, but the future for the constructor change
seems grim.
Martijn
On 3/14/07, Stefan Lindner [EMAIL PROTECTED] wrote:
Al Maw wrote
I don't want to do any of A, B or C.
I am not a developer of wicket
Hi,
I use Wicket 1.2.5 and have been looking at Converters (IConverter
ITypeConverter).
The problem I want to solve is formatting my BigDecimals correctly.
Can't understand why this should be so complicated. Why have converters
at all? Java already has java.text.Format with the methods:
You can include
wicket:remove
base href=file:///C:/Docs%20and%20Settings/you/your-
project/src/webapp/
/
/wicket:remove
in your html head.
Ah cool!
Ok, so that will include the CSS at HTML edit time. What do I need to
put in a tag that is the opposite to wicket:remove? ie., not
Just:
link href=mystyle.css rel=stylesheet /
Martijn
On 3/14/07, Chris Colman [EMAIL PROTECTED] wrote:
You can include
wicket:remove
base href=file:///C:/Docs%20and%20Settings/you/your-
project/src/webapp/
/
/wicket:remove
in your html head.
Ah cool!
Ok, so that will
* Al Maw:
Eelco Hillenius wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
I don't want to do any of A, B or C.
What I /really/ think we should try to achieve:
1. Have long-term JDK 1.4 and JDK 1.5 branches that are easy to
Can anyone vote?
I vote for alternative D.
You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but give
us generics (for models at least).
Alternative D is: Revert to working on 1 branch (doesn't matter if it's
called
Double-check the top-level pom.xml? It should have
modulejdk-1.4/module
modulejdk-1.5/module
but your log doesn't seem to show it doing the jdk-1.4 module tree for
soem reason...
/Gwyn
On 14/03/07, Frank Bille [EMAIL PROTECTED] wrote:
I have upgraded to 2.0.5 and also updated to latest svn
Ar! On closer reading I just realized that you were using the
wicket:remove to set a base whereas I had assumed (without reading too
carefully) that you were using it to include the CSS and consequently I
was concerned that the CSS would be included twice by the HTML editor -
but not do! It
This feels like something someone would have asked before, but I couldn't
find any relevant answers.
I have a usecase where my page/components have role-based security;
ENABLE/RENDER actions are dynamic as opposed to static based upon the
user/data on the page. When data on the page changes
you could keep component instances as fields so you can reference them
directly instead of getting them via their path
-igor
On 3/14/07, ChuckDeal [EMAIL PROTECTED] wrote:
This feels like something someone would have asked before, but I couldn't
find any relevant answers.
I have a usecase
C as wel.
On 3/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not direclty releasing it but usable for people who want 1.3 + java5)
johan
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Can anyone vote?
I vote for alternative D.
You asked about reverting the constructor
Hey guys,
When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called. Why is that? I thought these methods existed
specifically to catch these types of problems?
Thanks
Par
Dear all,
within my Wicket application I'm using a self build process framework. I
klick on a wicket button and a process starts running in an own thread.
I want the process thread to take over the control of the wicket thread
to e.g. build the gui, or change the current model of a component
please look at the converters that are now in 1.3. those are much simpler
and you should be able to do what you want pretty quickly
in 1.2.x it is also possible. But it is a bit harder
Because if you want BigDecimals support for both ways you have to make 2
and then register one for
First of all you shouldn't really access the session in another thread.
Because that is not really supported by a webcontainer, especially in
clustering or persistent storage..
So if you want to spawn to a thread you should only really do backend logic,
not gui logic things.
If you really want
onexception where? onerror is called when a form validation error occurs.
-igor
On 3/14/07, Apaar Trivedi [EMAIL PROTECTED] wrote:
Hey guys,
When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
Me Too.
Can we organize a BOF?
johan
On 3/14/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Martijn Dashorst:
Who is going to attend Apache Con in Amsterdam? We are planning
to host an evening session, but we would like to know how many
would be interested/attend.
Me too.
--
On 3/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
Me Too.
Can we organize a BOF?
That is the idea, or just go and drink ourselves a hangover!
Martijn
On 3/14/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Martijn Dashorst:
Who is going to attend Apache Con in Amsterdam? We
On 3/14/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
Me Too.
Can we organize a BOF?
That is the idea, or just go and drink ourselves a hangover!
As always I am in for this last proposal ;-).
./alex
--
.w( the_mindstorm )p.
Martijn
Something like the following code:
Button searchButton = new Button(searchButton, new
StringResourceModel(searchButton, this, null));
searchButton.add(new MyAjaxFormSubmitBehaviorWithIndicator(form,
onclick) {
protected void onError(AjaxRequestTarget arg0) {
Is the feature set for 1.3 set? I vote to remove everything that may
delay the release of that version.
With alternative C; when would you estimate 1.4 (Java5) could be released?
/Anders
Johan Compagner wrote:
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not
ok
onexception is for exceptions that occur during form processing. in
onsubmit() you are responsible to process your own exceptions since that is
your own handler code
-igor
On 3/14/07, Apaar Trivedi [EMAIL PROTECTED] wrote:
Something like the following code:
Button
no there is a discussion about that.
1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0
And no releasing it quickly will not mean that we will release a java5
version quickly
because that will mean we will again have multiply branches to support.
johan
On 3/14/07, Anders
Is it this?
https://issues.apache.org/jira/browse/WICKET-376
Apaar Trivedi wrote:
Hey guys,
When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called. Why is that? I thought
Why have converters at all?
Because dates and numbers and possibly other things should
transparently be presented and parsed in a locale aware fashion.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join
Yeah, that's what I thought you were going to say.
What I ended up doing was to make two complimentary methods
// keep a registry of Components that are event sources (stored as Map on
the Page)
registerAsEventSource(String sourceName, Component source)
// keep a registry of event targets
1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0
And no releasing it quickly will not mean that we will release a java5
version quickly
because that will mean we will again have multiply branches to support.
It would be my idea to follow up with a Java 5 version asap
I can understand why onException might only be used for internal exceptions
in processing, but shouldn't the exception at least escalate back up to
RequestCycle.onRuntimeException and be handled there?
Otherwise, are we expected to always catch any possible Throwable in our
onSubmit if we want
From reading old posts I know that the converters have been improved
for 1.3/2.0 but I'm doing my best to stay away from beta versions.
I have built two new ITypeConverters, a new IConverter and a new
IConverterFactory and ... it kind of works. Strangely I don't see the
correct format
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
One of my questions remain: Why does Wicket need converters at all? Java
already has java.text.Format with two-way conversion between String and
some other class.
But they assume the VM's locale, not the locale of the request/session/user.
Do you plan to still release new features for old Java after you've
released a Java5 version? That seems crazy.
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should have moved to
Java5 at least one year ago!
/Anders
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Do you plan to still release new features for old Java after you've
released a Java5 version? That seems crazy.
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should
No. You create them specifying which Locale to use. Look at the static
factory methods in NumbverFormat.
http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html
All Wicket would needs is a FormatFactory that reads the Locale from the
request/session/user and instantiates correct
and does that api support registering your own converters?
-igor
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
No. You create them specifying which Locale to use. Look at the static
factory methods in NumbverFormat.
http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should have moved to
Java5 at least one year ago!
I beg to
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
No. You create them specifying which Locale to use. Look at the static
factory methods in NumbverFormat.
http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html
All Wicket would needs is a FormatFactory that reads the Locale
Maintaining Wicket 1.3 should be for bug fixes, not new features. But
that doesn't prevent new components to be developed, or backported by
our community if there is a need for JDK 1.4 components. And if you
really have a need, then you can always use retrotranslator/weaver to
backport 1.5
1) I think you're overestimating the trouble that would cause. The only
thing they're not getting is new features after the next release. In
terms of new (major) releases no one has gotten anything for almost a year.
2) You also lose something by not moving to Java5... Wicket can be
better
isnt this thread a poll? how many polls of the same thing do we need? omfg
ponies!
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Maintaining Wicket 1.3 should be for bug fixes, not new features. But
that doesn't prevent new components to be developed, or backported by
our
This thread is about 'Reverting the constructor change of 2.0', not
about 'Stop supporting JDK 1.5 after 1.3'.
Eelco
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
isnt this thread a poll? how many polls of the same thing do we need? omfg
ponies!
-igor
On 3/14/07, Eelco Hillenius
Not sure what you mean, but if you control the factory you control the
formatters. /Anders
Igor Vaynberg wrote:
and does that api support registering your own converters?
-igor
On 3/14/07, *Anders Peterson* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
No. You create them
well obviously we cannot poll for that until we have decided what 1.3 will
be. so first you need a poll on that, then you need a poll that depends on
that poll so we can decide when to drop support for 1.5. and then another
poll on the what to do next, but that poll has to depend on the previous
wicket-ajax.js (revision 518211) appears to have a problem.
I think lines 296-299 should be
var e = element.childNodes[i];
if (e.tagName != null) {
result += Wicket.Form.serialize(e);
}
but right now they are
var e = element.childNodes[i] {
if (e.tagName != null) {
Don't poll too much - just decide on something. The core development
team is relatively small isn't it... /Anders
Igor Vaynberg wrote:
well obviously we cannot poll for that until we have decided what 1.3
will be. so first you need a poll on that, then you need a poll that
depends on that
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
well obviously we cannot poll for that until we have decided what 1.3 will
be. so first you need a poll on that, then you need a poll that depends on
that poll so we can decide when to drop support for 1.5. and then another
poll on the what to
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Don't poll too much - just decide on something. The core development
team is relatively small isn't it... /Anders
But the user base isn't anymore.
Eelco
-
Take Surveys.
i guess sacrasm and frustration dont transfer well over email :|
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
well obviously we cannot poll for that until we have decided what 1.3will
be. so first you need a poll on that,
From a user base standpoint, I am just waiting for core developer to decide
something...
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Don't poll too much - just decide on something. The core development
team is relatively small
I didn't mean that bad. I would just prefer someone else to do the next vote.
Eelco
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess sacrasm and frustration dont transfer well over email :|
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Igor Vaynberg
Actually, it should be fixed already. Can you please check if it works
as it should?
-Matej
On 3/14/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
I do not see difference between you two ;) samples
but maybe you was talking about that :
https://issues.apache.org/jira/browse/WICKET-387.
I
hi,
i came over from another framework to wicket because i didnt like the
api change with every release there and liked the way wicket does things.
first i was not sure which version of wicket to use and read the mailing
list and found out, that 2.0 suits best to me. after starting 2 bigger
On Tuesday, 13 March 2007 03:31 pm, Jean-Baptiste Quenot escreveu:
* Igor Vaynberg:
a better option for these situations imho is to not to use a
serverside tabpanel, but a clientside one. that way your
entire form is written out and the submit button submits
the
Sorry, I should have been explicit about what I was pointing out. The last
char of the first line (var e ...) should be a semicolon, not an open brace
as it is in the second snippet.
And yes, the reason why I even was looking was because of WICKET-387. I
patched my code to fix it and will
i came over from another framework to wicket because i didnt like the
api change with every release there and liked the way wicket does things.
first i was not sure which version of wicket to use and read the mailing
list and found out, that 2.0 suits best to me. after starting 2 bigger
heh, of course. sorry for that. i wonder how could i have missed that,
as i have tested script.
-Matej
On 3/14/07, ChuckDeal [EMAIL PROTECTED] wrote:
Sorry, I should have been explicit about what I was pointing out. The last
char of the first line (var e ...) should be a semicolon, not an
I finally got it!! Ok, two things:
First the pom file error. I'll commit a fix for the root pom without the
jdk15 profile. This was the one which caused problems with the second error.
The first error was because of some old versions of maven plugins. I didn't
find out what it exactly was
umm, we already found a solution for that
mvn eclipse:eclipse -U
which tells maven to update its dependencies
woops :)
-igor
On 3/14/07, Frank Bille [EMAIL PROTECTED] wrote:
I finally got it!! Ok, two things:
First the pom file error. I'll commit a fix for the root pom without the
jdk15
And why didn't anyone tell me that? We can't all be maven experts ;)
Frank
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
umm, we already found a solution for that
mvn eclipse:eclipse -U
which tells maven to update its dependencies
woops :)
-igor
On 3/14/07, Frank Bille [EMAIL
If you are off into the city, I'll join you. Perhaps I can show you one
or two locations as well.
Erik.
Alexandru Popescu schreef:
On 3/14/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
That is the idea, or just go and drink ourselves a hangover!
As always I am in for this
Serial version UID exists to prevent problems deserializing persistent
serialized data, and since serialization is not being used for long-term
persistent storage in Wicket (unless you have some unusual project going,
sessions should not be persistent across class changes), I cannot see
a need
I think some containers complain in certain cases if you don't have
them. Johan, what was the problem with not having those UIDs again?
Eelco
Serial version UID exists to prevent problems deserializing persistent
serialized data, and since serialization is not being used for long-term
Hi all
Among the questions I had, one of the core questions is the following
one : is the architecture I plan to use appropriate ? Just to give a
bit of insight, I'm new to Hibernate/Spring and Wicket (ouch !). lol
But I'm really motivated :) I would like to be sure I don't do huge
mistake in my
On 3/14/07, ZedroS Schwart [EMAIL PROTECTED] wrote:
When I have to change an object on the OnSubmit, I use the update
methods from my managers. What I fear here is to update some data
which have already been updated in between.
hibernate and jpa provide optimistic locking that guards against
oh. that could be. i guess a server could use this in theory to
keep old session info on a code-change that didn't affect class
layout. but does anyone really do that?
Eelco Hillenius wrote:
I think some containers complain in certain cases if you don't have
them. Johan, what was the
Hi folks,
As part of our ongoing incubation process at Apache, we're going to be
renaming the core wicket package from wicket to org.apache.wicket
shortly (not quite sure when yet, but soon).
If you're developing against the subversion wicket-1.x branch, you'll
need to change your imports
72 matches
Mail list logo
