where is the code?
-igor
On 7/24/07, Francisco Diaz Trepat - gmail [EMAIL PROTECTED]
wrote:
Hi, igor, or someone:
I took the liberty in writing an extensible autocomplete behavior based on
the AutocompleteTextField by Janne (jannehietamaki).
I was supposed to open a JIRA but as I've
hrm
it is called beforecallcomponent(), if we do not actually call it then we
should prob not call the handlers either.
-igor
On 7/18/07, Johan Compagner [EMAIL PROTECTED] wrote:
the invoke method does this:
public final void invoke(final Page page, final Component component)
{
On 7/14/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I've created a ehcache based MarkupCache extension. On my laptop it is
currently in wicket-extension which due to ehcache requires a ehcache
dependency in pom.xml. I wonder whether wicket-extension realy is the
right place?
what are the
On 7/11/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 7/11/07, Gwyn Evans [EMAIL PROTECTED] wrote:
I did want to respond to Johan's comment, but it's /not/ a -1 vote,
especially in view of your reasons above - 0 if anything.
I didn't want to imply as such, but I would not hold a grudge if
On 7/10/07, Johan Compagner [EMAIL PROTECTED] wrote:
this should work, do you have a quickstart that demonstrates this?
ive noticed a few messages about this, but havent had time to look yet. it
looks like we do not properly merge query strings parameters into other
coding strategies. for
On 7/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 7/10/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Today I've committed the new Border to 1.3 trunk. I would appreciate
if you could do a quick check of your applications using Borders to
make sure everthing is working as expected.
On 7/9/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
That's the whole point: in the wrapModel, I store a key with which I can
retrieve the wrappedModel from a context. So the wrapModel only stores a
'transient' reference to the wrappedModel, and its detach() clears that
reference. Whenever asked
the new error reporting feature, that one that throws two exceptions per
component, is really making development not enjoyable. it slows down request
processing significantly and might give noobs the wrong impression. it is
valuable information for noobs, but imho after using wicket for a week
On 7/6/07, Al Maw [EMAIL PROTECTED] wrote:
The current default validation messages in Application.properties make
no logical sense.
At the moment, if you put in a value that is larger than a
NumberValidator maximum it says:
5 must be smaller than 3
Which it can't be, not even for very small
On 7/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
[x] disable this feature by default, put instructions on how to enable it
into component-not-found related exception messages
[ ] leave it enabled by default
-igor
On 7/5/07, Noel J. Bergman [EMAIL PROTECTED] wrote:
a/org/apache/commons/fileupload/
Sorry if this comes across as being snarky, but rewriting the wheel is bad
enough; getting it wrong is worse.
--- Noel
actually if you take a look you will see that our upload code does come from
On 7/5/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Vincent Demay:
I think it also avoid to write 40 code lines just to get the
component in the model.
I also find it utterly complicated. Is there a reason for this
that we are overlooking?
--
yes, there is. the interface
On 7/4/07, Al Maw [EMAIL PROTECTED] wrote:
Do we really need to go around and aggressively clean up these
InputStreams? Can't we do that in a finalize() method somewhere?
yes we do, because users dont do it themselves :) we can also add something
like
protected boolean closeStreamOnDetach()
On 6/30/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
WDYT?
archetypes under applications sounds a bit weird, but i can live with it.
+1
-igor
Martijn
--
Wicket joins the Apache Software Foundation as Apache Wicket
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6
[x] I have checked the distribution and +1 its release
-igor
+1
-igor
On 6/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
We are on 1.3.1 now but i see there is a 1.4.0
and i have to use it anyway in another project (thats also using wicket)
so i could also upgrade wicket to 1.4.0
johan
On 6/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
[x] I didn't check the distribution, but I want to release them regardless
(+0)
On 6/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
simplified how they are used a bit in 1.3, but imho, I think we should
just ditch them all together in favor of simply two factory methods in
application. Factory method
i dont feel strongly about it anymore. a lot of people seem to want to shoot
themselves in the foot, and i am inclined to let them.
-igor
On 6/24/07, Matej Knopp [EMAIL PROTECTED] wrote:
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup
and that all makes perfect sense, however at its current state the
requried/null checks are considered syntactic checks. if not then every
ivalidator out there must first perform the null check, which is annoying.
how about:
class ConstraintValidator extends ... implments IValidatorAddListener
yes, that makes sense. howevern, i still like ondestroy() better then
destroy(). ondestroy() makes it clear it is a listener.
-igor
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Actually there is also a protected internalDestroy (still not final
though) which calls destroy so why not
On 6/20/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
It works with the classloader of the current thread, so that's OK.
And yes, I was surprised to find a non-optional initialization like that
of
the PropertyResolver to be defined in an Initializer that might not always
be called.
erm.
actually
protected void internaldestroy() { ondestroy(); }
@deprecated - use ondestroy instead
final void destroy() {}
void ondestroy() {}
-igor
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote:
as in ?
protected void internalDestroy()
{
...
destroy();
...
}
public final void destroy()
the added code is there to guard validators against having to check for
null. if we remove it then the first thing all validators should do is check
if validatable.getvalue() is null - which gets annoying and causes NPEs if
you forget.
wicket has a facility for setting whether or not the
On 6/19/07, Al Maw [EMAIL PROTECTED] wrote:
As subject. See other thread for discussion.
[x] Yes, rename AjaxSubmitButton to AjaxButton, leaving behind a
@deprecated subclass for backwards-compatibility.
[ ] No, that's a crazy idea. We're frozen for 1.3.0 and this sort of
stuff
gah!
i thought i moved everything non-spring releated into extensions a long time
ago.
what did i leave behind?
-igor
On 6/19/07, Al Maw [EMAIL PROTECTED] wrote:
Hi folks,
The wicket-spring project currently has some generic injection and proxy
classes with no Spring dependencies.
If we
i would not be against making formcomponent.validate() non-final
-igor
On 6/19/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
That means you can never put 'required' logic in a validator. And that's
just
what we want to do, because that's the way we can integrate with the
Hibernate validators.
i dont know about that. isvalid's contract is that it only returns false if
there are error messages reported against the component.
i think this would be simple enough
class hibernatetextfield extends textfield {
valid() {
if (hibernaterequired()) {
if
or instead,
maybe make that hibernatevalidator also be a behavior, and simply toggle
component's setrequired in onattach
-igor
On 6/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont know about that. isvalid's contract is that it only returns false
if there are error messages reported
not to have to check if a value is null, but
we're paying a price for this that might be higher than the gain ?
Jan.
igor.vaynberg wrote:
or instead,
maybe make that hibernatevalidator also be a behavior, and simply toggle
component's setrequired in onattach
-igor
On 6/19/07, Igor Vaynberg
go for it
-igor
On 6/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
AbstractBehavior#isEnabled(Component component) currently returns true
by default. Wouldn't it be better if it was implemented like this?
public boolean isEnabled(Component component)
{
ah,
i did that in the old 2.0 branch.
dont know if we need a separate wicket-ioc which wont be very useful by
itself, we could just move that stuff into extensions.
-igor
On 6/19/07, Al Maw [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
gah!
i thought i moved everything non-spring
since everyone is talking about this can i add some more flames? why is Link
called link? cause really its not just a link.
you can do:
add(new Link(foo) {});
and in markup have
a wicket:id=foo/a
input type=button wicket:id=foo/
button wicket:id=foo/
so its not just a link.
-igor
On
why would you want to do that? that is there only to detect run away loops.
-igor
On 6/18/07, Sean Sullivan [EMAIL PROTECTED] wrote:
In RequestCycle.java, the steps() method has this code:
* final* *int* maxSteps = Short.MAX_VALUE;
Is there any way for me to override the maxSteps value?
fine by me
-igor
On 6/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
max int is actually a pretty rediculous default in itself. How about
setting it to 1,000 or even 100 or such?
Eelco
On 6/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Why would you want to do that? Sure, we can put a
done and done
-igor
On 6/16/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Igor, Could you create projects for wasp and swarm too, i seem to be a
regular user on jira.
Thanks,
Maurice
On 6/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
done
-igor
On 6/15/07, Martin Funk [EMAIL
done
-igor
On 6/15/07, Martin Funk [EMAIL PROTECTED] wrote:
How do I create a project Wicket Contrib GMap2 on wicketstuffs jira.
I do see a Create New Issue link but the Create New Project links
seems to be hiding.
People ought to have a proper place to blame about it:-)
Martin
welcome
-igor
On 6/11/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Dear developers,
Please welcome Grégory Maes among the WicketStuff developers.
Grégory has filed [1]several patches on WicketStuff Dojo, and has
shown a long-term interest in this project. He now deserves to
afir, jetty has their own servlet api jar if that helps.
-igor
On 6/10/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
After Noel (rightfully) wagged his finger for our beta 2 release, I
have been going through our notice and license files.
- spring was not in a notice file, but we do
whats wrong with 2.4? it is java 1.4.
-igor
On 6/10/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
But that is servlet api 2.4 or 2.5, not 2.3...
Martijn
On 6/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
afir, jetty has their own servlet api jar if that helps.
-igor
On 6/10/07
havent checked out the projects yet, but you already get the props just for
the acronyms :)
-igor
On 5/21/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Hi, all
With the help of Martijn i added 2 new projects to wicket-stuff under
the name of wicket-security-wasp and wicket-security-swarm.
I
you need to use some trickery when adding/removing columns if you want this
thing to work in a form. see my recent change to datatable or one of its
parents where i changed refreshingview used to render columns to
repeatingview to make it work right in forms.
-igor
On 5/20/07, Martijn Dashorst
so why is it onadded() here and bind() in ibehavior?
-igor
On 5/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I guess sitting back is not my strongest point :)
I just committed a variant of Al's idea:
/**
* Optional interface for validators ([EMAIL PROTECTED] IValidator} and
* [EMAIL
huh?
-igor
On 5/11/07, Bruno Borges [EMAIL PROTECTED] wrote:
To follow with onAttach/onDetach (I don't remember if these has -ed)
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
so why
actually another advantage of doing this, as far as hibernate validator
stuff goes, is that because it is a behavior and validator in one the
validator can get access to the component it is attached to via
behavior.bind().
-igor
On 5/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hrm. after
:
On 5/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
actually another advantage of doing this, as far as hibernate validator
stuff goes, is that because it is a behavior and validator in one the
validator can get access to the component it is attached to via
behavior.bind().
Not really
On 5/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
This is (of course) the first solution I worked on, and in fact the
solution I preferred up to yesterday (and maybe still prefer, not
sure). It needed some API changes though, as currently you can't have
a class that implements both
to do that funny cast)
yes. this is the only con i see. like i said maybe we add a convineience
addvalidator(ivalidator) that will avoid the cast.
-igor
johan
On 5/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 5/10/07, Johan Compagner [EMAIL PROTECTED] wrote:
and i don't like
On 5/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 5/10/07, Johan Compagner [EMAIL PROTECTED] wrote:
i find that class extremely ugly
IValidator is a pretty simple interface but IBehavior not.
And what does that solve? nothing i don't find it any cleaner
can you remove behaviors
On 5/10/07, Johan Compagner [EMAIL PROTECTED] wrote:
can you remove behaviors that validator has added? when your remove a
validator how will you know which behaviors were linked?
see my previous mail (i aksed the same thing to eelco)
just don't add the behavior to the behaviors
just in
no. dont forget that the idea of IValidator is to be decoupled from wicket,
to allow the reuse of validators in service layer. i do that all the time
now and it rocks! my service layer and my ui layer are validated by the same
code. adding ivalidator.getbehavior() will break all that nice
:
Is this decoupling ( example of multiple use) concept expressed in the
javadocs? I didn't see it on the 1.2.6 documentation. Would be good to
capture it, maybe on the class documentation on IValidator and/or its
package javadoc.
Jon
On 5/9/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
no. dont forget
than a coincidence.
Jon
On 5/9/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
this change is only in 1.3. as far as documentation i dont know, its
pretty
obvious from the code. wicket.validator package doesnt have dependencies
on
any other package in wicket. maybe someday it will be its own
where is your sf.net id?
-igor
On 5/9/07, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]
wrote:
want to be able to commit to the gmap contrib...
what will people think??? :)
http://papernapkin.org/pastebin/view/5915
-igor
On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jcompagner
Date: Tue May 8 07:44:07 2007
New Revision: 536209
URL: http://svn.apache.org/viewvc?view=revrev=536209
Log:
stupid stupid stupid
as far as i can see eelco is complaining because he is doing that and no one
is following! :)
-igor
On 5/7/07, Johan Compagner [EMAIL PROTECTED] wrote:
we dont need to fix the world.
but nobody should or would stop you if you did!
the world needs saving! Igor start doing this maybe the
http://people.apache.org/dist/incubator/wicket/apache-wicket-1.3.0-incubating-beta1/m2-repo/org/apache/wicket/wicket/1.3.0-incubating-beta1/wicket-1.3.0-incubating-beta1-javadoc.jar
for wicket, other modules in adjoining dirs
-igor
On 5/7/07, Sean Sullivan [EMAIL PROTECTED] wrote:
I
you _maintain_ them as far as keeping api with wicket in sync. but do you
actively develop them? do they provide any value in their current state? are
they up to the latest hibernate version?
imho those projects never got finished, not even close.
-igor
On 5/6/07, Eelco Hillenius [EMAIL
well, yes it does matter. there is a difference between a project and a
bunch of compiling code. for example that project will break if anyone tries
to use it with hibernate 3.2 because it hasnt been updated to their switch
of aggregate return types form int to long. who knows what else is
i love the fact that wicketstuff is both a playground (very little entry
barrier for anyone) and that it serves as a repository for additional wicket
modules. the problem is when i look into trunk i see ten thousand projects.
some are dead, some are half dead, and others are alive. how am i
i do not use the project. i do not have time, nor honestly the desire, to
fix every wicketstuff project i do not use. do you find that unfair? as for
it being fixed on a version, do you think anyone would bump down their
hibernate version just for an auxilary project? i think not. maybe no one
well, thats exactly it - very little is required to do this, just an svn
move. we should establish procedures/guidelines for what it takes to move
from tier 2 to tier 1 and viceversa, and where new projects start out.
-igor
On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
i think what we
On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
However, that does impose some form of oversight, and given the
current state of Wicket Stuff, I doubt that it will ever happen, if it
doesn't come from us.
Exactly.
i dont think you got it right eelco. oversight!=maintenance. if we
will that really make things better? if you misname the markup file you will
now get component not found rather then markup not found.
-igor
On 5/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
How about giving Panel.java an accompanying Panel.html file? That
would obviate the need of adding
[X] Yes, propose Wicket for Graduation
-igor
so is it a firstattach if you remove a component and then readd it at a
later time?
-igor
On 5/4/07, Jonathan Locke [EMAIL PROTECTED] wrote:
Although I do still think we should generally discourage two-phase
construction, it is occasionally truly necessary and it seems like it
might
be nice
well i dont know
if you need second-phase-init then you are likely doing something that is
context-sensitive because this context is the only thing you are missing
in the constructor really.
so when you move things around the context changes, so should the component
reinit itself?
-igor
On
.
best,
jim
On 5/4/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
so is it a firstattach if you remove a component and then readd it at
a
later time?
-igor
On 5/4/07, Jonathan Locke [EMAIL PROTECTED] wrote:
Although I do still think we should generally discourage two-phase
wicket uses callback methods instead of listeners for a simple reason: it is
a smaller memory footprint - there is no list to store, no listener
implementations to serialize. it is further my experience that you very very
rarely need more then one listener, so it cannot justify the overhead imho.
will we also have isFirstBeforeRender and isFirstBeforeRenderAfterAdd? since
in onattach you cannot modify component hierarchy anymore, and you shouldnt
really be attaching models in onbeforerender.
-igor
On 5/4/07, Jonathan Locke [EMAIL PROTECTED] wrote:
right.
well, if the component
open a jira issue please.
-igor
On 5/2/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
I'm trying to port our application code from the former Wicket 2.0 to the
current trunk, and came across another difference between the two
versions:
* in 2.0, HeaderContainer:renderHeaderSections() delegates
i also see MarkupParser.appendMarkupFilter @ MarkupParser:167
-igor
On 5/2/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Sorry, I did miss something: there are constructors for
MarkupParserFactory
that accept one or more filters. Forget my request.
Jan.
--
View this message in context:
On 5/1/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
protected Object convertValue(String[] value) {
// we can ignore passed in value, but what we do instead is create an
object based on child components
LocalTime time=(LocalTime)timepicker.getconvertedinput();
DateTime
so far there havent been any bug reports against the latest, so who knows :)
-igor
On 4/30/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I have spent quite some time issuing the 1.2.6 release. The main
difference between our 1.2.x branch and trunk is that the quality of
the poms in 1.2.x is
this is already possible, and is very elegant!
all you have to do is something like this
protected Object convertValue(String[] value) {
// we can ignore passed in value, but what we do instead is create an
object based on child components
LocalTime
this will get better in the next version when we can break an api and pass
around a javascript object instead of strings.
-igor
On 4/27/07, Julian Klappenbach [EMAIL PROTECTED] wrote:
The following was gathered from a particular implementation using
AjaxFormSubmitBehavior
var
imho it can wait until the next version.
+0
-igor
On 4/27/07, Frank Bille [EMAIL PROTECTED] wrote:
+1 on that. And use EnumeratedType instead, so we can say
public AjaxEventBehavoir(ClientEvent event)
Frank
On 4/27/07, Timo Rantalaiho [EMAIL PROTECTED] wrote:
On Wed, 25 Apr 2007, Johan
On 4/27/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Like for example RefreshingView using an IDataProvider...
say what now?
-igor
not only is the name of this method horribly jacked up, but it doesnt appear
to be called from anywhere?
can we remove it?
-igor
On 4/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Bug WICKET-4 Page.onBeginRequest() [and consequently
.onAttach()] not called when form on page is submitted
this is that oanttach refactor johan is working on.
-igor
i dont see why we are having this discussion now. we are on jdk1.4 so this
is a moot point. lets have this discussion once we move to jdk1.5.
-igor
On 4/26/07, Johan Compagner [EMAIL PROTECTED] wrote:
no getModel() should always just work. It should return the model of the
component
also
+1 to apply it
-igor
On 4/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/26/07, Johan Compagner [EMAIL PROTECTED] wrote:
thx
i guess nobody is against this ?
Then we'd hear from them already in this thread again.
(we already had a vote for this for 2.0 and we agreed that it was
why would our opinion matter? you are free to start a wicket-stuff project
to integrate whatever you want :)
-igor
On 4/25/07, Xavier Hanin [EMAIL PROTECTED] wrote:
On 4/25/07, Bruno Borges [EMAIL PROTECTED] wrote:
Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
it'll
i am planning on backporting ialternateparentprovider still. of course if
you want to beat me to it with a patch you are most welcome.
-igor
On 4/25/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
I am now porting our code, and already came across a number of issues:
* no longer support for
so its foo, bar, kazam. interesting.
-igor
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I think that blatant errors can be fixed by anyone with write access.
In this particular case it should not lead to discussion :)
Complete rewrites of functionalities is something that should be
jdk1.4 doesnt have covariant return types anyways. when we move to jdk
1.5you can bring this up again :)
-igor
On 4/25/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
typecast? in 2.0 you didn't have to cast when using the model or
getModelObject()
where did you need
naah, we share this list with wicket-stuff. makes it easier.
-igor
On 4/25/07, Xavier Hanin [EMAIL PROTECTED] wrote:
On 4/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
why would our opinion matter? you are free to start a wicket-stuff
project
to integrate whatever you want :)
Agreed
i thought we have the three required votes for it to pass
yours, bertrand's, and frank's
so as long as no one votes -1 we are set no?
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have 12 PPMC members and 4 mentors. Until now we have had 1 vote
from a PPMC member and one from a
lookup for ids, if wicket:id is not there.
On 4/24/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
there are a lot of reasons for this. the few that come to mind are:
designers want control over the id attribute for css styling
wicket:id allows duplicates in markup while id doesnt, so
can you please make it into a jira issue so it doesnt get lost?
-igor
On 4/24/07, Iulian Costan [EMAIL PROTECTED] wrote:
hi,
i suppose the id of a script tag added in a ajax response should be
preserved, if so then here is the patch. i've created the patch from
1.2codebase but the issue
its that huge picture of the cat you have in your blog header. sometimes i
just sit there and shift-refresh your blog.
-igor
On 4/24/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/24/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
So now we're waiting what will happen with Wicket 1.4 (or
we should just change our formprocessing traversals to postorder
-igor
On 4/24/07, Johan Compagner [EMAIL PROTECTED] wrote:
i think it is because you have a panel that is a FormComponent by itself
it has 3 textfields and those 3 text fields combines to one thing
Then the panel can implement
that
encapsulates multiple form components, by the time it is processed so are
all its children.
-igor
On 4/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 4/24/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
we should just change our formprocessing traversals to postorder
Yeah, still absolutely +1
html also doesnt allow nested forms :)
on our abstraction level validating a compound form component makes perfect
sense. if it wants to be opaque why can it not?
why shouldnt you be able to do
add(new TimePicker(...).add(new DateBeforeValidator(...)))?
-igor
On 4/24/07, Eelco Hillenius
there are a lot of reasons for this. the few that come to mind are:
designers want control over the id attribute for css styling
wicket:id allows duplicates in markup while id doesnt, so validation would
fail.
link wicket:id=aspan wicket:id=a/span/a is allowed.
it is cleaner to use our own
makes sense to me. ive used PackagedTextTemplate on more then few occasions.
-igor
On 4/22/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'm +1.
Eelco
On 4/21/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Dear developers,
What about moving the very useful TextTemplate to core?
i think we can certainly give it a try.
these messages are not stored across requests so there is no impact of
storing each component's messages in its metadata session-size wise. the
reason we didnt do it is because we didnt want to dedicate yet anoter slot
to an array - thats why it was
it isnt too expensive if you store it in the metadata. i think this was all
discussed before we had metadata support.
-igor
On 4/21/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Can there now never be hanging feedback messages?
IF a component didn't have a page anymore (removed by listview
On 4/20/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Which one of these 4 issues is a security issue?
And those issues are not Fixed:
if you read carefully you will see that martijn was listing those as open
issues, not as the changelog.
-igor
On 4/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/20/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
looks fine to me
Notice I didn't label a release General Available :)
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
1 - 100 of 532 matches
Mail list logo
