you can have multiple strategies easily working together. just keep looping through them until you get a false out of one (a veto) and then stop. if no false then it passes - true. just what a compound strat would do.
but setonce and exception wont work. then module can never set one, so we lose all that goodness. -igor On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
you could easily have a set-once policy and throw an exception. i don't understand what you mean by add with veto. igor.vaynberg wrote: > > the thing i dont like about is that if a module installs a strategy the > user > can then later overwrite that strategy in security settings by simply > calling set with his own. its the semantics of set/get vs add that suck in > this case, add is more preferrable with veto return values from the > strategies. > > -igor > > > On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> aaaah. i'm a bit slow this morning. the reason you want to change >> authorization >> is because auto module initialization doesn't permit easy parameters to >> the >> module >> such as: >> >> add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...)); >> >> (or whatever name best fits this module) >> >> >> Jonathan Locke wrote: >> > >> > >> > i agree that not having to know this: >> > >> > addComponentInstantionListener(new SpringComponentInjector(this)); >> > >> > is where any kind of module system could improve on the current way of >> > doing things. >> > but there is still a need to know how this is happening for new users >> of >> a >> > project. >> > something magic is going on when you start a wicket application with >> > auto-loaded >> > modules and eventually there will be issues about load order because >> there >> > CAN be. >> > >> > i think the best thing would be to figure out some easy way for the >> user >> > to discover >> > what modules they can install by putting in a simple line of code. one >> > easy way to >> > do that, for example, would be to have a prefixing convention so that >> they >> > pop up >> > in your IDE. "addModule(new WicketModule" could give you a list of >> > modules via >> > code completion such as "WicketModuleSpringBeanInjector". the >> advantage >> > is that >> > a casual observer later is going to know how this module is getting >> loaded >> > and when. >> > you also have some idea what modules are available. if they are >> getting >> > auto-loaded >> > you will only know this if you know what's on the classpath >> somehow. the >> > code >> > completion functions as a kind of self-documentation. there are >> probably >> > other ways >> > to do this. i'd just like to find something simpler and less >> automatic. >> > >> > i feel like there's a second issue being tacked on here. is there >> really >> > a need to >> > change authorization to accomodate modules? it seems to work really >> well >> > for me. >> > it's straightforward and there's one place to look to find out how an >> > application is >> > being authorized. >> > >> > >> > igor.vaynberg wrote: >> >> >> >> i disagree. having things explicit is very nice when there is a need >> for >> >> you >> >> to know, but what if there isnt? >> >> >> >> take wicket-spring module. its only service is to make fields >> annotated >> >> with >> >> @SpringBean injectable. why should the user care that this is done >> with >> >> the >> >> componentinstantiationlistener, or what a >> componentinstantiationlistener >> >> is. >> >> >> >> there is also no need to make the user dig in though the docs and >> figure >> >> out >> >> they they need to have >> >> addComponentInstantionListener(new SpringComponentInjector(this)); >> >> >> >> to them its total garbage they just have to paste in. no one cares >> what >> >> it >> >> is, they only care @SpringBean fields are injected. >> >> >> >> so perhaps i should chage "zero-configuration" to "zero-installation". >> >> >> >> same for security >> >> >> >> if i provide a module that provides a couple of annots like @Admin >> @User, >> >> etc and a security strategy for them - why make user go through all >> the >> >> gritty details of installing it. what if they have their own and want >> to >> >> mix >> >> it with the one in the module? they have to do all the wrapping >> >> themselves - >> >> it gets messy and the end result is exactly the same as when the >> module >> >> wouldve installed its own by itself. if we move to veto semantics for >> >> return >> >> values of strategies there is no difference how it is mixed in as long >> as >> >> it >> >> is. >> >> >> >> i dont know. if there is only one way to install something, why not >> have >> >> it >> >> done automatically? >> >> >> >> like i said, just thinking out loud >> >> >> >> -igor >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 2/18/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >>> >> >>> >> >>> I like the idea of snap-in modules of some sort, but I don't >> completely >> >>> understand what you're talking about here and I'm not sure I agree >> with >> >>> what >> >>> all of what I do get. >> >>> >> >>> I'm unsure about auto-installing modules using the classpath. With >> the >> >>> classpath loading, you wind up with a lot of magic going on that you >> >>> don't >> >>> explicitly specify. I find that kind of "zero config" to be >> slippery, >> >>> sometimes surprising and generally harder to manage than simply >> >>> requiring >> >>> a >> >>> single line of code in your application constructor that makes it >> clear >> >>> to >> >>> everyone exactly what is supposed to happen (and when). It is very >> >>> straightforward and self-documenting to explicitly state the >> dependency >> >>> for >> >>> each module you want to use in your app constructor. It's extremely >> >>> hard >> >>> to >> >>> mistake the intention of something like "add(new WhateverModule())". >> >>> You >> >>> don't have to know anything about how Wicket modules might work to >> >>> figure >> >>> it >> >>> out. >> >>> >> >>> I also think that the current approach of having /a/ security >> strategy >> >>> is >> >>> quite elegant and straightforward. The mechanism is extensible by >> >>> explicit >> >>> chaining and I think probably better than a fancy one that has >> locators, >> >>> searching or cascading because you end up with magic again. Saying >> >>> "add(new >> >>> WebApplicationAuthenticator())" (instead of extending >> >>> AuthenticatedWebApplication) lets you to add web application >> >>> authentication >> >>> functionality without having to educate anyone about how it happens. >> >>> >> >>> I think what we should be shooting for is an easy way to use modules >> in >> >>> Wicket that add behavior explicitly in your application >> constructor. I >> >>> think this ought to be some kind of simple and explicit pattern of >> >>> composition. >> >>> >> >>> I like the start of what you're thinking here, but let's be careful >> not >> >>> to >> >>> invent for invention's sake. Wicket would best remain a highly >> >>> predictable >> >>> and simple framework. >> >>> >> >>> >> >>> igor.vaynberg wrote: >> >>> > >> >>> > just thinking out loud... >> >>> > >> >>> > for a long time we have had problems with addons that have their >> own >> >>> > application subclass because if you wanted to use more then one >> addon >> >>> you >> >>> > had to bastardize the code of one and add it to the application >> >>> subclass >> >>> > of >> >>> > the other. recently i refactored wicket-spring to not have its own >> >>> > application subclass, but the user still had to install the >> component >> >>> > injector - and needs to know how to do that. >> >>> > >> >>> > i thought it would be great to have modules that users can install >> >>> that >> >>> > would take place of the module-specific application subclass. and >> then >> >>> i >> >>> > thought about it some more and realized we already have something >> like >> >>> > that. >> >>> > >> >>> > interface wicketmodule extends iinitializer, idestroyer {} >> >>> > >> >>> > and there you have it, a beginnings of a wicket module. i just >> >>> refactored >> >>> > wicket-spring to work like this, it uses an initializer to register >> >>> the >> >>> > springcomponnetinjector so now for user there is >> zero-configuration. >> >>> drop >> >>> > the jar onto the classpath and its ready to go. why didnt i do this >> a >> >>> long >> >>> > time ago? :| >> >>> > >> >>> > now for security stuff we can also do some really cool things. it >> gets >> >>> a >> >>> > bit >> >>> > controversial here but bare with me. what if we let the security >> >>> strategy >> >>> > cascade from session->application->modules and instead of returning >> >>> true >> >>> > or >> >>> > false it returns pass or veto? the controversial bit is removing >> >>> security >> >>> > strategy from a setting and letting session, application, >> wicketmodule >> >>> be >> >>> > able to implement it directly - or implement a locator interface. >> this >> >>> way >> >>> > installing wicket-auth is pretty simple, drop the jar in and create >> >>> your >> >>> > own >> >>> > roles. the module takes care of installing the right security >> >>> strategy, >> >>> > etc. >> >>> > >> >>> > could be cool, the module interface can be extended to handle other >> >>> > usefull >> >>> > callbacks, etc. >> >>> > >> >>> > -igor >> >>> > >> >>> > >> >>> >> >>> -- >> >>> View this message in context: >> >>> http://www.nabble.com/wicket-modules-tf3250868.html#a9037838 >> >>> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >>> >> >>> >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/wicket-modules-tf3250868.html#a9045749 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/wicket-modules-tf3250868.html#a9047743 Sent from the Wicket - Dev mailing list archive at Nabble.com.