You can use the component.hasBeenRendererd() method to determine if it
is the first time or not.
-Matej
On 7/24/07, Carlos Pita [EMAIL PROTECTED] wrote:
Erm, how would you implement that?
I'm overriding onAttach and setting a flag for doing initialization
just during the first attachment.
You need to call session.bind().
We've been discussing this many times. It's no good to make
session.dirty() bind the session, because it's called internally even
on sessions that should not be bound.
-Matej
On 7/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 7/24/07, spencer.c [EMAIL
On 7/24/07, spencer.c [EMAIL PROTECTED] wrote:
Thanks Eelco, that did the trick.
Couple of follow up questions/comments that anyone can field:
1) I understand why you would want a stateless application, however I don't
understand why you would ever want your session to be regenerated on each
There is more of it in the archives, this one might be most relevant
http://www.nabble.com/Magic-to-replace-ModalWindow-images-tf3811156.html#a10788038
-Matej
On 7/24/07, NateBot2000 [EMAIL PROTECTED] wrote:
NateBot20002 wrote:
Can you explain how the image resources in the ModalWindow
Are you sure the form validates right?
-Matej
On 7/23/07, carbonbasednerd [EMAIL PROTECTED] wrote:
In my parent page I create a ModalWindow which has ajaxsubmitbuttons and
works just fine. Within that modal window I have a link which will take the
user to another page within the same
Problem is that we evict it also on refresh. But then you still can go
to the page B. Anyway, there are more problems then this with
HttpSessionStore. I think that upgrade to 1.3 is really recommended,
as the default SecondLevelCacheSessionStore doesn't suffer from this
problem any more.
-Matej
To filter header contribution in wicket there you can set the id
attribute of the script. Otherwise it will be filtered by URL. So if
you have the contribution twice with same javascript url, it will be
filtered.
-Matej
On 7/19/07, James McLaughlin [EMAIL PROTECTED] wrote:
The injecting flag
and wicket-contrib-yui use
it to load script.
thx,
jim
On 7/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
To filter header contribution in wicket there you can set the id
attribute of the script. Otherwise it will be filtered by URL. So if
you have the contribution twice with same javascript url
Five modal windows? At the same time? It might be that you are running
out of pagemaps.
This is very weird, hovewer, seems to be reproducable. Can you post a
quickstart? Also, could you check if this is working with wicket 1.3?
-Matej
On 7/18/07, Laurent Brucher [EMAIL PROTECTED] wrote:
You can't. Java property files are always encoded in ISO-8859-1. In
order to use other characters you need to escape them properly. There
is an encoder/decoder for it and/or eclipse plugin.
-Matej
On 7/19/07, wheleph [EMAIL PROTECTED] wrote:
Hi everyone!
I've got the following problem.
My
AjaxRequestTarget target;
target.addComponent(item);
where item is a repeater Item.
This doesn't work for you? What wicket version are you using?
-Matej
On 7/19/07, ChuckDeal [EMAIL PROTECTED] wrote:
ptrthomas wrote:
How about this thread:
What wicket version are you using?
-Matej
On 7/18/07, Alex Objelean [EMAIL PROTECTED] wrote:
I have a strange issue when using ModalWindow in my application. Sometimes
(randomly), I got the following error in ajax-debug window:
[MESSAGE]
INFO: Response parsed. Now invoking steps...
I built a page store using ehcache but it didn't really give any
benefit, was actually slower that what we have now.
-Matej
On 7/16/07, Johan Compagner [EMAIL PROTECTED] wrote:
secondlevelcache doesn't cache anything anymore. (except caching it on disk)
So ehcache cant really be used there.
Okay, I missed this conversation a bit so let me explain current state
of wicket and clustering:
With SecondLevelCacheSessionStore only last accessed page per pagemap
is stored in http session (not directly as attribute, but as a
property of pagemap object, which is a session attribute).
With
I think it is wrong. Why would we set the pagemaps as attributes in
the session when using the second level cache page map? The whole idea
of storing in the session of page maps was clustering, and that works
for HttpSessionStore. But it doesn't make sense for SLCSS and
variants.
Because
[
https://issues.apache.org/jira/browse/WICKET-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512802
]
Matej Knopp commented on WICKET-758:
I could live with that. Optionally, you can put the method to determine
[
https://issues.apache.org/jira/browse/WICKET-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512807
]
Matej Knopp commented on WICKET-640:
Should be fixed, can anyone test it?
modal window close button does
[
https://issues.apache.org/jira/browse/WICKET-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-736:
--
Assignee: Matej Knopp
Improve PageStore
-
Key: WICKET-736
[
https://issues.apache.org/jira/browse/WICKET-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp updated WICKET-736:
---
Description:
* create AbstractFileStore which contains the (de)serialization logic
* create
Add metadata to RequestCycle
Key: WICKET-759
URL: https://issues.apache.org/jira/browse/WICKET-759
Project: Wicket
Issue Type: Improvement
Components: wicket
Reporter: Matej Knopp
[
https://issues.apache.org/jira/browse/WICKET-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-759.
Resolution: Fixed
Add metadata to RequestCycle
Well, it's very new and not very tested. Therefore it's
experimental. It might work well but there might also be issues. It
would help a lot if you tried using it and if you come across any
problems let me know.
-Matej
On 7/12/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Matej Knopp-2 wrote
Btw, I've tried the test you provided with both FilePageStore and
DiskPageStore. It failed with FilePageStore but passed with
DiskPageStore.
-Matej
On 7/11/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
As a consequence of 'random' errors in a single-page application using
Wicket, that always
It's probably a bug (or intended behavior) if IE. Wicket can't really
control the http request the browser makes to get the .htc file.
-Matej
On 7/11/07, rc.china [EMAIL PROTECTED] wrote:
I have do some further tests. This is the content of my original CSS file:
body {background: #EEE; color:
No it does not. When you click the second window's close button, it
tells you to close the window with the link inside window instead.
That's intentional and demonstrates that you can suppress the action
on close button.
Your problem is that you have modal window with panel inside modal
window
Improve PageStore
-
Key: WICKET-736
URL: https://issues.apache.org/jira/browse/WICKET-736
Project: Wicket
Issue Type: Improvement
Components: wicket
Reporter: Matej Knopp
Fix For: 1.3.0
This is a known bug in the Tree class. To get around it you need to
use LabelTree (or LinkTree) from wicket 1.3.
-Matej
On 7/9/07, kenixwong [EMAIL PROTECTED] wrote:
Hi,
i had build a tree explore and also given each node with the name (
displayed in the screen) . But then some of the word
This is hardly a wicket fault. It's a html/css problem.
-Matej
On 7/9/07, westpine [EMAIL PROTECTED] wrote:
Hi... I use iframe on my page
iframe width=100% height=100% wicket:id=content src=[actual url goes
here]/
Like this. In IE and Opera everything is OK. But in FF this iframe just
I think it should get in.
-Matej
On 7/8/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
In order to fix wicket-695, I once again looked at Border. Today it is
a single component and basically via different states it tries to find
the relevant markup and components. This is a little bit hairy
I'm a strong -1 on removing access to private fields. This wouldn't
really change anything. When someone wants to access private fields,
he/she will do that, with or without PropertyModel.
-Matej
On 7/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
We could do the restriction, but then the question will be how
predicable and confusing this behavior will be.
-Matej
On 7/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
I've never said saving typing is always bad. As I said in another post,
Eclipse run will not run the program in debug mode. Thus you have no
reloading at all. To have at least basic jvm reloading (when the class
shape doesn't change), you must debug you application in eclipse.
-Matej
On 7/7/07, ZedroS Schwart [EMAIL PROTECTED] wrote:
Hi
Just a small question :
Perhaps you are looking for IComponentAssignedModel ?
-Matej
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
Unfortunately, there is no control of the opacity. The problem is that
for certain browsers, the opacity attribute doesn't work well and we
need to use a masking transparent picture.
-Matej
On 7/4/07, Sean Sullivan [EMAIL PROTECTED] wrote:
Hello,
I am using a Wicket 1.3.0 SNAPSHOT from the
I believe, that what you want, is not to set response page, but rather
to switch panel components. At least that sounds much more reasonable
to me.
-Matej
On 7/4/07, kenixwong [EMAIL PROTECTED] wrote:
the reason i using the tree is my menu will be cover a lot of reports ( i m
develop the
Hi Matt, as far as I know there are no strict rules.
Basically, if the position involves Wicket, nobody objects against such posts.
-Matej
On 7/3/07, Watter [EMAIL PROTECTED] wrote:
Are there any rules about a company posting to this list about potential open
positions around Wicket?
Matt
You're welcome :)
-Matej
On 7/3/07, Nathan Beach [EMAIL PROTECTED] wrote:
With some simple changes to ModalWindow, I'm able to get the basics to
work (see attached gif). Just turned off the masking, added x and
yOffsets, and altered the loadPosition function to take settings
parameters
a page should definitely not be serialized twice per request, i'll
look at it right now.
as for (2), it is necessary to serialize page after every request.
Version manager can track soem changes, but not all of them (consider
simple counter examples that does count++ - version manager is not
Hi,
indeed, (2) was a bug and it should be fixed now. Thanks for spotting it.
-Matej
On 6/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
a page should definitely not be serialized twice per request, i'll
look at it right now.
as for (2), it is necessary to serialize page after every request
What we should have is some kind of listener. Which you could use to
easily plugin your own behavior (even dumpThreads if you want). I
wated to do this some time ago, but then we stopped getting those
exception so i let it be.
-Matej
On 6/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
its a
It is possible what you have one page instance/version opened in three
tabs. How does the link you are clicking on when creating new tabs
look like?
-Matej
On 6/29/07, Francisco Diaz Trepat - gmail
[EMAIL PROTECTED] wrote:
1.3 incubator beta and currently STILL drooling for the beta 2.
I'll
if you use sessionstore then you need to turn on that setting i told you
about.
-igor
thanks,
f(t)
On 6/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
It is possible what you have one page instance/version opened in three
tabs. How does the link you
(servletRequest, servletResponse);
}
However it does not seem to add the header? Hoping you can tell what
wrong? Log tells me that the filter does get activated and adds to
header.. But on the web page firebug does not report that the header are
there...
regards Nino
Matej
huh, if you have a in your markup, then i wouldn't be surprised if
things didn't work as expected. You should try to replace a panel with
panel, possible attached to div
-Matej
On 6/28/07, Evan Chooly [EMAIL PROTECTED] wrote:
On 6/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi, there was a significant change to ajax requests after beta1, so
please test this when beta 2 is out. If the problem persists, we will
certainly look into it.
-Matej
On 6/28/07, Chris Lintz [EMAIL PROTECTED] wrote:
Hi all,
I am hoping there is a work around or at least a known issue by
.. ?
Matej Knopp-2 wrote:
The problem is that when setResponsePage() is called, no appended
Javascript is evaluated. In fact, wicket doesn't process the ajax
response at all. Just sets window.location.
-Matej
On 5/9/07, dukejansen [EMAIL PROTECTED] wrote:
Yeah, but I don't want
That wouldn't work, it would break Ajax header contribution filtering.
-Matej
On 6/28/07, Jan Kriesten [EMAIL PROTECTED] wrote:
hi,
i've come across the problem that many components add special css-files and
that those headercontributions cummulate to a certain amount of lines with
link
I think we could make this by default in wicket. Until then, you can
make a filter, that checks if the request contains wicket-ajax header,
and when it does, add the cache-control no-store header.
-Matej
On 6/27/07, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi
We are
You need to use more recent version. Wicket 1.2.2 is really ancient.
Also after upgrade, don't forget to clean browser cache.
-Matej
On 6/26/07, Nili Adoram [EMAIL PROTECTED] wrote:
Hi all,
I am working with wicket-1.2.2.
I included datepicker calendar.js twice in the same page, and the
Btw, next time, you don't need to post 1000 lines of
setFullYear(2007)calendar.js (line 1796)
:)
-Matej
On 6/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
You need to use more recent version. Wicket 1.2.2 is really ancient.
Also after upgrade, don't forget to clean browser cache.
-Matej
On 6
I believe even i 1.2.6 isn't binary compatible (there might be some
very small minor changes that slipped in by accident), it's still
should be almost drop-in replacement, and the upgrade should be rather
painless.
Wicket 1.2.2 is from august 2006, that's almost a year ago.
-Matej
On 6/26/07,
compatibility... Are
you saying those were for nothing?
/me crawls back in cave
Martijn
On 6/27/07, Matej Knopp [EMAIL PROTECTED] wrote:
I believe even i 1.2.6 isn't binary compatible (there might be some
very small minor changes that slipped in by accident), it's still
should be almost drop
I think reasonable behavior would be to generate markup id when
invoked from constructor (instead of failing getting one from markup).
However, I'm affraid the complications you have are caused by the fact
the the component hasn't been rendered already, so it doesn't know
it's markup position. At
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup id specified in template. The
reason is that it's not unique and it behaves wrongly in repeaters or
when you put the component to page twice.
I'd actually prefer wicket to preserve specified
You can create the DOM element using custom javascript (it's very
simple, basic DOM manipulation) invoked from
ajaxRequestTarget.prependJavascript(). Be sure that the id attribute
of new DOM element is same as new list item id.
Then just render the newly created item (target.addComponent) which
().add(contrib)
}
lets discuss the pros and cons of all alternatives in order to find
the best solution for Wicket and all its users.
Juergen
On 6/24/07, Matej Knopp [EMAIL PROTECTED] wrote:
Arrgh. Discard my previous reply. This is wrong. Why shouldn't I be
able to do header
There's nothing javascript heavy on this :)
You add new item like this:
String id = rv.newChildId();
Item item = rv.newItem(id, index, model);
rv.populateItem(item);
rv.add(item);
(where rv is the refreshing view. Some of the methods might be
protected, so you will need to subclass the view, but
As far as I know id is a property of DOMElement, so there should be no
need to call setAttribute.
-Matej
On 6/24/07, Peter Thomas [EMAIL PROTECTED] wrote:
On 6/24/07, Peter Thomas [EMAIL PROTECTED] wrote:
On 6/24/07, Matej Knopp [EMAIL PROTECTED] wrote:
There's nothing javascript heavy
Hi,
I noticed that you get the field like this:
String fieldName = propertyModel.getPropertyExpression();
Class type = propertyModel.getTarget().getClass();
...
Field field = type.getDeclaredField(fieldName);
...
That means that the lookup is done on every configuration. Also will
this work for
Allow validators to process null value
--
Key: WICKET-686
URL: https://issues.apache.org/jira/browse/WICKET-686
Project: Wicket
Issue Type: Bug
Components: wicket
Reporter: Matej
[
https://issues.apache.org/jira/browse/WICKET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-686:
--
Assignee: Matej Knopp
Allow validators to process null value
Err, I believe that you can do add(HeaderContributor.forCss(...)) in
page constructor.
-Matej
On 6/23/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Jan,
the problem is that though you can attach attribute modifier (that is
what HeaderContributor is as well) to a Page (or WebPage), it'll
.
Matej Knopp-2 wrote:
Err, I believe that you can do add(HeaderContributor.forCss(...)) in
page constructor.
-Matej
On 6/23/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Jan,
the problem is that though you can attach attribute modifier (that is
what HeaderContributor is as well
Modifying the tag (onComponentTag) and rendering header contribution
(renderHead) are two different thing. While onComponentTag on a
behavior attached to page won't work (for reasons as you stated),
there is no reason why renderHead shouldn't work as well.
-Matej
On 6/23/07, Juergen Donnerstag
Arrgh. Discard my previous reply. This is wrong. Why shouldn't I be
able to do header contribution on behavior attached to a page? This
doesn't make sense!
I know onComponentTag doesn't make sense, but that's IMHO not valid
reason to forbid header contribution as well.
-Matej
On 6/24/07,
Two weeks? No, we started doing that on apache con :)
-Matej
On 6/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 6/23/07, Johan Compagner [EMAIL PROTECTED] wrote:
no, also normal serialization.
1 page instance (id/version) is never saved in more then 1 file
Oh. See, I go on vacation
I also think this would be a good solution.
-Matej
On 6/24/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 6/23/07, Matej Knopp [EMAIL PROTECTED] wrote:
Modifying the tag (onComponentTag) and rendering header contribution
(renderHead) are two different thing. While onComponentTag
[
https://issues.apache.org/jira/browse/WICKET-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507463
]
Matej Knopp commented on WICKET-683:
I believe this actually a feature of AccessStackPageMap. We've talked about
[
https://issues.apache.org/jira/browse/WICKET-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-683:
--
Assignee: Johan Compagner
It's your baby, deal with it ;-))
Fast multiple clicks cause page
All you need to do is override newNodeLink imho. Also to change row
background color you'll need to tweak the styles and add attribute
modifier inside populateItem, it's not really trivial, but it's not a
rocket science as well.
Simple alternateive in 1.3 would be to call setEnabled(false) on the
What wicket version are you using? Nested forms are only supported in
1.3. If you are using modal window with 1.2, the only reliable way to
use forms is putting a page inside modal window.
-Matej
On 6/22/07, Frank Bille [EMAIL PROTECTED] wrote:
On 6/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
That's weird. You should be able to call setRequired from that
listener, that's the point why i have introduced it!
-Matej
On 6/22/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
I'm *still* trying to find a way to modify a component *when the model is
bound*. The new
Weird, wicket-ajax works for me well in IE6.
-Matej
On 6/17/07, Thies Edeling [EMAIL PROTECTED] wrote:
AjaxLink works in FF2 and IE7, however in IE6 I get a Page Expired
immediately. I saw some previous threads about the jsessionid not set
but I doubt this is the same problem as it works in
You need to use AjaxSubmitButton inside the modal window. And to
refresh the parent window you need to add WindowClosedCallback to it,
just like in the wicket-examples.
-Matej
On 6/14/07, Nili Adoram [EMAIL PROTECTED] wrote:
add AjaxSubmitButton to the form embedded inside the modal window:
Hi, I've fixed this for 1.3.
As a workaround for 1.2, this is what you can do:
Don't update the script tag directly, but enclose it in a div, like this:
div wicket:id=script
span style=display:noneThis is an invisible tag to prevent buggy
IE ignoring the script
script
What wicket version are you using?
-Matej
On 6/14/07, Seldon, Richard [EMAIL PROTECTED] wrote:
Experiencing a wicket problem to do with UI state corruption when using ajax
tabbed panel. When the ajax links are rapidly clicked in succession various
validation errors appear relating to panels
On 6/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Actually the dirty bit is only relevant when you use session replication
using a 'standard' clustering technology (e.g. like Tomcat provides). If
the dirty bit is set, Wicket will explicitly set an attribute on the
session, which will
[
https://issues.apache.org/jira/browse/WICKET-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-192.
Resolution: Won't Fix
There's a new tree, in which you can make your own node panel with icons
[
https://issues.apache.org/jira/browse/WICKET-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503373
]
Matej Knopp commented on WICKET-536:
I can't reproduce it. Does it also happen with the modal window from
[
https://issues.apache.org/jira/browse/WICKET-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503376
]
Matej Knopp commented on WICKET-589:
I tried to reproduce it but i couldn't. Can you please confirm
[
https://issues.apache.org/jira/browse/WICKET-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-394.
Resolution: Fixed
Fix Version/s: 1.3.0-beta3
I've applied sligthly modified version
[
https://issues.apache.org/jira/browse/WICKET-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-139.
Resolution: Fixed
DefaultTreeState allowSelectMultiple == false not evaluated when selecting
[
https://issues.apache.org/jira/browse/WICKET-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp updated WICKET-139:
---
Fix Version/s: 1.3.0-beta3
DefaultTreeState allowSelectMultiple == false not evaluated when
Can you please test it with latest wicket 1.3? There was a bug that
prevented IE7 from processing ajax requests properly, it might be
related.
-Matej
On 6/11/07, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Yes i'll try to explain in greater detail.
Looks like it was not the
of upgrading the gmap contrib
to 1.3.
regards Nino
Matej Knopp wrote:
Can you please test it with latest wicket 1.3? There was a bug that
prevented IE7 from processing ajax requests properly, it might be
related.
-Matej
On 6/11/07, Nino Saturnino Martinez Vazquez Wael
we are in the process of upgrading the gmap contrib
to 1.3.
regards Nino
Matej Knopp wrote:
Can you please test it with latest wicket 1.3? There was a bug that
prevented IE7 from processing ajax requests properly, it might be
related.
-Matej
On 6/11/07, Nino Saturnino
[
https://issues.apache.org/jira/browse/WICKET-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-583:
--
Assignee: Matej Knopp (was: Eelco Hillenius)
Header Contribution in ModalWindow doesn't work
[
https://issues.apache.org/jira/browse/WICKET-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-583.
Resolution: Fixed
Header Contribution in ModalWindow doesn't work properly
[
https://issues.apache.org/jira/browse/WICKET-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503215
]
Matej Knopp commented on WICKET-572:
Works for me. Can you submit a testcase?
replacing tr using ajax does
[
https://issues.apache.org/jira/browse/WICKET-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503232
]
Matej Knopp commented on WICKET-604:
Well, there are two things I'd like to know.
a) How do you pause
Tree components cleanup
---
Key: WICKET-633
URL: https://issues.apache.org/jira/browse/WICKET-633
Project: Wicket
Issue Type: Improvement
Reporter: Matej Knopp
Assignee: Matej Knopp
I think your problem is that the pages are evicted from pagemap.
You'll need to specify different pagemap name for each modal window
component (ModalWindow.setPageMapName). Also you might need to
increase total number of pagemap
(Application.getSessionSettings().setMaxPageMaps()).
-Matej
On
Hi folks,
I hope this e-mail won't upset anyone too much.
Let me summarize our tree components situation first.
We have Tree and TreeTable components in core, and another Tree
component in extensions.
The Tree from extensions is the oldest one, without Ajax support.
The Tree in core (as well
Err. Sorry for not-explaining it right. This is not a vote. What I
suggest are all those three options.
-Matej
On 6/10/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Matej Knopp:
I hope this e-mail won't upset anyone too much.
Let me summarize our tree components situation first.
We
On 6/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
if it is really better then do it now before we put out rcs. also what
happens to treetable? that should prob also move to extensions?
-igor
On 6/10/07, Matej Knopp [EMAIL PROTECTED] wrote:
Hi folks,
I hope this e-mail won't upset anyone too
Yes, exactly. That's what I want.
-Matej
On 6/10/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
So for the tree and treetable nothing changes with respect to wicket
1.2? Both are in extensions, and a new tree replaces the old, pre ajax
tree?
Martijn
On 6/10/07, Matej Knopp [EMAIL PROTECTED
On 6/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
a) remove the old (kinda unsupported) tree from extensions (is
anyone even use it?)
+1
Cool.
b) move the current Tree and TreeTable* from core to extensions
(sight, i know we moved it into core just recently)
Don't know yet.
[
https://issues.apache.org/jira/browse/WICKET-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502892
]
Matej Knopp commented on WICKET-618:
I don't understand this. It should be already supported. If there still
[
https://issues.apache.org/jira/browse/WICKET-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-561.
Resolution: Fixed
Fix Version/s: 1.3.0-beta2
TextField should determine the object type
Project: Wicket
Issue Type: New Feature
Components: wicket-extensions
Reporter: Matej Knopp
Assignee: Matej Knopp
Priority: Minor
Fix For: 1.3.0-beta2
--
This message is automatically generated by JIRA.
-
You can reply
1301 - 1400 of 2371 matches
Mail list logo
