up
and it should 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 PROT
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 Ma
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
rg <[EMAIL PROTECTED]> wrote:
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
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
/8/07, 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
If it doesn't have major API consequences, I don't mind getting it in.
II think you once requested
This now requires myForm.add(getBodyContainer()) in some cases.
As as you used Border without subclassing and extending it, than you
should be fine.
How much extra memory are we ta
Until now nobody complaint about it not working properly in any
browser. Could you please point to the right spec where it says that
"\" must be escaped with ". A xhtml validator output would do as
well.
Juergen
On 7/8/07, Sven Meier <[EMAIL PROTECTED]> wrote:
Why is ComponentTag escaping quote
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 since
the implementation, at least IMO, is not easy to understand and it was
in the past not
[x] disable this feature by default, put instructions on how to enable it
Juergen
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
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
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
+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 distribu
I've backported the IMarkupLoader change which removes "business"
logic e.g. merging markup for inheritance out of MarkupCache into
markup loaders. The interface is designed in a way that markup loaders
can be chained, the most simple one just using MarkupParser. Another
one merging the markup in
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:
> http
[x] yes accept wicket-contrib-velocity
Juergen
You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter,
final Class beforeFilter)
Juergen
On 5/24/07, Al Maw <[EMAIL PROTECTED]> wrote:
Hi,
I've created a bug for this.
https://issues.apache.org/jira/browse/WICKET-590
It's currently causing the build to fail - we really should f
[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 y
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.
--
V
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 r
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:
...IUnvers
[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 m
It was new to me, but may be you are already aware of it. I was using
jdk 1.6 to run the tests on my windows pc and all tests passed. I
recognized that Bamboo failed (and eelco fixed it) but I couldn't
quite figure out why. Now I know. I changed jdk back to 1.4 and now it
works with eelco's chang
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 t
+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 thi
I don't think you are right. A new markup parser is create for each
markup file and each markup parser gets a new instance of
PrependContextPathHandler. Looks fine to me.
Juergen
On 4/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I don't think I undestand the issue...
Eelco
On 4/25/07, Ig
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
>
the back porting 100+ issues to are open in JIRA right now.
Eelco
On 4/14/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> 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
> implem
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 <[EMA
I agree and I'm not 100% sure the 2.0 approach on MarkupFragments is
realy the right one.
Juergen
On 4/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
markupfragment is a pretty extensive refactor, and i dont think it will be a
straight backport. i think best is to leave it for 1.4
-igor
On
It passed all tests when I committed it. Whatever made the test now
failing, might not be related to the backport. Your modification now
definitely changed the bahavor and you are sure that is what you
intended to do?
Juergen
On 4/7/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
A related
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 co
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
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'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. 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 ot
(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 PROTECTE
t 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.
>
> Jue
ailure-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
/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
> refer
r artifact:
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 individ
x27;t find the right 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 backp
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 -DdownloadSource
+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
> Wi
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:
+1
Juergen
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 oth
It seems that WicketTestCase has recently be moved from src/test/java
to src/main/java. I'm -1 on this channge. I understand the reason well
and I think we should come up with a better solution rather than to
allow code creep. It is merely for testing purposes. E.g. what about
getting rid of it co
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 ser
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 a
Hi,
someone change the autolink implementation but didn't run/update the
junit tests. Please run and modify the tests everytime before you
commit something to SVN.
The Cookie test has not yet been fixed either.
Juergen
+1
Juergen
On 1/13/07, Sean Sullivan <[EMAIL PROTECTED]> wrote:
+1
On 1/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Why don't we get rid of the old project.xml (maven 1) files. The
> current versions don't have the new logger dependency, and I think
> it's a pain to keep maintaining
Please see CustomResourceStreamFactory in wicket-examples for an
example on how to use it.
Juergen
On 1/10/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Yes, the setter should be renamed as well. Thanks for pointing out.
Juergen
On 1/10/07, Juergen Donnerstag <[EMAIL PROTECTE
Yes, the setter should be renamed as well. Thanks for pointing out.
Juergen
On 1/10/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Please extend ResourceStreamFactory.locate(...) and register your
factory with the application.
Juergen
On 1/10/07, Ernesto Reinaldo Barreiro &
Please extend ResourceStreamFactory.locate(...) and register your
factory with the application.
Juergen
On 1/10/07, Ernesto Reinaldo Barreiro <[EMAIL PROTECTED]> wrote:
Hi,
In an application we were using CompoundResourceStreamLocator but after
syncronyzing with the 2.0 repository I have foun
Hi Igor,
there are more wicket examples (e.g. library) failing due to the attach change
Juergen
On 1/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
fixed
-igor
On 1/7/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
>
> Hangman doesnt work anymore
>
> WicketMessa
There are junit test failure dues to changes to RadioBoxes?
Juergen
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 h
In an attempt to simplify (more readable) resource loading I
- renamed IResourceStreamLocator to IResourceStreamFactory
- combined what used to be AbstractResourceStreamLocator,
ClassResourceStreamLocator, ResourceFinderResourceStreamLocator and
CompoundResourceStreamLocator in a single class Reso
t have a disconnect :(
we can't 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
whole bunch 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:
> >
> > Juer
Anyone else having problems? It is fine on my machine except 4 (minor) errors
Juergen
On 1/2/07, Ross Gardler <[EMAIL PROTECTED]> wrote:
The commit at [1] has broken the 2.0 trunk:
http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/markup/MarkupCache.java?r1=490933
classloader? J2EE
and servlet container mail archives are full of classloader issues.
Are these issues only related to classes (not including resource
files)?
Juergen
On 1/1/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
fine by me
On 1/1/07, Juergen Donnerstag <[EMAIL PROTECTE
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 UrlResour
b. it is fixed in 2.0 trunk
Juergen
On 12/28/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
b. The problem is with MarkupParser, which doesn't handle this
specific situation of missing close tags. is already
registered as tag which doesn't require a close tag, howe
cket-dev@incubator.apache.org
> > Betreff: AW: is it a BUG or is it me?
> >
> > yes 2.0 - i like it even if it has its sharp edges. sorry
> for my dumb
> > mistake...
> > at least I now know what means "not found in fragment: null"
> >
> > Tha
The are not closed. is missing. But the error message
should be better. You are using 2.0?
Juergen
On 12/28/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi,
i just wanted to create a small JUNIT (regarding the BUG in case of a
StatelessForm breaking IndexedURLStrategy) test Johan asked me
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
> not
> first solution save some typing but IMHO it may ca
what do you prefer? wicket:div? wicket:span? wicket:tag? anything else?
Juergen
On 12/27/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
good idea. but pseudo is awfully cryptic.
Juergen Donnerstag wrote:
>
> Ingram created the following RFE:
>
> ===
pagner <[EMAIL PROTECTED]> wrote:
>>
>> ?
>>
>> johan
>>
>>
>> On 12/26/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
>> >
>> > Ingram created the following RFE:
>> >
>> > ==
Ingram created the following RFE:
I occasionally encounter a problem, for example, a template like:
field A
field B
field C
groupAB is just functional group and will always
setRenderBodyOnly(true), so rendered page will be validated.
But the pro
And what is the reason why you want to remove final? What are the use
cases? I understand your words, but just removing final to remove
final, IMO is not a good idea. I don't mind though to relax our
general position on removing final for these two methods if there is
real use case. I still think
+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
>
>
I applied the patch yesterday but didn't want to commit it (yet) as in
2.0 still quite some junit tests are failing. They should be fixed
first to avoid side effects.
Juergen
On 11/30/06, Frank Bille <[EMAIL PROTECTED]> wrote:
Thank you
Frank
On 11/30/06, Martin Benda <[EMAIL PROTECTED]> wrot
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 in
There are two test suites hows features have not yet been fixed in 2.0
- scoped component resolution
- wicket:component tag
I don't know about the others. I can only stress again and again and
again that every one should run the junit tests before committing
anything to make sure the change does
I created the bug report hoping that whoever made the change which
caused the test failing looks into the code he changed to make sure
everything is fine. And finally either revert/change it or modify the
expected test result. In general this shouldn't happen at all if
everybody would run the juni
fixed
Juergen
On 11/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Could someone please take a look at that?
Eelco
The Forms examples fails with an NPE in Check.java
if (group.hasRawInput())
{
String[] inputs = group.getInputAsArray();
for (String input : inputs) << NPE
{
WebRequestCodingStrategyTest and CookieValuePersisterTest are failing.
Mind someone looking into it. Thanks
Juergen
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 infl
> 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 is
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 most
+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 gener
I'm not sure. Isn't it that the whole form / page layout require
changes to make it look right. Same is true for japanese etc. That is
why we allow for per locale properties file.
Juergen
On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi,
I converted the form input example this weeken
nse header 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:
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
in src/main goes into our
binaries. When compiles it correctly and will then result in a compiletime
error because DummyApplication is unknown to WicketTester.
Frank
On 11/8/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
>
> I've seen the fix and I don't understand why.
; On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > just making sure you knew about it to save you some work :)
> >
> > -igor
> >
> > On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > >
> > > I didn't like the patch. It onl
I'll do. I must be tester.getApplication().getSecuritySetting().
Though it is probably better I change WicketTester to delegate to
avoid some changes to existing tests.
Juergen
On 11/7/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Could someone please fix the compile errors in wicket-auth-role
yes, logging in made the difference. Thanks
Juergen
On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
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
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?
Juergen
t; wrote:
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 M
1 - 100 of 147 matches
Mail list logo
