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 my one
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
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
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
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
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
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 Jonathan Locke
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:
Well, you
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
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 or
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 just
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 -
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] wrote:
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
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
start
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 the
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'! :)
On
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=revrev=512952
Log:
typo
Modified:
incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/IMarkupCacheKeyProvider.java
Modified:
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=revrev=512952
Log:
typo
Modified:
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
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
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
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
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'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
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
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
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
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
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
+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 in
45 matches
Mail list logo
