Re: [Wicket-develop] wicket validators 2.0

IValidationContext() { >> T getValue() { return getConvertedInput(); } >> void error(String s) { FormComponent.this.error (s); } >> }} >> >> -Igor >> >> >> >> On 9/5/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> > >>

Re: [Wicket-develop] wicket validators 2.0

the list and map look like implementation details to me. isn't the component itself the validation context? so something more like: IValidationContext { T getValue(); void error(String); } then an adaptor class connects the two methods to the component. jon igor.vaynberg wrote:

Re: [Wicket-develop] urlfor funcs

yeah, i agree. this is once place i got carried away with making things convenient. those particular convenience methods should go away. i'm a little less sure about getting rid of setResponsePage(), but from certain perspectives that would be better too. getRequestCycle().setResponsePage(...

Re: [Wicket-develop] VOTE: incubation at Apache

[X] Yes, let's go Apache Eelco Hillenius wrote: > > Hi all, > > Some time ago we announced that we started negotiations with Apache to > start an incubation process. That basically means we would be entering > a 'test period' where we proof ourselves to fit in as an Apache > process, adhering

Re: [Wicket-develop] TagModifier

bah. this is going to be driven the other way around. when someone needs to nest something in the html they are going to go "oh shoot, is this a container?" and then they'll look and see it is. i don't see a reason for some other name here. igor.vaynberg wrote: > >> >> Only by having such a

Re: [Wicket-develop] TagModifier

I'd support Core, whereas I'd think Extensions might be better > if it's more specialised... > > /Gwyn > > On 19/08/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> yeah, i'm certainly someone who could have written this component too. >

Re: [Wicket-develop] TagModifier

yeah, i'm certainly someone who could have written this component too. only i didn't. and now i've slowly added more and more instances of the "one time" solution of webmarkupcontainer + simpleattributemodifier. the only hope here is to have a handy core component. i would have used that throu

[Wicket-develop] TagModifier

even after reading the counter-arguments, i'm still for this. it's one of those cases where it's a very common thing to do (probably MOST web apps have a need to simply modify a tag attribute) and the alternative for beginners is quite unintuitive and relies on knowledge they may not have yet. so

[Wicket-develop] two small feature ideas

i've run into a lot of situations developing voicetribe where i'm using webmarktupcontainers when it seems like it should not be needed. the code gets verbose and harder to read than it should be. two quick feature ideas to reduce this: 1. a TagModifier component which extends WebMarkupContaine

[Wicket-develop] voicetribe closed beta

hey wicket devs! we at voicetribe are approaching beta now on our film community site. our site is built in wicket (of course) but also does some neat stuff with java web start. and although we've still got a few little things going on, it's time to start testing. so, if anyone out there in

[Wicket-develop] hidden form field in IE

i've noticed that IE shows the spacing around a wicket form differently than other browsers. we add this inside the form: i suspect that this is causing the spacing to be different and i was just wondering if the input field itself shouldn't be style="display:none"? jon -

[Wicket-develop] rss feeds in wicket

has anyone done rss feeds in wicket yet? i'm trying to set up jetty so it can handle the "feed" protocol (as in feed://host/resource). i suspect it's easy, but i can't google how to do it. please reply-all if you have any ideas as i'm not on the dev list right now. thanks! jon ---

Re: [Wicket-develop] build failure in wicket 1.2 head

okay.  well that explains the problem nathan was having.  ;-)do the tests pass for you on 1.2 head too?On 7/10/06, Johan Compagner < [EMAIL PROTECTED]> wrote:IValueMap is 2.0 is not 1.2 so i don't know where you are exactly looking at? On 7/10/06, Jonathan Locke < [EMAIL PROTECTED]&

[Wicket-develop] build failure in wicket 1.2 head

anyone know what this is about?  i updated and got this build failure.also, someone added some interface like IValueMap (not sure i likethe sound of that at all) and now nathan can't build either.  for a finished product, we sure are changing wicket 1.2 a lot.    jon=== wicket.markup.html.panel.Inl

[Wicket-develop] wicket-parent pom exception

i have current wicket 1.2 head and maven 2.0.4.does anyone have any idea why i would get the exception below?should i be using a different repo or something?thanks,    jonC:\Projects\voicetribe\workspace\wicket>mvn install [INFO] Scanning for projects...[INFO] --

Re: [Wicket-develop] duplicate get methods in session classes

i may be wrong, but i thought co-variant return types were added in 1.5.On 6/1/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:Hi, tried to create a session class, which inherits from theAuthenticatedWebSession class in the auth package. My compiler (jdk1.4 andjdk1.5) throws some errors due to the

[Wicket-develop] test failure in 1.2 branch

i just checked out a fresh 1.2 wicket core and i get test errors.  apears to be ajax link.[surefire] Running wicket.ajax.markup.html.ajaxLink.AjaxLinkTest[surefire] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.364 sec=== wicket.ajax.markup.html.componentMap.SimpleTestPage ===@@ -8,14 +8,1

Fwd: [Wicket-develop] Type Enhancers

oops, meant to send this to wicket-develop!  i can tell it's going tobe one of those days...-- Forwarded message --From: Jonathan Locke <[EMAIL PROTECTED]>Date: May 5, 2006 7:07 AMSubject: Re: [Wicket-develop] Type EnhancersTo: wicket-user@lists.sourceforge.net i

[Wicket-develop] Re: multi-window support and deadlocks

i saw this thread on wicket-user today and wanted to comment on client-side state.i think the right thing for wicket is to support a generalized interface for storing session state.  it could be that the existing ISessionStore interface or some modification of it is sufficient.  but whatever the i

[Wicket-develop] anyone doing wicket here in seattle?

was thinking it would be nice to meet people using wickethere in seattle.  i know there are at least a couple of us now...maybe have lunch together and shoot the breeze.  if you'reinterested, send me an email so we can try to set something up. best, jon

Re: [Wicket-develop] protectection of internal bookmarkable pages

also, when you're running in development mode, nobody wants to type a password all the time.  maybe it should only be required in deployment mode?On 4/21/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: well, that sounds better.  but it seems like it's separate from what featu

Re: [Wicket-develop] protectection of internal bookmarkable pages

t even asking for the login codes because we already see that we can't check it because the user/password combo is not specified)When a developer does specify it in the ISecuritySettings so it does say "admin", "password" Then we see that and ask the user to authenticate it

[Wicket-develop] internal pages

i can't believe this problem. i've spent so many hours thinkingabout wicket security. patching every little mouse hole i couldthink of... and here it was my inspector feature that left the front door wide open! what a forehead slapper! man i am an idiot sometimes!! DOH!!to solve, i think 2 is b

[Wicket-develop] Wicket Enters the SourceForge 100

Today (Tuesday), Wicket moved up to #98 on sourceforge's project list, entering the top 100 projects for the first time.  That makes us a very popular project, especially given how gigantic sourceforge is these days!  Just thought you all might want to know this. Best,    Jon

[Wicket-develop] Type Enhancers

For anyone who was following my idea about "mixed types" which Igor posted to the user list recently, I've changed the name of it to "type enhancers" and written a micro-whitepaper on it which you can read here.  If anyone has any comments, I'd be interested in your feedback.  Thanks!Best,    Jona

[Wicket-develop] multiple sign in pages

multiple sign in pages (per role) would be possible, but not supported by default. you would have to provide the logic and throw a differently constructed RestartResponseAtInterceptPageException for each role. but it is certainly possible with just a little work. jon -

[Wicket-develop] Fwd: remove Page.checkAccess() in 1.2?

Begin forwarded message:From: Jonathan Locke <[EMAIL PROTECTED]>Date: February 6, 2006 5:10:32 PM PSTTo: wicket-develop@lists.sourceforge.netSubject: remove Page.checkAccess() in 1.2?    IAuthorizationStrategy is pretty darn easy to use and really suffers from none of the problems you describe

[Wicket-develop] remove Page.checkAccess() in 1.2?

IAuthorizationStrategy is pretty darn easy to use and really suffers from none of the problems you described. in your application's constructor you would do something like this: getSecuritySettings().setAuthorizationStrategy(new IAuthorizationStrategy() { boolean authorizeInstan

Re: [Wicket-develop] Stateless pages problem.

i assume you mean ExceptionErrorPage? it looks like the problem is that the page is not bookmarkable and yet has no listeners either. since it's not bookmarkable it cannot be recreated via refresh. since it has no listeners, it was assumed to be stateless and not left in the session! Joha

Re: [Wicket-develop] remove add() and pass parent in constructor?

it seems like any kind of injection ought to be framework-internal such that we could manage that very special case (maybe pass a special internal constant value as the parent that signifies that the parent can be set just once later). of course, injected components then behave differently t

Re: [Wicket-develop] [ wicket-Bugs-1409210 ] wicket.util.lang.Objects.sizeof() should be more effective

must is a strong word and this is more rfe than bug since sizeof is only used in debugging with the inspector, but this does seem good. SourceForge.net wrote: Bugs item #1409210, was opened at 2006-01-18 19:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You ca

Re: [Wicket-develop] [ wicket-Feature Requests-1408679 ] time for IAuthenticationStrategy

in markup container! and that seems perfect to me. will you stop trying to change everything that somehow doesn't intersect with your own personal world view? the same energy would be better spent trying to solve problems that would really improve the framework -Igor On 1/17/06, *Jonathan

Re: [Wicket-develop] [ wicket-Feature Requests-1408679 ] time for IAuthenticationStrategy

inimum you have an instanceof check that will run 99% for nothing. thus my suggestion of a seprate interface to only check instantiation of pages and not components. -Igor On 1/17/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: you would use this

Re: [Wicket-develop] [ wicket-Feature Requests-1408679 ] time for IAuthenticationStrategy

() automatically so you don't have to write this either. what happens on the sign in page would be implementation specific, but it would need to set things up so that future exceptions would not be thrown by the authorization strategy. Jonathan Locke wrote: an UnauthorizedInstantiationExce

Re: [Wicket-develop] [ wicket-Feature Requests-1408679 ] time for IAuthenticationStrategy

with authentication (whatever that might be). something like Session.onAuthenticate(). Jonathan Locke wrote: we need to avoid confusing things. the instantiation of a page component is also an authorization issue and is already covered by IAuthorizationStrategy: /** * Chec

Re: [Wicket-develop] [ wicket-Feature Requests-1408679 ] time for IAuthenticationStrategy

we need to avoid confusing things. the instantiation of a page component is also an authorization issue and is already covered by IAuthorizationStrategy: /** * Checks whether an instance of the given component class may be created. * If this method returns false, a [EMAIL PROTECT

Re: [Wicket-develop] Re: Wicket In Action

code looks like this: add(new InspectorBug("inspector", page)); // page could be "this" and html looks like: that's it. Brent Roberts wrote: Thanks for considering this. What would be nice is to provide stategies to help understand what you see in Tomcat's manager display re

Re: [Wicket-develop] Re: Wicket In Action

there is an inspector that dumps your session now easy to attach. see the examples for 1.2 (it's that little orange (i) icon) Brent Roberts wrote: Thanks for considering this. What would be nice is to provide stategies to help understand what you see in Tomcat's manager display regarding t

Re: [Wicket-develop] remove add() and pass parent in constructor?

i can understand this predicament and this was my first suggestion: that we release 1.2 as-is and then quickly release a 2.0 with these constructor changes before focusing on a longer-term 2.1... i think your request is a reasonable one and since you object, i'd like to change my vote to match y

Re: [Wicket-develop] remove add() and pass parent in constructor?

+1 for now Igor Vaynberg wrote: this question is posed here because we want feedback from non-committers who are interested in how wicket grows. -Igor On 1/16/06, *Ingram Chen* <[EMAIL PROTECTED] > wrote: I'm not committer but +1 for change now ! We

Re: [Wicket-develop] VOTE: default number of versions/pages to be held in the versionmanager/pagemap.

+1 for 5 Igor Vaynberg wrote: +1 for 5 -Igor On 1/16/06, *Johan Compagner* <[EMAIL PROTECTED] > wrote: Hi, The page eviction strategy is a bit rewritten so it now looks at the number of pages and the number of page versions to excactly mimic the

[Wicket-develop] unserializable log variable

getting this from displaytag example... java.io.NotSerializableException: org.mortbay.log.LogImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.write

Re: [Wicket-develop] Component.doRender

does anyone have an example to contribute to wicket-examples that shows how to use ajaxhandler? the current ajax prototype example looks really nice and does not need to use doRender(). looking at that example, i wonder if doRender() should really exist. it's quite elegant to set the request

[Wicket-develop] broken tests

i worked on ValueMap and AttributeMap a little tonight (they no longer nest map objects or create immutable wrappers, which is good for memory and cpu) and the result is that some tests are broken because the order that these maps iterates over their keysets has subtly changed. i spent about

Re: [Wicket-develop] Component.doRender

can be properly rendered. In that sense Page.doRender overrides Component.doRender as the logic to prepare to render a Page is different. Or to get rid of doRender completely (Component and Page) try to move Page.doRender into Page.render() and Component.doRender into Component.render. On 1/15/06,

Re: [Wicket-develop] Component.doRender

x27;t make sense to make Component.render more intelligent. Juergen On 1/15/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: can't the logic for doRender() just be folded into a smarter render() method? and then ajaxhandler could expose a render() method which would do the most appr

Re: [Wicket-develop] Component.doRender

maybe it's as simple as renaming Component.render() and Page.render() to internalRender() and then changing the name of doRender() to the more public sounding render() ? Jonathan Locke wrote: doRender() is an internal sounding name. Page.doRender() is entirely int

Re: [Wicket-develop] Component.doRender

From that point of view it wouldn't make sense to make Component.render more intelligent. Juergen On 1/15/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: can't the logic for doRender() just be folded into a smarter render() method? and then ajaxhandler could expose a render()

Re: [Wicket-develop] invocation chaining

Eelco On 1/15/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: there are a half dozen methods in Component that still do "return this" (which we removed from settings code). do we want to remove this now or wait until 2.0 to do that? or leave it? it seems to me that not many

[Wicket-develop] invocation chaining

there are a half dozen methods in Component that still do "return this" (which we removed from settings code). do we want to remove this now or wait until 2.0 to do that? or leave it? it seems to me that not many people are using this anyway, but maybe not... i dunno

Re: [Wicket-develop] Component.doRender

can't the logic for doRender() just be folded into a smarter render() method? and then ajaxhandler could expose a render() method which would do the most appropriate thing to render the component that the handler is attached to... Jonathan Locke wrote: i'm okay with manual renderi

Re: [Wicket-develop] Component.doRender

i'm okay with manual rendering so long as it's not through a method called doRender(), which sounds internal and does not differentiate itself from render(). Let the conclusion be that things are fine as they are now. If people want to be consistent with how our request cycle works, they shoul

Re: [Wicket-develop] profiling

f is using for example JMeter that must be then integrated into a unit test. That starts jetty and then let jmeter run through a script and let us report the number of total request made. johan On 1/14/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

Re: [Wicket-develop] Component.doRender

do that via setting the request target? > > > > > > -Igor > > > > > > > > > > > > On 1/14/06, Eelco Hillenius < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > Mar

[Wicket-develop] profiling

btw, does anyone have any profiling results for wicket? (johan, you seem to be going through performance stuff...) does anyone have any ideas how to include profiling in the build? or just make it easy to automatically update some xdoc file? -

Re: [Wicket-develop] does this cause a double checked locking problem or not?

maybe the answer is to unsynchronize it and just let the markup load twice on (probably very) rare occasions. you should get the same result since the markup is immutable. Johan Compagner wrote: MyObject myObject = concurrenthashmap.get(key) if(myObject == null) { synchronize(concurrent

Re: [Wicket-develop] does this cause a double checked locking problem or not?

burned, everyone is going to wonder about it. Jonathan Locke wrote: the reason for this has to do with the semantics of synchronized on muli-processor systems. until you actually enter the synchronized block order of operations on memory is not guaranteed because of processor cache (in)coh

Re: [Wicket-develop] does this cause a double checked locking problem or not?

the reason for this has to do with the semantics of synchronized on muli-processor systems. until you actually enter the synchronized block order of operations on memory is not guaranteed because of processor cache (in)coherency. Jonathan Locke wrote: i'm not 100% sure that i

Re: [Wicket-develop] does this cause a double checked locking problem or not?

i'm not 100% sure that it's a problem in this case, but generally speaking, double checked locking does not work in java because of the underlying memory model. Igor Vaynberg wrote: i think the concurrenthashmap guards against multiple threads writing into it, using it as a whiteboard. but i

Re: [Wicket-develop] class relative path

yeah. it's Component.PATH_SEPARATOR now. Igor Vaynberg wrote: yeah looks right. maybe we should make a constant for that :) -Igor On 1/14/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: shouldn't this: /** * @ret

Re: [Wicket-develop] Component.doRender

re elegant. Eelco On 1/14/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: but all these ajax components are using doRender()... and it's confusing how doRender() differs from render(). you can't tell just from the name. can we somehow

[Wicket-develop] class relative path

shouldn't this: /** * @return A path of the form [page-class-name].[page-relative-path] * @see Component#getPageRelativePath() */ public final String getClassRelativePath() { return getClass().getName() + "." + getPageRelativePath(); } be: /** * @return A

Re: [Wicket-develop] Component.doRender

i mean couldn't render() look at the markupStreamPosition value and act accordingly? Juergen Donnerstag wrote: The idea was that it in the future it will support component render (without previous full render) and that we won't need to change the API than. Juergen On 1/14/06

Re: [Wicket-develop] Component.doRender

r (without previous full render) and that we won't need to change the API than. Juergen On 1/14/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: can we come up with a better name for this method? it looks to me like it should be called something more like "rerender". i'

[Wicket-develop] Component.doRender

can we come up with a better name for this method? it looks to me like it should be called something more like "rerender". i'm not so worried about Page.doRender() because that is not a public API method... but Component.doRender() is part of the public api because of ajax and so it should

Re: [Wicket-develop] authorization II

x27;s impl of the strategy the more typesafety problems we can eliminate. im fine with that as long as the pattern we force is flexible. -Igor On 1/12/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: i agree, but i continued this thought and got r

[Wicket-develop] [Fwd: Re: security in wicket]

mation directly... similar to below. again, i can work on explaining this all in code... where i think it will make sense. jon Original Message Subject:Re: security in wicket Date: Thu, 12 Jan 2006 00:20:12 -0800 From: Jonathan Locke <[EMAIL PROTECTED]> To

[Wicket-develop] [Fwd: Re: security in wicket]

11 Jan 2006 18:06:51 -0800 From: Jonathan Locke <[EMAIL PROTECTED]> To: Maurice Marrink <[EMAIL PROTECTED]> CC: 'Martijn Dashorst' <[EMAIL PROTECTED]>, Johan Compagner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] References: <[EMAIL PROTECTED]>

Re: [Wicket-develop] authorization II

i agree, but i continued this thought and got rid of the strings. if it's okay, i'd like to fuss with eelco's refactoring for a few hours today. i think my idea will pan out if i'm given a chance to do that... your idea below is similar to the Action / ActionAuthorizer idea i sent yesterda

Re: [Wicket-develop] authorization II

Eelco Hillenius wrote: Now that I sent the discussion we had on the authorization thread, I'd like to point out the differences of view there are. 1. Should or shouldn't authentication be part of Wicket's security. I think not, as there are a couple of options for that already (JAAS, J2EE sec

Re: [Wicket-develop] stateless pages

i went ahead and fixed it this way. a good idea because now you can view any page in the page map by just tweaking the url of the inspector. kindof cool. jon Jonathan Locke wrote: Johan Compagner wrote: fine by me, are there specific things against it? we could label DO NOT USE

Re: [Wicket-develop] stateless pages

is the page id? (it is by default i think) it's the same value. getId() is a string and i wanted an integer id so i added getNumericId(). if there's a nicer way... jon johan On 1/8/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrot

Re: [Wicket-develop] stateless pages

he developers (don't know how) says no i want this page in the pagemap because i find it statefull then it may override something and return that if he wants. So he can say it is statefull but he can't say it is stateless.. johan On 1/8/06, *Jonathan Locke* <[EMAIL PROTECTED] <mail

Re: [Wicket-develop] stateless pages

is there a fix for this other than having the inspector bug make every page its placed on stateful? kindof makes it interfere with the experiment, but with this new auto detect code, i don't see another choice offhand. Jonathan Locke wrote: oh right... the page is stateless because i

Re: [Wicket-develop] stateless pages

oh right... the page is stateless because it has not rendered yet! the inspector bug was calling isStateless() in its constructor so every page is always stateless to it now! Jonathan Locke wrote: why is wicket inspector broken now? it just says every page is [Stateless Page]... even when

Re: [Wicket-develop] stateless pages

(new InspectorPage(page)); } }; } link.add(new Image("bug")); add(link); } Jonathan Locke wrote: why is wicket inspector broken now? it just says every page is [Stateless Page]... even when it is not... Johan Compagner wrote: ok implemented the fist cut for this It seems to wor

Re: [Wicket-develop] stateless pages

is called now). So, we might rethink whether we really need this method, or that we should make Wicket smarter about this. Eelco On 1/8/06, Jonathan Locke < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > >

Re: [Wicket-develop] stateless pages

we can always remove the final if we need to though... Jonathan Locke wrote: cool Johan Compagner wrote: ok implemented the fist cut for this It seems to work fine. Alle example applications seems to work and the test are running. Page.isStateless() is made final and it shouldn'

Re: [Wicket-develop] stateless pages

this does make it impossible to have stateless pages which take advantage of IPageMapEntry however. Jonathan Locke wrote: cool Johan Compagner wrote: ok implemented the fist cut for this It seems to work fine. Alle example applications seems to work and the test are running

Re: [Wicket-develop] stateless pages

hat we should make Wicket smarter about this. Eelco On 1/8/06, Jonathan Locke < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > the idea was that some pages that encode stateful urls might actually be > stateless (in

Re: [Wicket-develop] stateless pages

map implementation (or whatever it is called now). So, we might rethink whether we really need this method, or that we should make Wicket smarter about this. Eelco On 1/8/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: the idea was that some pages that encode stateful urls might actua

Re: [Wicket-develop] stateless pages

e and they know immedianlty why they suddenly get an Expired Page when they do X) johan On 1/7/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: maybe the IRequestCodingStrategy is the place to keep track of this. if the coding strategy is used

Re: [Wicket-develop] stateless pages

athan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: the new feature would not be any more limiting than the same feature in jsf. might not be too fun to implement though... Igor Vaynberg wrote: > imho, > > On 1/6/06, *Jonathan

Re: [Wicket-develop] [ wicket-Bugs-1394722 ] BookmarkableWebPage class

stateless and it is not stored in the page map. If it is called it has to be added to the pagemap. johan On 1/4/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: maybe when the component check flag is on we could look for any stateful components

Re: [Wicket-develop] stateless pages

make a PageEntry so the page should never go into the pagemap. this is already possible. just return true from isStateless(). johan On 1/7/06, * Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: the new feature would not be any more limiting than the

Re: [Wicket-develop] stateless pages

the new feature would not be any more limiting than the same feature in jsf. might not be too fun to implement though... Igor Vaynberg wrote: imho, On 1/6/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: it definitely can get harder. but it de

Re: [Wicket-develop] stateless pages

probably not use this feature even on a high volume site, perhaps unless it truly had to be clustered. but it seems not too hard to provide and it gives users options and critics (who may or may not be well informed) less to find lacking. Igor Vaynberg wrote: On 1/6/06, *Jonathan Locke

Re: [Wicket-develop] stateless pages

btw, just out of curiosity, how big can (non-persistent) cookies be? ;-) Jonathan Locke wrote: Igor Vaynberg wrote: possibly the fact that pages with large component hierarchies ( ie pages with repeaters ) will be huge when serialized and base64ed. so you end up with client side pages

Re: [Wicket-develop] stateless pages

ally sucks. agree, but it would only be required when you have turned it on. default would be off. i dont think url will be able to hold as much data as a decent sized page would produce. agree. this would only work only for special cases. -Igor On 1/6/06, *Jonathan Locke* <[EM

Re: [Wicket-develop] stateless pages

how hard would this really be? we simply store the IPageMap entry in a serialized hidden form field and put it back in the pagemap on request handling. am i missing something? Jonathan Locke wrote: so we do have stateless pages and we do have IPageMapEntry. two things: 1. what does the

[Wicket-develop] stateless pages

so we do have stateless pages and we do have IPageMapEntry. two things: 1. what does the code look like to encode/decode params for a stateless page into url? 2. now that we have IPageMapEntry, it could make more sense to allow page state serialization! rather than serializing the whole

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

just realized that the target lock problem will get much worse if igor ever gets his way with delayed init. then components could naively do something involving the parent that wound up accessing the session. Jonathan Locke wrote: i think you should be synchronizing on the target's

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

tLock() implementations... Jonathan Locke wrote: no, no, you're right. that call to get the request target from the request cycle should just be above the factory call and the lock should work. sorry, i was jumping to conclusions... Igor Vaynberg wrote: currently we lock the process

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

page instantiation on the same lock? -Igor On 1/5/06, *Jonathan Locke * <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: also, because we have Session.get(), any non-locked object (image object, for example) that accesses the session this way could have threadi

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

uh... or i don't understand requesttargets fully yet... ;-) Igor Vaynberg wrote: currently we lock the processing on the target.getLock()why not lock the page instantiation on the same lock? -Igor On 1/5/06, *Jonathan Locke * <[EMAIL PROTECTED] <mailto:[EMAIL PROTECT

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

because the page is the target and you can't get the lock until the constructor has run Igor Vaynberg wrote: currently we lock the processing on the target.getLock()why not lock the page instantiation on the same lock? -Igor On 1/5/06, *Jonathan Locke * <[EMAIL PROTECTED]

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

i think you should be synchronizing on the target's lock, retrieved by target.getLock() Martijn Dashorst wrote: Here's my patch for this code. I think this should work but I'd like others to take a look at it: I changed the page construction, such that it is done within a synchronized bloc

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

ng to have to hard-code all the session locks. Jonathan Locke wrote: just realized that the target lock problem will get much worse if igor ever gets his way with delayed init. then components could naively do something involving the parent that wound up accessing the session. Jonathan Locke

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

the constructor would still be un-threadsafe though, wouldn't it? Jonathan Locke wrote: i think you should be synchronizing on the target's lock, retrieved by target.getLock() Martijn Dashorst wrote: Here's my patch for this code. I think this should work but I'd li

Re: [Wicket-develop] Re: Are BookmarkablePageTargets executed outside the synchronized block?

also, because we have Session.get(), any non-locked object (image object, for example) that accesses the session this way could have threading problems. but that doesn't seem very likely. Jonathan Locke wrote: just realized that the target lock problem will get much worse if igor

  1   2   3   4   5   6   7   8   9   10   >