You can have all the out-the-box stats, jmx, eviction (remove if
markup was not requested for 7 days) etc.
Juergen
On 7/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/14/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I've created a ehcache based MarkupCache extension. On my laptop
free something.
johan
On 7/15/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
You can have all the out-the-box stats, jmx, eviction (remove if
markup was not requested for 7 days) etc.
Juergen
On 7/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/14/07, Juergen Donnerstag [EMAIL
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?
Juergen
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. Thanks.
Juergen
, 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. Thanks.
Hi
If it doesn't have major API consequences, I don't mind getting it in.
II think you once requested
wicket:border
span wicket:id=myForm
wicket:body/
/span
/span
This now requires myForm.add(getBodyContainer()) in some cases.
As as you used Border without subclassing and extending it,
, Sven Meier [EMAIL PROTECTED] wrote:
It's about escaping a quote () in the value, when not properly escaped,
the value ends prematurely.
Sven
Juergen Donnerstag schrieb:
Until now nobody complaint about it not working properly in any
browser. Could you please point to the right spec where it says
any patch is welcome. Please open a jira issue, upload the patch and
I'm happy to look at it. Thanks.
Juergen
On 7/6/07, Gerolf Seitz [EMAIL PROTECTED] wrote:
since juergen donnerstag is the author of this class, this question is
probably directed towards him, but all opinions are welcome
thanks a lot
Juergen
On 7/2/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 6/30/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
BoxBorderTest_7 currently fails with Bamboo but it is working fine
with me. The Bamboo online information from the test doesn't give me a
hint either. And idea? I
+1
Juergen
On 7/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
fine by me +1
On 6/30/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Igor just committed a maven archetype to our svn and we still have a
quickstart and examples project that seem a bit out of place for our
main distribution.
BoxBorderTest_7 currently fails with Bamboo but it is working fine
with me. The Bamboo online information from the test doesn't give me a
hint either. And idea? I guess Bamboo is running on Linux?
Juergen
[x] yes accept wicket-contrib-velocity
Juergen
I need to look into a bit more. I way out-of-order for some days.
Juergen
On 5/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Ah, yes. I missed that one. Just came back from a vacation :)
Eelco
On 5/28/07, Johan Compagner [EMAIL PROTECTED] wrote:
AlMaw also already looked at it:
[X] I'm ready to freeze the codebase for RC bug fixing.
markup fragment was never meant to go into 1.3
Juergen
It should be possible with WicketTester. WicketTester creates a mock
request cycle instead.
Juergen
On 5/12/07, Xavier Hanin [EMAIL PROTECTED] wrote:
Hi,
I have a very specific need and I would like to gather some thoughts before
starting in a wrong direction. I need to render components in
sorry, I forgot to uncomment it. Interesting that no junit test failed
- we definitely should add one to avoid such fauxpage in the future.
The change is part of a (small) step by step change towards markup fragments.
Juergen
On 5/10/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
juergen, did you
It'll take some time. It was not an easy thing to do and the some
details of the approach we took needs to be reworked. But we'll get
there. Not sure it'll make it into 1.3 though.
Juergen
On 5/8/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Are there any plans for backporting this ?
Jan.
--
In 2.0 the code has been completely reworked. Very simplistic: In 1.x
we iterate over the markup, search the component, and render the
component based on the current markup position. This approach works
well for Pages (none-ajax components) but has some shortcomings when
it come to per-component
May be it is too early, but I have a strange problem.
I'm currently playing with backporting some MarkupParser functionality
which makes it is more easy to add IMarkupFilter and insert them at
the right (user determined) place.
This is the original junit output of SimpleTestPanelTest:
[X] Yes, propose Wicket for Graduation
Juergen
But I agree, in 2.0 it was much nicer (simpler, obvious, ...). I
haven't backportet it yet.
Juergen
On 5/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i also see MarkupParser.appendMarkupFilter @ MarkupParser:167
-igor
On 5/2/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Sorry, I did miss
I went through the 1.3 examples and seems to me that some are broken
pub: images are not localized
hangman: serialization exception
authorization: endless loop of exceptions
authentication: exceptions
customized markup loading: first link seems to be broken
and some more
are we not maintaining
+1
Juergen
On 4/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
+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.
I'm only saying the approach I took in 2.0 doesn't feel perfectly
right. Hence it probably wouldn't be a backport but a new
implementation for 1.x, which will take even longer. I am convinced
that the MarkupFragment concept itself is the right way to go.
Juergen
On 4/14/07, Eelco Hillenius
yes
Juergen
On 4/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
or 1.5 since 1.4 is just generics+1.3
-igor
On 4/14/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I'm not aware of any 1.3 issue it would solve. I'd leave it for 1.4
Juergen
On 4/14/07, Eelco Hillenius [EMAIL PROTECTED
I think Johan is right.
Unfortunately I'm not able to look into it over the weekend since my
computer broke down yesterday and I won't get it fixed before Tuesday
next week.
I haven't maintained the example testcases for a while due to various
problem with jwebunit, javascript, etc. The whole
experience report: Since I worked more on 2.0 than on 1.x I decided to
remove 1.x completely and to rebuild it from scratch before I wanted
to start backporting the localizer. I'm using windows and Eclipse.
Until now I checked out the projects individually (same as Igor), run
mvn
documentation, but until now I'm not
able to work on 1.x
Juergen
On 3/24/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
experience report: Since I worked more on 2.0 than on 1.x I decided to
remove 1.x completely and to rebuild it from scratch before I wanted
to start backporting the localizer. I'm using
:
org.apache.wicket:wicket-extensions:jar:1.3.0-incubating-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Juergen
On 3/24/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Juergen Donnerstag:
Until now I checked out the projects individually (same as Igor), run
/wicket-1.
3.0-incubating-SNAPSHOT.jar; invalid header field
On 3/24/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Juergen Donnerstag:
As I mentioned, until now I checked out the Wicket projects
individually instead of the whole wicket-1.x tree. Thus the parent pom
referenced in Wicket
-p9482860.html
On 3/24/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
This is the error message when I execute your command. I even removed
them manually and rebuild them, but the error does not go away. What
can be the reason for an invalid header field in a jar file?
[INFO
:
And it is a bug in the eclipse plugin that it requires the
dependencies in the local repository.
So first you'd need to do:
mvn install
then
mvn eclipse:eclipse
then
import projects
Martijn
On 3/24/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Thanks a lot Frank.
Juergen
On 3/24/07, Frank Bille [EMAIL
(or at least it should do that).
Also it seems that you only see the jdk-1.5 sub projects. Which is
strange (and why I suggest putting the -Pall parameter).
Did you see the wicket-examples project too? That is also part of the
1.5 subdir.
Martijn
On 3/24/07, Juergen Donnerstag [EMAIL PROTECTED] wrote
Thanks, that was the problem. Now I have all 1.x projects loaded in eclipse
Juergen
On 3/24/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Juergen Donnerstag:
No change. Still only 3 eclipse projects: jmx, objectsizeof and
spring-annot. No wicket-examples or any other project
I'm already working on backporting the Localizer. Lets see how far I
get this weekend
Juergen
On 3/24/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Cool, now that we have you back, can you ;-)
Martijn
On 3/24/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Thanks, that was the problem
I've backported Localizer, ResourceStreamLocator, ResourceFinder and
PropertiesFactory from 2.0 trunk. Compared to current 1.3 there are
some slight API changes though in my opinion no big ones. If one is
using any of these features you'll have to change your code though.
With that in mind, shall
I've no single junit test failure on wicket 1.x HEAD.
Juergen
On 3/24/07, Jonathan Locke [EMAIL PROTECTED] wrote:
ah. it looks like those tests are failing on 1.x HEAD anyway.
Eelco Hillenius wrote:
You changes sound good to me. I don't know why those tests fail.
Eelco
On 3/23/07,
+1
Juergen
On 3/21/07, Frank Bille [EMAIL PROTECTED] wrote:
+1
Frank
On 3/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Like the subject says.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5
They are really meant for simple cases only. If you need anything
special use Links and you can do whatever you want.
Juergen
On 3/9/07, Bruno Borges [EMAIL PROTECTED] wrote:
Why not? This is great for menus, bookmarkable pages, etc... =)
On 3/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
I finally found some time to restructure Localizer and many its
downstream classes. The code should now be much easier to read. The
Localizer interface remained (almost) unchanged, except on exotic
method which were meant for requests without Component. Since
component can now be null with the
I remember that about a year ago someone has create WML.with Wicket.
The old sourceforge mail archive might contain some information
Juergen
On 2/1/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
So, in short, what I'm asking here: how much effort would it take to add
WML support to Wicket?
+1
Juergen
On 1/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
+1
Eelco
On 1/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
these examples were written before dataview/datatable and no longer
demonstrate best practices
-igor
0
I go with the majority on this
Juergen
On 1/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
+1
Eelco
On 1/27/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
we have way too many base classes that arent really useful.
we can remove AbstractModel and AbstractDetachableModel as they serve
It only gets restartet once a day. Thats usually it. It is not
available 100% that is true, but it is down only very few times. If
anyone wants to spend some time on investigating why it is done, I'm
more than happy to grant you access. Unfortunately I have only very
little time right now. It is
Hangman doesnt work anymore
WicketMessage: Error attaching this container for rendering:
[MarkupContainer [Component id = 0, page =
wicket.examples.hangman.Guess, path = 1:letters:0.ListItem, isVisible
= true, isVersioned = false]]
Root cause:
java.lang.IllegalStateException: wicket.Component
There are junit test failure dues to changes to RadioBoxes?
Juergen
dispose it correctly.
It is not about jars or files in jars. See above.
The only thing that still is a problem i think is our wicket initializer
thing. That still seems to lock the jar files (for reloading inside tomcat)
johan
On 1/2/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Related
of changes
-igor
On 1/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
fixed
juergen take a second look in case its not how it is supposed to be
-igor
On 1/2/07, Ross Gardler [EMAIL PROTECTED] wrote:
Juergen Donnerstag wrote:
Anyone else having problems? It is fine on my machine except
While working on improving resource loading I came across the following issue:
IResourceFinder: URL find(String path);
xxxResourceStreamLocator: IResourceStream locate(Class, String path)
locate(..)
{
URL file = finder.find(path)
if (file != null)
{
IResourceStream stream = new
what means not found in fragment: null
Thanks for Help
-Ursprüngliche Nachricht-
Von: Juergen Donnerstag [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 28. Dezember 2006 18:30
An: wicket-dev@incubator.apache.org
Betreff: Re: is it a BUG or is it me?
The input
No, it has be wicket:id. The namespace not inherited from the tag to
its attributes.
Juergen
On 12/27/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 12/27/06, Ingram Chen [EMAIL PROTECTED] wrote:
So the propose solution is
wicket:container id=foo not wicket:container wicket:id=foo
Ingram created the following RFE:
I occasionally encounter a problem, for example, a template like:
tr
span wicket:id=groupAB
tdfield A/td
tdfield B/td
/span
tdfield C/td
/tr
groupAB is just functional group and will always
setRenderBodyOnly(true),
, Johan Compagner [EMAIL PROTECTED] wrote:
wicket:div ?
johan
On 12/26/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Ingram created the following RFE:
I occasionally encounter a problem, for example, a template like:
tr
span wicket:id=groupAB
+1
Juergen
Igor Vaynberg wrote:
move DataView and all super+support classes into core alongside ListView
amend ListView's javadoc to refer users to the newly added repeaters that
might better fit the usecase
-igor
+0
Juergen
On 12/2/06, Frank Bille [EMAIL PROTECTED] wrote:
You've got your 3x+1 so I won't stand in the way.
+0
Frank
On 12/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, last vote had my +- 0, but that lead to a stale mate which is
why this vote was restarted.
Eelco
On
I only recently put the logic back into
WebMarkupContainerWithAssociatedMarkup. It is easy to put it into a
utlity class.
Juergen
On 11/29/06, Joni Freeman [EMAIL PROTECTED] wrote:
On Tue, 2006-11-28 at 21:24 -0800, Eelco Hillenius wrote:
I've got around the fact that I can't do multiple
fixed
Juergen
On 11/19/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Could someone please take a look at that?
Eelco
I remember we had endless discussions on the sequence of finding
properties and I'm not able to recall all of them. I'm not aware of
any changes to the code for quite a while. And as it has been fairly
silent with respect to users asking questions or requesting
functionality, means to me that
To Johans point, I think the current implementation is too inflexible,
it is far to difficult to change/extend/limit the search order easily
if required. IMO this general design problem needs to be fixed.
Yep, I agree. The logic should be brought back to one place. So... we
could open an
It has been on my todo list for a long time already. It's just lack of time
Juergen
On 11/18/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/18/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
To Johans point, I think the current implementation is too inflexible,
it is far to difficult
WebRequestCodingStrategyTest and CookieValuePersisterTest are failing.
Mind someone looking into it. Thanks
Juergen
And it increases memory usage. We might not transfer it to the client
but we cache the markup.
Juergen
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
But you are right though that we still have that issue with were and if we
strip headers. All pages .html (not extended), .css and .js files
or not. IMO the markup doesn't contain any (what
was the term they used?) intellectual knowledge which needs to be
protected. It is the source code that should be protected. But that of
course is only my opinion.
Juergen
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
On 11/13/06, Juergen
+1
Juergen
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
yeah +1 to that
On 11/13/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
yeah, what eelco said.
-igor
I'm all for only changes the packages for 2.0. I still would like to
keep the breaks for 1.3 minimal, and generally get it
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
+1
On 11/5/06, Frank Bille [EMAIL PROTECTED] wrote:
+1
On 11/5/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
From my previous long winded message and to make sure we're voting on
the right issue:
- create 1.2.x from current head,
- fix only bugs in 1.2.x branch after a vote,
-
It is not only the header component, it is any auto component such as
wicket:link, wicket:message etc. If anything is different in the other
markup file ...
Juergen
On 11/3/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
the markup gets loaded. Two possible solutions: a) stay with adding
auto
Please see src/test/java. It contains all the junit tests.
Juergen
On 11/3/06, craigdd [EMAIL PROTECTED] wrote:
I though I remember seeing on the WIKI a section on how to unittest
components and pages in wicket. Since the move to the apache WIKI I don't
see that anymore, unless I am totally
Not sure I understand it. Can a bit more specific. How markups (input
and expected output) look like?
Juergen
On 11/3/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Sorry to hijack the thread, but I think this might be related:
I have an idea for a component that is added to an event handler
Search for WicketTester and TagTester and WicketTestCase
Juergen
On 11/3/06, craigdd [EMAIL PROTECTED] wrote:
Ok, but those don't look like the examples that I'm thinking about, I'm
looking for documentation on how to unittest your own pages, forms, etc.
Juergen Donnerstag wrote:
Please
the render phase.
Juergen
On 11/3/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but they are auto components, so they get disregarded after the render has
finished anyways so what is the problem?
-igor
On 11/3/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
It is not only the header component
Frank,
could you create a simple junit test as well please. Thanks
Juergen
On 10/26/06, Frank Bille Jensen (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/WICKET-16?page=all ]
Frank Bille Jensen resolved WICKET-16.
--
-1 for 1.2
0 for 1.3
+1 for 2.0
Juergen
On 10/25/06, Johan Compagner [EMAIL PROTECTED] wrote:
complex classloader machinations should be avoided at all time ;)
but fine by me if it suits people better.
This api doesn't fall back automatically doesn't it? (if log4j is not found
then jdk14)
You
+1
Juergen
On 10/25/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I think we should add such a class or extend links behavior. This
question comes up what, once a month? And I believe some committers
(Johan?) have said they would like such a component too.
Eelco
On 10/25/06, Korbinian Bachl
-
Von: Juergen Donnerstag [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 25. Oktober 2006 12:00
An: wicket-dev@incubator.apache.org
Betreff: Re: Possible Bug
Yes, sounds like a bug. We are not automatically url/base64
encoding/decoding all query parameters. Please create a jira
bug report
Did someone recently change the initializer code? It seems like it is
causing endless loops with the junit tests
Juergen
)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:337)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:497)
at wicket.jmx.Initializer.init(Initializer.java:68)
... 21 more
On 10/15/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Did someone recently
I have compiler errors in extensions because of model(Object)
Juergen
79 matches
Mail list logo
