typically be nothing really big).
Eelco
On 1/30/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
It really depends on your developer team on how comfortable you are
working on beta versions. If you can find your way around Wicket a
bit, and you do find important bugs, we are typically fast to respond
+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
Yeah, 1.3 is the best to go if you're ramping up for development now.
Eelco
On 1/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i would go with 1.3 branch. 2.0 is still unstable and if you have a deadline
i wouldnt go with it
-igor
On 1/29/07, Alexei Sokolov [EMAIL PROTECTED] wrote:
Hello
[ x ] yes, bug-b-gone my Wicket
[ ] no, I still have some critters to deal with
Eelco
On 1/27/07, Jonathan Locke [EMAIL PROTECTED] wrote:
a long time ago, i was wondering if we shouldn't put all wicket framework
resources under wicket. so you'd have app/wicket/* for framework reserved
stuff. besides being a nice orgnization, this would allow us to mount stuff
on the root
On 1/27/07, Jonathan Locke [EMAIL PROTECTED] wrote:
unacceptable how? what if you could configure the name under which wicket
stores its resources in application settings? default could be wicket but
you
could change it.
We've had a lot of complaints of people wanting to map their Wicket
Coincidentally I came across YUI's cheat sheets (see
http://developer.yahoo.com/yui/docs/assets/cheatsheets.zip). And I
like them! I don't have plans to write them myself for Wicket, but if
anyone would be interested in that, I'm sure it would be a great
addition to the framework.
Eelco
You might want to subtract 2 more if you want to win this :)
Eelco
On 1/24/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
-100
We already have the site up on apache: http://cwiki.apache.org/WICKETxSITE
Martijn
On 1/24/07, Eelco Hillenius (JIRA) [EMAIL PROTECTED] wrote:
[
https
I'd like us to include the src jars. It should be just an option with
maven, and I always hate it when I have to do it myself (like with
most projects unfortunately).
Eelco
On 1/23/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi Igor,
Actually, I do use maven. I just have lots of bad
click the link to src/javadoc jar that poitnts to the maven repo and save
that into your project
so what does the zip really get you that two links to the maven repo dont?
you dont have to use maven to download from the maven repo.
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote
Hi,
I'd like to get rid of the fact that WebResponse#redirect(String)
throws an exception when a redirect fails. That method is - like the
documentation states - only for internal use, and the code that
currently calls it never tries to catch the exception. I don't think
the exceptions add much
Not really. Lots of stuff came in between. Imo the 2.0 is reasonably
stable and many of it's features got backported to 1.3, making both
1.3 and interesting enough alternative and giving the new features of
2.0 the change to get tested (there are at least a couple of
production systems written on
+1
Eelco
On 1/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
include https://issues.apache.org/jira/browse/WICKET-218 in 1.2.5
-igor
I don't think the safety net mattered that much, and furthermore,
prior to the change, you have to make constructs like:
new MetaDataKeyActionPermissions(ActionPermissions.class) {
};
which imo is just stupid and actually surprised me no-one caught that.
So, if you are worried about the runtime
am +1 for keeping both
-igor
On 1/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't think the safety net mattered that much, and furthermore,
prior to the change, you have to make constructs like:
new MetaDataKeyActionPermissions(ActionPermissions.class) {
};
which imo is just stupid
+1 I think it makes sense API-wise, even if the problem could more
elegantly tackled in some other fashion.
Eelco
On 1/12/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
we need an official vote on this, the subject says it all.
this is to help with repainting of dependent (javascript, or other
Hello,
This is a ping to keep the new site design alive. Martijn, is Vincent
done with the new design, or is he still tweaking? Can we compile a
list of things that need to be done to get the new site + design up
and running in this thread?
Eelco
to happen with the
release of 1.3?
Jon
On 1/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hello,
This is a ping to keep the new site design alive. Martijn, is Vincent
done with the new design, or is he still tweaking? Can we compile a
list of things that need to be done to get the new site
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
- Align pagemaps and version management so that pages and versions are
stored in, and retrieved from the same entity.
- Change the SecondLevelCacheSessionStore so that it either saves
pages without the version manager but rather exactly
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
4? SecondLevelCacheStore sets a IPageVersionManager, That manager is
almost completely dummy
except that it increases an page counter when the page is changed just
like
the current one does.
then we generate the versionid but
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
exactly
We shouldn't delete any files only when the session is closed.
Why do this when the session is live? To save some space?
That looks to me like a wast of time when the session is still live and
kicking
and request is handled.
Because
I created issue http://issues.apache.org/jira/browse/WICKET-201.
Eelco
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
i will look at it to see if i can extract the version manager from the Page
as its own global thing.
Only one thing come to my mind that could be hard.. Keeping the current
AccessStack also an option. Because the global version manager for
There are a couple of components in extensions that are alternatives
(a better description for them than branches, as they typically
provide the same functionality, but have a different code base) for
the ones in core. It's one of the reasons for extensions' existence in
the first place. I don't
My back base knowledge is poor, so can you give an example of what
kind of markup you need to produce?
Eelco
On 1/8/07, Toscano [EMAIL PROTECTED] wrote:
Hello,
Thank you very much for your responses.
I understand what you want to say, but I'm afraid I don't know how to do it.
My Wicket
Hi,
Currently, pages and versions of pages are stored separately. Pages
are stored in IPageMaps, and each page has a IPageVersionManager. By
default (and I wonder how many users actually ever did override this)
the IPageVersionManager is UndoPageVersionManager, which keeps a list
of changes in
Exactly.
Eelco
On 1/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont even see the point of having an IPageVersionManager. it is tied to
Change which has an undo() method, so what other kind of manager can you
write except the undo one?
-igor
On 1/8/07, Eelco Hillenius [EMAIL PROTECTED
btw, SecondLevelCacheSessionStore seems a little fuzzy to me as a name.
it presumes someone knows what a second level cache is. what about
something a little more direct like maybe FileBackedSessionStore? not sure
i love that either, but it's maybe a little more obvious.
I don't know. It
Simplifying sounds *very* good to me. Thanks for giving it a try.
Eelco
On 1/7/07, Juergen Donnerstag [EMAIL PROTECTED] wrote:
In an attempt to simplify (more readable) resource loading I
- renamed IResourceStreamLocator to IResourceStreamFactory
- combined what used to be
On 1/6/07, Korbinian Bachl [EMAIL PROTECTED] wrote:
ok - I now understand why we need it. so, you couldnt get rid and since
changing much would break api in several places I only have 3 ideas:
1. dont change it - would be safest way
2. create another constructor where the locale could be
-Ursprüngliche Nachricht-
Von: Eelco Hillenius [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 5. Januar 2007 06:45
An: wicket-dev@incubator.apache.org
Betreff: http://issues.apache.org/jira/browse/WICKET-151
any others have an opinion about
http://issues.apache.org/jira/browse/WICKET-151
any others have an opinion about
http://issues.apache.org/jira/browse/WICKET-151 ?
Eelco
Hmmm... maybe. Sucks, because that really merely is a formal thing.
But ok, even that could probably be fixed in a few days?
Eelco
On 12/20/06, Frank Bille [EMAIL PROTECTED] wrote:
On 12/20/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Are there real nasty issues left besides this?
Don't we
I guess we have to have some
pretty clear proofs that there isn't any code left in SVN that can be linked
to them.
WDYT?
Frank
On 12/20/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hmmm... maybe. Sucks, because that really merely is a formal thing.
But ok, even that could probably be fixed
With discussed it from day 1... did we ever get a resolution though?
Did any ever do a solid proposal other then 'lets work with interfaces
instead'?
:)
Eelco
On 12/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
Didn't we already discuss such an interface before for 2.0?
I get a major déjà
pick that up.
Cheers,
Eelco
On 11/28/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I've got around the fact that I can't do multiple inheritance to
combine a component that is both a panel and a form component (or at
least acts as one) in many ways now, but I really think we need to
have a ready
On 12/13/06, Erik van Oosten [EMAIL PROTECTED] wrote:
True.
To make it rock solid, I think it should be adaptable and/or extendable.
IMHO it is not fair to expect that the change you propose is done
perfectly from the start and maybe not even ever.
Oh, common', what fun is playing fair? ;)
I'm using the same workspace too, but don't commit my differences :)
An important thing that is not mentioned here, and that was the main
reason initially to put these files in there, was that we weren't
satisfied at how checkstyle etc worked, but wanted to have a more
direct enforcement of
when i read it back in its gets converted again so i see 12-12-2006 18:00
you read it in and you see 12-12-2006 09:00
Thats fine for appointments but i don't want to have it everytime.
sometimes the data i type in is really that date (its a literal)
Example on a website:
Yeah. After waking up
formatting, etc
-igor
On 12/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'm using the same workspace too, but don't commit my differences :)
An important thing that is not mentioned here, and that was the main
reason initially to put these files in there, was that we weren't
satisfied
IMO .classpath files should be removed from the repository as
every developer has different usage: one wants JAR dependencies,
one wants to reference other projects in the workspace. And
apparently Igor has multiple versions of Wicket in his workspace
thus needs different project
(nowEST.hourOfDay());
-igor
On 12/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'll actually go Igor's path of having model wrappers for this. Darn,
why does anything you want to do with dates in Java have to be so
awkward all the time.
Eelco
for now i accept eelco's hack only because i
think it is a necessity at this point in time.
Exactly. Imo, we need something like FormComponentPanel in 1.3/ 2.0
sooner rather than later. In the past I've had a couple of times where
I just spent too much time trying to work in other ways, while
But in
future versions, it would be great if you could achieve the same
through mixing in rather than extending.
my point was that it is the formcomponent that should be mixed into the
panel and absolutely not the other way around
Do we think in different directions? What I meant is that
Taken that you want them to turn up as real components, being able to
receive their own inputs and stuff, you'd need an interpretation.
Roughly
public class MyDynamicPanel extends Panel {
public MyDynamicPanel(URL xmlDefinition, IModel model) {
// read and interpret definition
// create
On 12/13/06, Erik van Oosten [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
Then i need to know that /app in the filter. You can't ask it anywhere
(not
that i know)
Perhaps it is possible to parse the web.xml from Wicket?
Should be doable, though it seems like a lot of work for a
agree with Gwyn that we should avoid adding new stuff to 1.2 only
really needed fixes.
And try to focus on getting 1.3 as fast as possible out of the door.
johan
On 12/11/06, Gwyn Evans [EMAIL PROTECTED] wrote:
On 11/12/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
[ ] sure put it in 1.2.x
I agree with that remark, and like the idea of components attaching to
markupfiles whatever kind of component they are. However, what we'd
gain in flexibility by getting rid of Panel (hypothetically), we'd
loose in clarity. If you wouldn't explicitly instantiate a panel that
matches markup, how
Sure, done.
The issue is still open. I'm still not convinced we should ship the
reloading filter tbh. As it only works with quite a few ifs and buts,
I'd rather see the reloading filter (and class locator) to be part of
wicket-extensions or maybe as a WIKI article or such. Though I'm fine
with
BTW, is the reloading filter portable to Wicket-2.0? do you see any
problem in using it with w-2.0?
I first wanted the implementation stable enough before we port the
changes to 2.0. There need to be a couple of tweaks before that filter
can be used, but not big things.
Eelco
See http://issues.apache.org/jira/browse/WICKET-159
We don't currently focus on the popped up window, which has the effect
that if the window with the same name already is open and in the back
ground, it will stay in the back ground. It's an easy fix, and I
thought it might be what people want
It's not on the top of my head when/ how, but final was removed a long
time ago because it just worked better. Like e.g. isVisible, even
though the fact that the method is not final results in a weaker
contract, in practice this rarely (or never) leads to problems, while
the ability to override
Are there relased date for Wicket 1.3 and wicket 2.0
I would actually be confident enough calling 1.3 final right away
(1.3.0) or maybe do one release candidate first.
Eelco
/branches - helds 1.1, 1.3, and 1.2, branch as well as /vendor (whatever
this is for) and a (!) wicket-stuff directory...
Any branch goes if it makes sense to the people creating it. Every now
and then, it would be good if people delete obsolete branches again
(if they are *very careful* about
functionality
in a web application. Using Wicket as web application framework it think
would be nice and useful to have a fast way to expose embeded service in
your application jar.
Paolo
On 12/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't know. There are other frameworks that are great
I agree with the sentiment, and I think a 1.3 release has more
priority than 2.0, but we can push out 2.0 as well... it's a beta
after all.
Eelco
On 12/8/06, Johan Compagner [EMAIL PROTECTED] wrote:
hmm my thing is the other way around
2.0 i dont know (we need to do more there i guess and
I'm not proposing to ease up on final in general, though I think using
finals aggressively makes more sense when the project is taking shape
and less so when things got more stabilized. Components like Link,
TextField, CheckBox, ImageButton are components people regularly ask
about why they can't
Please vote:
[ x ] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 12/7/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Another example is Link with a label inside. I'm starting to get
irritated with the fact that even though a label rendering was
requested as part of it's default behavior, and at least
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
After deleting some heated, unsent messages (never post when angry, a
very wise blogger told me), taking some time thinking about other
stuff, I see that I misinterpreted your message. I'm sorry I misread
you, I'm sorry I accused you of
I think using final for the onComponentTag and onComponentTagBody
methods have served their purposes fine during our wild two years of
development, but our core components are now stable enough to not have
to be worried about painting ourselves in the corner when we would
open up these methods
, we better discuss this on http://issues.apache.org/jira/browse/WICKET-144
Eelco
johan
On 12/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It just didn't work. It didn't work for Jetty on Linux and OSX, but it
did for Jetty on Windows. Jetty throws an EofException, which extends
+1
Eelco
On 12/5/06, Matej Knopp [EMAIL PROTECTED] wrote:
Hi, I've just committed a fix that allows td, tr, th, thead and tbody
replaced by AJAX.
Should I backport this to 1.2.4?
+1 (binding)
-Matej
--
get professional wicket training and consultation
Sure, go for it.
Eelco
On 12/4/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Eelco Hillenius:
Well, no. We'd have to start a new vote. Which I'm not gonna do
this time, as my previous two tries got a very luke-warm
response :)
No Wicket developer seems to be willing
So please cast your votes:
[ ] Leave ListView in core unchanged and let the repeaters forever
in the extensions
[ x ] Move at least a bunch of repeaters from wicket-extensions into
core and deprecate ListView
Eelco (binding)
Though we don't have to actually deprecate ListView. I
I would like to know
*which* repeaters move to core...
That could be another proposal for which we need some to time to
settle which ones. The point of this vote is to get clear whether we
want to keep the things as they are, or that we want to put some more
weight on the repeaters instead of
+1
Eelco
On 12/4/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
+1
-igor
On 12/4/06, Igor Vaynberg [EMAIL PROTECTED] 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
Yeah. Ted, trunk is meant for 2.0, and we have 1.3 and 1_2 for
Eelco
On 12/1/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* [EMAIL PROTECTED]:
Revision: 1256
http://svn.sourceforge.net/wicket-stuff/?rev=1256view=rev
Author: ted_roeloffzen
Date: 2006-12-01 07:17:27
Can we have more votes please devs?
Eelco
On 12/1/06, Johan Compagner [EMAIL PROTECTED] wrote:
nowadays i hate checked exceptions..
+1
johan
On 12/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
+1
Eelco
On 11/30/06, Nick Heudecker [EMAIL PROTECTED] wrote:
Here's the background
.
Not sure if just declaring the checked exception in the constructor of
a page is just as good. ie.
class MyPage extends WebPage {
MyPage(PageParameters pars) throws StringValueConversionException {
// ... do something with the pars.
}
}
On 12/1/06, Eelco Hillenius [EMAIL
Yep, you're right. If you could open an issue for this, I'd be happy
to apply the changes.
Eelco
On 11/28/06, Ernesto Reinaldo Barreiro [EMAIL PROTECTED] wrote:
Hi,
I have some problems in generating dynamic images (charts) and the they seem
to be related to the method
protected
Nevermind. It's fixed: http://issues.apache.org/jira/browse/WICKET-130
(wicket 1.3 and 2.0).
Eelco
On 11/30/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yep, you're right. If you could open an issue for this, I'd be happy
to apply the changes.
Eelco
On 11/28/06, Ernesto Reinaldo Barreiro
Well, no. We'd have to start a new vote. Which I'm not gonna do this
time, as my previous two tries got a very luke-warm response :)
Eelco
On 11/30/06, Alexei Sokolov [EMAIL PROTECTED] wrote:
So, is it decided that repeaters will move to the core?
Thanks,
Alex
On 11/28/06, Eelco Hillenius
But now the real question: what about that traversal?
Eelco
On 11/28/06, Johan Compagner [EMAIL PROTECTED] wrote:
with validation this time. Note the (double) casts.. they suck and
should be solved by adding methods that take ints. Anyone up to that?
I don't get why you have to cast.
i
On 11/29/06, Johan Compagner [EMAIL PROTECTED] wrote:
what makes a formcomponent a formcomponent?
That, of course, is the main question :) But not an easy one,
certainly not to extract a robust interface from it. The component
like I proposed (but that should have the header stuff included)
On 11/29/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
what if the parent is disabled - then the traversal should not go to
children.
Yep. But that's not rocket science.
there are plenty of usecases for both traversal modes - i wouldnt change the
default because there might be a lot of things
IMO the great components in the extension's repeater package
should be promoted to the core. It is very easy to miss those
great extensions, just because they are not in core. I feel
disappointed to discover them after 6 months of Wicket hacking...
I agree and in fact
Currently, we traverse children of Forms pre-order. It would imo
actually be nicer to traverse post-order so that if you would create
nested form components - not a common use case, but possible - the
children would be updated before the parent, so that the parent can
use the updated values of
On 11/28/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Currently, we traverse children of Forms pre-order. It would imo
actually be nicer to traverse post-order so that if you would create
nested form components - not a common use case, but possible - the
children would be updated before
I've got around the fact that I can't do multiple inheritance to
combine a component that is both a panel and a form component (or at
least acts as one) in many ways now, but I really think we need to
have a ready-to-use component for this now.
This would be the simplified version:
public class
and
should be solved by adding methods that take ints. Anyone up to that?
Bed time here.
Eelco
On 11/28/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/28/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Currently, we traverse children of Forms pre-order. It would imo
actually be nicer to traverse post
I would be ok with removing it. Maybe Johan wants to confirm?
Eelco
On 11/27/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
I was giving the WicketFilter backport a shot, and I noticed that the
wicket servlet is completely gone from Wicket 2.x.
Should we keep the servlet as a fallback for 1.x
around our filter should do the trick.
-igor
On 11/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I would be ok with removing it. Maybe Johan wants to confirm?
Eelco
On 11/27/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
I was giving the WicketFilter backport a shot, and I noticed
Could someone please take a look at what's wrong with Wicket 2.0's
unit tests? Besides the fact that we have 5 failures and 2 errors,
they generate an enormous amount of serialization errors.
Eelco
some time ago i reportet http://issues.apache.org/jira/browse/WICKET-16
, wich was solved fast. However, the problem consits till today and so i
opened up http://issues.apache.org/jira/browse/WICKET-77
These was aimed at the missing decoding of these issues in pageparameters,
however, I now
Method internalDetach should have been called in
Component#renderComponent. Just like internalAttach should have been
called in that method; which was fixed a couple of revisions ago by
me, but I overlooked/ forgot about internalDetach. The big weird thing
is how this worked in the first place,
+1
Eelco
On 11/23/06, Matej Knopp [EMAIL PROTECTED] wrote:
Okay, the description wasn't clean enough. I didn't fix firefox :) I
just made a workaround in modal window (actually removed the code that
was writing Loading... to iframe before the page inside was loaded :))
-Matej
Matej Knopp
Oh, actually I made the StringResponse serializable yesterday as I
thought it was temporarily set somewhere else. But now... I don't know
what I was thinking as indeed Matej, that doesn't solve the fact that
that response shouldn't be in there in the first place. It is a show
stopper though.
Sigh... seems I had some outgoing changes still too. Programming in
the evenings != a good idea.
Eelco
On 11/22/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, sorry about that. Actually I made that change (at least I
thought) so that only StringResponse implemented it.
Anyway, it seems
+1
On 11/20/06, Matej Knopp [EMAIL PROTECTED] wrote:
Hi
I've got a fix I want to commit to 1.2.x, it's concerning
AbstractAjaxTimerBehavior and IE leak.
Just one minor fix, shouldn't break anything.
WDYT?
-Matej
Bug report?
On 11/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
in 2.0 we have a cookie unit test failure (some utf8 chars are encoded that
generates a different string then the test says it has to be)
This should be returned:
test+%C3%A4%C3%B6%C3%BC%C3%9F%C3%A9%C3%A8%C3%AA
but this gets
Me? Not that I know :)
On 11/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
there was a bug report wasn't there???
You where busy with that..
johan
On 11/21/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Bug report?
On 11/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
in 2.0 we have
Hi all,
I'm writing a chapter on internationalization/ localization, and found
out the message loading works differently from what I expected (and
I'm quite sure how it used to work pre 1.2?).
The first thing I stumbled on was the fact that messages are located
searching from parent to child
But rewriting that.. its a file with almost only static finals.. rewriting
that means that you pretty much type it over
What we could do, and what imo would be a bit nicer, is instead of a
general bucket of client properties (backed by a map), just implement
those properties as actual
On 11/18/06, Johan Compagner [EMAIL PROTECTED] wrote:
we should first go through it for the given language and then do it for the
default language
But quickly looking at that.
That won't be an easy fix, because the iteration through components is in
Localizer and the iteration over locale/style
On 11/18/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think that was done so you can override properties of deeper components.
suppose i create a custom component, and this component uses key my.key in
its markup and provides a default value in its .properties file.
so how do you override
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 to change/extend/limit the search order easily
if required. IMO this general design problem needs to be fixed.
Yep, I agree. The logic
ClientProperties is MPL, which should be ok, right?
Eelco
On 11/16/06, Frank Bille [EMAIL PROTECTED] wrote:
All,
I was a little too quick placing ASL2 headers in all the .java files in 2.0.
When looking trough 1.x I found some thirdparty code. I have therefore
looked through all java files
You're right. I was confused with BSD. Damn. Seems like we have to
rewrite it then. To the upside, this isn't very difficult.
Eelco
On 11/17/06, Frank Bille [EMAIL PROTECTED] wrote:
On 11/17/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
ClientProperties is MPL, which should be ok, right
And now? You have more detail for us?
Eelco
On 11/15/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Error 500:
Request processing executed 32767 steps, which means it is probably in
an infinite loop.
Martijn
--
a href=http://www.thebeststuffintheworld.com/vote_for/wicket;Vote/a
for a
501 - 600 of 667 matches
Mail list logo
