but instantiation authorized is does just what it says.
is the creation of a page/component possible
For extra checks you need:
/**
* @see
wicket.authorization.IAuthorizationStrategy#isActionAuthorized(
wicket.Component,
* wicket.authorization.Action)
*/
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 name it finds in
the .project file.
thnx,
Martin
Index:
This is a vote that I came to after some long hard thinking. Our
examples projects have grown and put a burden on the release
procedure. We already discussed merging them into one project and iirc
the concensus was to make it so. The problem lies with the
Wicket 1.x branch where we have Java 1.4
OK, I'll start adding more stuff to it...
What do you mean with too wide? The screen is now for 1024 wide
screens iirc. They won't get wider. 900px wide.
Martijn
On 2/27/07, Frank Bille [EMAIL PROTECTED] wrote:
Yes thats really good. But a link to the sources would be very good.
And we have
(non-binding)
[ ] 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
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
[ ] 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
Stefan Lindner
everyone can test on java5 to look how it works so that shouldn't be any
problem:
+1 for java5
On 2/27/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
This is a vote that I came to after some long hard thinking. Our
examples projects have grown and put a burden on the release
procedure. We
Martijn Dashorst wrote:
This is a vote that I came to after some long hard thinking. Our
examples projects have grown and put a burden on the release
procedure. We already discussed merging them into one project and iirc
the concensus was to make it so. The problem lies with the
Wicket 1.x
[ ] 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
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Xavier Hanin wrote:
Whlie browsing the wicket1.x code, I've stumble upon a piece of code which
seems strange in the WicketFilter class:
public void setServletMode(boolean servletCompatibilityMode)
{
this.servletMode = true;
}
Shouldn't the servletMode be assigned to
but that is so disjointed.
for example how will that interact with setrequired(true)? you entered
something into text but the model is null?!?
also
lets say i want to create a new person if one doesnt exist. if i know this
field works with strings only there is one thing for me to do, write a
if you care about security at all, when the user logs out you should be
invalidating their session. if their session is gone, you can't get to any
of this information because their page map is associated with their
session.
Martin Benda wrote:
Hi,
isn't
i was seeing it just as a component that's completely consistent for
selecting among available values. but if the model is null (required
validation would fail), you could manually pick up the value the user
entered to create a new object. the only problem there is clearing
the required
but i use it all the time just as a textfield, so you are saying i am
screwed because all of a sudden my model would be null just because there
are no autocomplete options?
i think what is really needed here is another component.
-igor
On 2/27/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i
if we're getting rid of PageLink entirely, you mean:
new Link(previousPage)
{
public void onClick() { setResponsePage(prevPage); }
public boolean linksTo(Page page) { return page.equals(prevPage); }
}
Johan Compagner wrote:
instead of doing this:
PageLink link = new
oooh... i missed that somehow. i had been assuming all along we were
talking about another component because of the title of the thread.
i agree and i'd call it AutoCompleteObjectField.
igor.vaynberg wrote:
but i use it all the time just as a textfield, so you are saying i am
screwed
The current slf4j version included in wicket2 examples is 1.1.0. It should be
1.3.0 because the Logger class name changed and the core wicket library already
uses the new name.
Stefan Lindner
[ x ] Yes, make one examples project to rule them all, and by all
means, make it Java 1.5 dependent
Eelco
could you please add it to jira, thanks
-igor
On 2/27/07, Stefan Lindner [EMAIL PROTECTED] wrote:
The current slf4j version included in wicket2 examples is 1.1.0. It should
be 1.3.0 because the Logger class name changed and the core wicket library
already uses the new name.
Stefan Lindner
but there is also an enabled action that can work very well for this. if the
page is not enabled it wont be rendered
-igor
On 2/27/07, Jonathan Locke [EMAIL PROTECTED] wrote:
you are correct that there is an underlying assumption that a user's roles
cannot change within a session. to
sorry. you're correct. the enabled action is actually preferred in general
for this because the framework does a variety of other checks beyond
just rendering. for example, you cannot submit a form that has been
found to be disabled by security.
igor.vaynberg wrote:
but there is also an
we do very much need isInstantiationAuthorized(Class). it is a building
block
for implementing component security, including role based authorization.
and since pages are components, all the cases you're concerned with are
covered.
but pages are not the world in a component framework. it's
* Jean-Baptiste Quenot:
Author: jbq
Date: Tue Feb 27 15:29:12 2007
New Revision: 512491
URL: http://svn.apache.org/viewvc?view=revrev=512491
Log:
Merged with revision 497650:
better creation of the tmp/work dir and cleanup
Modified:
I don't know about that maven option, but if you check out the project
from svn with the project files (which are custom) it should prevent
you adding 1.4 code.
Eelco
On 2/27/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Jean-Baptiste Quenot:
Author: jbq
Date: Tue Feb 27 15:29:12 2007
* Eelco Hillenius:
I don't know about that maven option, but if you check out the
project from svn with the project files (which are custom) it
should prevent you adding 1.4 code.
I already have 1.4 compliance level in the project.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
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).
Eelco
eclipse doesnt catch this, neither does javac i dont think :| they catch
generics and other language constructs, but you can still import classes
like stringbuilder
-igor
On 2/27/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Eelco Hillenius:
I already have 1.4 compliance level in
Hi team,
What about creating a Wiki page to list all the things
that require a sync between branches?
So that at least we know what is missing in 1.x WRT
trunk or the opposite, and can do it later without
forgetting.
WDYT?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
On 2/27/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
eclipse doesnt catch this, neither does javac i dont think :| they catch
generics and other language constructs, but you can still import classes
like stringbuilder
Not if you use the JDK 1.4 lib as the syslib of your project. Which is
why
eclipse doesnt catch this, neither does javac i dont think :| they catch
generics and other language constructs, but you can still import classes
like stringbuilder
Not if you use the JDK 1.4 lib as the syslib of your project. Which is
why that project file is committed like that.
Or maybe
30 matches
Mail list logo
