On 2/28/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* Eelco Hillenius:
> > I already have 1.4 compliance level in the project.
>
> That *and* in the libraries section you should set JRE system
> library to 'execution environment JSE-1.4 (JVM 1.4).
I have J2SE-1.4, but pointing to m
> you are correct that there is an underlying assumption that a user's roles
> cannot change within a session. to solve that problem right now, you would
> have to manually call Session.clear(), clearing all pagemaps in the user's
> session. why do you think that would not work? (aside from what
you're quoting me a bit out of context here because i was talking about
why your solution to check things on removal from pagemap wouldn't
work completely. but that argument was a sidetrack because i never
agreed such a check was either necessary or desirable for full security.
it's logicall
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
Well, you are right. Now I see that there should be no problems with
isInstantiationAuthorized when Session.clear() is used consistently... Sorry
for my confused arguments :-)
Thanks,
Bendis
On Wednesday 28 of February 2007 11:52:01 Jonathan Locke wrote:
> you're quoting me a bit out of context
That was what I was proposing.
The usecase is the following:
we have Employee with ssn, empno, lastname, firstname, and an
abbreviation used to identify the employee.
The autocomplete object field should accept all 5-6 different field
types and query the database based on that. The list of sele
I have the following case:
I have an IAssignmentAwareModel: on assignment, the model creates a wrapper
that is appropriate for a component. If the user assigns this model to a
form, the form ends up with an IWrapModel that is itself an
IInheritableModel: on inheritance, it creates a wrapper for a
Martijn Dashorst wrote:
[ ] No, I object! Java 1.4 examples are the thing I live and die for
[X] Yes, make one examples project to rule them all, and by all means,
make it Java 1.5 dependent
Al
but still:
session.invalidate() instead of clear() is a much better solution anyway.
johan
On 2/28/07, Martin Benda <[EMAIL PROTECTED]> wrote:
Well, you are right. Now I see that there should be no problems with
isInstantiationAuthorized when Session.clear() is used consistently...
Sorry
for
commit it.
I guess if it is much better then it would also be nice for 1.3?
johan
On 2/28/07, Juergen Donnerstag <[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
please make a jira issue for this
On 2/28/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
I have the following case:
I have an IAssignmentAwareModel: on assignment, the model creates a
wrapper
that is appropriate for a component. If the user assigns this model to a
form, the form ends up with an
No problem.
Martin Benda wrote:
>
> Well, you are right. Now I see that there should be no problems with
> isInstantiationAuthorized when Session.clear() is used consistently...
> Sorry
> for my confused arguments :-)
>
> Thanks,
> Bendis
>
> On Wednesday 28 of February 2007 11:52:01 Jonat
Absolutely. Provides the best guarantee since it clears anything in the
Session object of the user too.
Johan Compagner wrote:
>
> but still:
>
> session.invalidate() instead of clear() is a much better solution anyway.
>
> johan
>
>
> On 2/28/07, Martin Benda <[EMAIL PROTECTED]> wrote:
>
Sounds good Juergen. I'm sure it will help with the book as well (I'm
writing about localizers just now).
Eelco
On 2/28/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I finally found some time to restructure Localizer and many its
downstream classes. The code should now be much easier to re
so what we need is to add an option not to accept free-form text, and then
you can write a subclass that does the conversion of model<->string?
-igor
On 2/28/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
That was what I was proposing.
The usecase is the following:
we have Employee with ss
ha! you and eelco made me remove that feature! thats how it was in the
beginning - but no...who is going to need a wrapper that is itself
inheritable. pfft.
-igor
On 2/28/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
please make a jira issue for this
On 2/28/07, Jan Vermeulen <[EMAIL PROTEC
~juergen++
personally i was always afraid to look into the localizer code, there were
scarry beasties living in there! :)
-igor
On 2/28/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I finally found some time to restructure Localizer and many its
downstream classes. The code should now be
isinstatiationauthorized is also very important because sometimes you do
things in the constructor that have sideffects.
take a stupid example
class DeleteAllUsersPage() { public DeleteAllUsersPage() {
service.deleteallusers(); add(new label("lbl", "all users deleted")); }}
by the time enable o
I always get the blame! :) Seriously, I don't remember such a thing
and in fact hardly have been involved in the models design discussions
for 2.0 other than having to fix/ complain on wicket-contrib-menu
until I grew so tired of it that I decided to not support the project
any longer. So, whateve
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I always get the blame! :) Seriously, I don't remember such a thing
that just means you complain about issues you dont really care about :)
/me ducks
-igor
hmm, i can remember one or 2 things about this, but not specifically
this case, need to look at the commits
On 2/28/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> I always get the blame! :) Seriously, I don't remember such a thing
that j
Hi all, I'm on this list, and I'd like to know how could I help the project?
And what do I have to do to make part of the developers team?
Well, all I want is to contribute.
Reginaldo L. Russinholi
Sun Certified Java 5 Programmer
Development & Network Admin.
IRapida Telecom
Cianorte - Pr - Brazi
Let's start the blamin'! :)
On 2/28/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
hmm, i can remember one or 2 things about this, but not specifically
this case, need to look at the commits
On 2/28/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> w
All help is appreciated. One thing we can never get enough from (ask
our users!) is documentation. And then there are the issues
http://issues.apache.org/jira/browse/WICKET for which anyone can
deliver patches. And then there is helping out the mailing lists (we
are very helpful for the folks step
start out by helping others on this list. if you want to become a committer
start contributing patches to solve jira issues. we need to see that you
understand wicket indepth and are aligned with our way of thinking before we
will invite you to become a committer.
-igor
On 2/28/07, Reginaldo L.
Ok, I'm starting to work with wicket, but i intend to work a lot with it,
and furthermore help with its projects.
For now, thanx to all and soon I hope to be helping.
2007/2/28, Igor Vaynberg <[EMAIL PROTECTED]>:
start out by helping others on this list. if you want to become a
committer
star
Thanks, fixed.
Eelco
On 2/27/07, Martin Funk <[EMAIL PROTECTED]> wrote:
sorry for my lazyness.
The eclipse name for the wicket-daytime module i incoherent to the name
of the svn folder it is saved in.
This is an itch because the 'subversive' plugin for eclipse names the
folder according to th
no igor just needs to fix everything :)
talking about those model changes.. i guess that really falls under the java
5 part of wicket 2.0 so back porting this
to a 1.X release is not what we want yes?
johan
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Let's start the blamin'! :)
O
we dont really use anything there but generics, which are a help but not
required. but backporting all these model changes will be a lot of work, not
to mention it will break all the clients, and so martijn will rip you a new
one :)
-igor
On 2/28/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Author: ehillenius
Date: Wed Feb 28 12:31:04 2007
New Revision: 512952
URL: http://svn.apache.org/viewvc?view=rev&rev=512952
Log:
typo
Modified:
incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/IMarkupCacheKeyProvider.java
Modified:
incubat
Yup.
Eelco
On 2/28/07, Upayavira <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> Author: ehillenius
> Date: Wed Feb 28 12:31:04 2007
> New Revision: 512952
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=512952
> Log:
> typo
>
> Modified:
>
incubator/wicket/branches/wicket-1.x/wic
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are serializable which typically means in the context of Wicket
that they should b
It will work when I'll be done with subtype-based matching. But using
marker interface is somehow ugly (even so it is probably the best fit
for the Terracotta support).
Java5 annotations could be a nicer option for such purpose, but then
Terracotta don't support matching on annotations yet
I like it.
And if i use terracotta i wouldn't mind such a marker interface anyway.
I don't really find it ugly
Especially if terracotta can use this for subtype matching then it would be
sooo much
easier..
Only one problem that is see.. Still lists or maps that are used by use are
ofcourse not
ma
It will work when I'll be done with subtype-based matching. But using
marker interface is somehow ugly (even so it is probably the best fit
for the Terracotta support).
Somewhat ugly but as we were already using a marker interface
(Serializable) it doesn't really change much. Introducing a new
Any grave objections to this?
And if you don't have objections/ agree your reaction is welcome as
well so that I have an idea that people read it and agree :)
Eelco
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (and please excuse my ignorance of annotations), i
I'm curious if the case would ever come up where someone wants to extend a
Clusterable class but not want the extended class to itself be Clusterable.
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
It would be a Wicket type, as we don't want a compile time dependency
on Terracotta, and it wouldn't introduce a
I'm curious if the case would ever come up where someone wants to extend a
Clusterable class but not want the extended class to itself be Clusterable.
Yeah, that's an interesting case. It is not supported by JDK's
serialization but interestingly enough, it is by Terracotta.
Eelco
On Feb 28, 2007, at 10:20 PM, Tim Eck wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either
actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (
On Feb 28, 2007, at 10:26 PM, Eelco Hillenius wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either
actually,
just wondering which one you had in mind.
It would be a Wicket type, as we don't want a compile
that are serializable which typically means in the context of Wicket
that they should be available for serializing.
Duh. I meant 'available for clustering'.
Eelco
That all makes sense. I guess the question about extending Serializable
only makes sense if you were proposing that the marker interface was a
Terracotta type (but that is not what you were proposing)
Eelco Hillenius wrote:
It's not super important, but would the marker interface be a wicket
t
You can actually use annotations on pre-1.5 JRE's, as long as you
don't mind to have compilation postprocessing pass. I.e. either using
backport175 [1] or commons attributes [2].
True. But in both cases that would mean adding an additional
dependency. Which we are very careful about for Wicket
Eelco Hillenius wrote:
Finally, (and please excuse my ignorance of annotations), is it feasible
to introduce an annotation without adding any compile time dependencies?
I don't think so. And as we're targetting Wicket 1.3 for JDK 1.4 and
up, annotations are out of the question for us.
You ca
Jonas Bonér wrote:
It's not super important, but would the marker interface be a wicket
type or a terracotta type? I could imagine it could be either actually,
just wondering which one you had in mind.
Clusterable extends Serializable? Why the coupling?
Finally, (and please excuse my ignoranc
On Feb 28, 2007, at 10:41 PM, Eugene Kuleshov wrote:
Jonas Bonér wrote:
It's not super important, but would the marker interface be a
wicket type or a terracotta type? I could imagine it could be
either actually, just wondering which one you had in mind.
Clusterable extends Serializable?
go for it
-igor
On 2/28/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are se
I don't see reason to object, +1
-Matej
Eelco Hillenius wrote:
Hi,
I'm making an inventory of classes that should be instrumented by
Terracotta if you deploy for them. I have a whole bunch of classes and
interfaces like PopupSettings and IPageable and IPagingLabelProvider
that are serializable
+1
Eelco Hillenius wrote:
>
> Hi,
>
> I'm making an inventory of classes that should be instrumented by
> Terracotta if you deploy for them. I have a whole bunch of classes and
> interfaces like PopupSettings and IPageable and IPagingLabelProvider
> that are serializable which typically means
I just committed the changes for the core projects (both the 1.3
branch and 2.0 trunk). See
http://issues.apache.org/jira/browse/WICKET-337
So Eugene, this configuration fragment:
wicket.IClusterable+
true
should suffice for Wicket, right? Pretty cool if that works! Could you
ping this thre
52 matches
Mail list logo