i don't hope that #Id# is mandatory!
I hate those things. Because those things mess up merging of branches
because they constantly change.
It is totally stupid that this is the case. A merge should ignore those
completely.
johan
On 11/6/06, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi
My point is that in checkstyle you are free to enforce both the presence
_and absence_ of anything that can be expressed as a regular expression.
So that includes the $Id$ tag.
That I always enforce inclusion of an $Id$ is just an example. In most
of my projects I don't have a lot of merging
Does it means that if the inner form is replaced with span that it
might look different (preview different from rendered output)?
Juergen
On 11/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Well... Semantically span is an inline element.
Form is a block element, as well as div.
So I don' think
Currently MockWebApplication and WicketTester are derived from
WebApplication which requires us to copy paste code from
MyApplication to MyWicketTester which is kind of ugly. I changed
MockWebApplication to delegate to an application instead. It seems to
work fine but most xxxExpectedResult.html
if it does the same in the end. go ahead.
johan
On 11/6/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Currently MockWebApplication and WicketTester are derived from
WebApplication which requires us to copy paste code from
MyApplication to MyWicketTester which is kind of ugly. I changed
didnt someone already submit a patch that does this?
-igor
On 11/6/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Currently MockWebApplication and WicketTester are derived from
WebApplication which requires us to copy paste code from
MyApplication to MyWicketTester which is kind of ugly. I
Counter intuitive?
Then don't use it. We have lot of use cases for this, components that
need to be independent of whether parent contains form or not. No one
forces you to nest forms, so take this just as a possibility.
-Matej
Ryan Sonnek wrote:
My vote is to not allow for inner forms
Hi.
As you may have noticed, we have nested forms support in Wicket 2.0.
(Please, this is not about whether we should/should not support nested
forms, so don't discuss it in this thread).
The question is, what should happen with inner forms, when outer forms
are submitted.
a) Inner forms
I vote for C
Eelco
On 11/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Hi.
As you may have noticed, we have nested forms support in Wicket 2.0.
(Please, this is not about whether we should/should not support nested
forms, so don't discuss it in this thread).
The question is, what should
Frank Bille wrote:
I think for completeness we should have:
d) Throw a RuntimeException when nested forms are detected, because
it's not allowed in HTML.
No we shouldn't. If you want to discuss this, go ahead, but in a
different thread. :)
-Matej
But personally I vote for (C)
Frank
On
Maybe is off topic in this thread, but what about XForm in wicket?
http://ibm.com/developerworks/xml/library/x-xformstipmultipleforms/index.html?ca=drs-
Do plan to support it in future releases?
Bye
- Paolo
On 11/5/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
the idea of me was that the
That should be doable, but someone with enough knowledge of XForms,
and preferably someone who is actually going to use that should
implement it. Maybe you? ;)
Eelco
On 11/6/06, Paolo Di Tommaso [EMAIL PROTECTED] wrote:
Maybe is off topic in this thread, but what about XForm in wicket?
On 11/6/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
apache jira contains ~35 entries but as far as I can tell only new
ones. I tried sourceforge but the bug and rfe pages are no longer
accessible. Is that by purpose?
Yes, there is no way of disabling new additions to the sf.net bug
C with default value 'false' - default does not process inner form.
IMO a form in a panel is not *typically* designed for processing in an
outer form.
Take for instance:
Form outer = new Form(this, outer) {
protected void onSubmit() {
session.save(getModelObject());
}
}
Form
fwiw, in my time as a wicket dev/user i dont think ive ever overridden
form.onsubmit(), i always put that behavior into the button's onsubmit().
-igor
On 11/6/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
C with default value 'false' - default does not process inner form.
IMO a form in a
Typically I never have more than one button on a form that matters:
save. This is then the submit button (no wicket component), and the
cancel is just a link. So I've probably never implemented
button.onSubmit() other then for examples.
Martijn
On 11/6/06, Igor Vaynberg [EMAIL PROTECTED]
When going through the files to add/ignore license headers I came across
these two javascript files. The onestat.js I think is easy enough (ignore),
but what about wicket-ajax-debug-drag.js? It says something about CC license
but the content is clearly Wicket specific. Anyone having an idea of
well, and in our application we *mostly* uses the button.onsubmit but for a
search field we use the form.onsubmit.
Frank
On 11/6/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Typically I never have more than one button on a form that matters:
save. This is then the submit button (no wicket
Hi,
I know we've been here before, but that was a couple of months ago,
and opinions might have changed by now.
What are your ideas about the /immediate/ roadmap for Wicket 1.3? I'm
interested to learn what the first things will be that people will be
working on when we start 1.3, and/ or what
That was my personal roadmap :)
On 11/6/06, Frank Bille [EMAIL PROTECTED] wrote:
- Fix license header stuff
- Synchronize WicketTester with Juergens changes
- Backport some fixes
- (2.0 and 1.3) Take a look at WicketTester to get it consistent
with AJAX generated content.
Yeah, the license header stuff is not so much a wish as a must-have if
we want to incubate :).
On 11/6/06, Frank Bille [EMAIL PROTECTED] wrote:
- Fix license header stuff
- Synchronize WicketTester with Juergens changes
- Backport some fixes
- (2.0 and 1.3) Take a look at
On 11/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
* SecondLevelCacheSessionStore
* deferred sessions
* stateless components (forms, links, but basically what we have now in 2.0).
+1 on all, and add:
* nested forms
* validator changes
* IModel hierarchy improvements
* API clean up ([re]move
All,
The time has come to finalize 1.2 and start work on 1.3.
There will be a 1.2.4 release, but it will have low priority unless
warranted by a major discovery of a bug.
Is anyone currently busy with a bug that absolutely needs to get into
1.2.4? If so, please let me know before tuesday
Could someone please fix the compile errors in wicket-auth-roles
(trunk): 'The method getSecuritySettings() is undefined for the type
WicketTester'.
Cheers,
Eelco
24 matches
Mail list logo
