Re: WICKET-147 Backport MockWebApplication and WicketTester to 1.x
Sure Eelco On 2/19/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: Hi team, I'm about to finish porting the MockWebApplication and WicketTester refactoring that happened in trunk to branch 1.x. Do you all agree to break the API in branch 1.x WRT WicketTester? BTW the wiki does not mention the API break: http://cwiki.apache.org/WICKET/migrate-20.html This API change will need to be documented here: http://cwiki.apache.org/WICKET/migrate-13.html Cheers, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
WICKET-147 Backport MockWebApplication and WicketTester to 1.x
Hi team, I'm about to finish porting the MockWebApplication and WicketTester refactoring that happened in trunk to branch 1.x. Do you all agree to break the API in branch 1.x WRT WicketTester? BTW the wiki does not mention the API break: http://cwiki.apache.org/WICKET/migrate-20.html This API change will need to be documented here: http://cwiki.apache.org/WICKET/migrate-13.html Cheers, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Questions about SecondLevelCacheSessionStore
On 2/19/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: I know you guys have already thought about/discussed this, but can't you reduce the size of the page map by storing deltas? I thought I saw a thread about it in the dev list archives... What I'm getting at is that if you could significantly reduce the size of the page map, there might not be a compelling reason to store it outside of the session. deltas/changes, whatever you call them, often have references to the page through anonymous classes, etc. so it ends up being the same I beg to differ here. If you don't have to rely on sticky sessions then you get rock-solid failover and can therefore add and remove nodes at will (you're basically failing over constantly under normal operating conditions). The other big advantage is improved resource utilization across the farm. Your load balancers distribute on a request-by-request basis, and that can make a significant difference in overall throughput when compared to distributing on a session-by- session basis. the con is that you lose data-locality in your caches. if you are using something like hibernate or doing caching on your own sticky sessions dramatically improve hit/miss ratio -igor
Re: Questions about SecondLevelCacheSessionStore
I know you guys have already thought about/discussed this, but can't you reduce the size of the page map by storing deltas? I thought I saw a thread about it in the dev list archives... What I'm getting at is that if you could significantly reduce the size of the page map, there might not be a compelling reason to store it outside of the session. On Feb 19, 2007, at 12:24 AM, Johan Compagner wrote: it is not a question about storing the entire session or not. The idea is that the second level cache keeps the session small. Because if we just rely on the session to serialize by the container then how many pages or page versions should we keep in memory? we did see by the AccessStackPageMap which defaults to 7 that they can grow quite large on big pages that are also changing a lot. and also saving just the page is much less then serializing the complete session for sure if we have that 7 page/versions in by default. Even if the session is many times larger than a single page, it *could* be cheaper to write the entire thing to disk or a database when the session goes "idle" than to perform lots of small writes (I assume it's one per request for stateful pages). Eelco already pointed out that I'm making performance assumptions here (and that's totally valid), but it's pretty well known that lots of small disk writes are far less efficient than fewer large writes. It's easy to confirm this with IOMeter and an idle server. the problem is that we are trying to find a balance between session usage and speed. We are still tweaking the Serialization and FileStore implementation as for clustering, i don't think that is a big problem, sticky session is the way to go anyway (i don't believe in the none sticky session variant at all, thats doesn't gain you anything) I beg to differ here. If you don't have to rely on sticky sessions then you get rock-solid failover and can therefore add and remove nodes at will (you're basically failing over constantly under normal operating conditions). The other big advantage is improved resource utilization across the farm. Your load balancers distribute on a request-by-request basis, and that can make a significant difference in overall throughput when compared to distributing on a session-by- session basis. As a practical matter, I'm not sure if it's at all important for a Java web framework to support non-sticky session clustering since Java environments seem to always rely on sticky sessions anyway. I just think the non-sticky approach is too often dismissed based on false assumptions (databases are slow, etc.) and it's certainly not a good thing if SLCSS makes it more difficult to achieve that setup. And then only in the situation where one server goes down and you have a failover AND the next request of a client is the backbutton. Then they will get a page expired They didn't loose the session info, or the current pages of all the current pagemaps only the old pages if you don't share the directory over all the servers. But i don't know if that really gains you anything.. You could drop in a DB save implementation ofcourse if you really need it. johan Totally agree with that. Trading guaranteed retention of old page state for increased load handling and scalability is a clear win. I really appreciate your and Eelco's explanations. I'm still skeptical, but I'm far less afraid of what you're doing now ;) I'd like to run some tests when the SLCSS file store gets to a point where you're reasonably happy with the performance. It will be difficult to compare it to Tomcat's PersistentManager, but I'll try to come up with something meaningful. -Ryan On 2/19/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: Hi Wicket devs, Sorry for jumping in on this list since I'm barely a Wicket user (much less a developer), but I wanted to share some thoughts/ questions regarding your work on the SecondLevelCacheSessionStore. 1) If the main purpose is to move sessions out of RAM and onto disk or a database, aren't you largely duplicating functionality already (and probably more appropriately) provided at the container level (e.g. Tomcat's PersistentManager)? I realize that SecondLevelCacheSessionStore moves only part of a session out of memory rather than the whole thing and so, in effect, keeps the literal session size small. But why is it necessarily better to swap a part of every session in and out of RAM vs swapping entire idle sessions out of RAM and back in only when needed (this is PersistentManager's strategy)? It seems like the PersistentManager approach would be more efficient (less disk writes) and should provide similar RAM savings in the long run. 2) Doesn't the SecondLevelCacheSessionStore create another data repository that must be shared or distributed across clustered application servers? I mean, in addition to normal session clustering wouldn't one also have to cluster wh
Re: this has to be easier.....
that would be the best thing
because doing it serverside is a bad thing
because the user could already be jumping to another field and then
it always is restored to the one you think it is on the serverside
The best thing is attaching it on the onfocus event on the client side
and record it.
and after a ajax request always do onfocus on this except when we
do call it on the server side explicitly !
johan
On 2/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
if you want something specific then you can already do ajaxtarget.focus()
ajaxtarget.appendjavascript("document.getelementbyid
('"+c.getmarkupid()+"').focus();")
if you want this more general so it works transparently its trickier. then
like you said you need to keep track of focus in a var and append it to
ajax
urls. which we can do. this new event stuff allows us to attach onfocus
event to everything so we can track it easily.
-igor
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> What i want is this:
>
> component.add(new ajaxbehaviour("onfocus"))
>
> then in the onEvent i do
>
> ajaxtarget.add(component)
>
> but then the focus is gone.
>
> So what should happen is that the focus is tracked on the page
> and when a ajax request comes back then it does focus() again.
>
> What we also can do is that i do it on the server side:
>
> onEvent(AjaxTarget)
> {
> ajaxtarget.add(component);
> ajaxtarget.setFocus(component,ignoreEvents)
> }
>
> then i can controll it on the serverside completely
>
> johan
>
> On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > really?
> > matej, do tell!
> >
> > i can work on it also because i really need it :)
> >
> > johan
> >
> >
> > On 2/19/07, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> > >
> > > yes, tracking is easy with our new event thing :)
> > >
> > > get on it matej!
> > >
> > > -igor
> > >
> > >
> > > On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > attach an onfocus event on all focusable components
> > > > then have a javascript variable in the page that gets that
assigned
> > > >
> > > > onfocus="lastfocuscomponent=this;MaybeAnAjaxCall">
> > > >
> > > > then i prepend a script that uses that lastfocuscomponent variable
> to
> > > get
> > > > the focus back in.
> > > > Ofcourse the onFocus event should be cleared or ignored for one
time
> > > if
> > > > there is an MaybeAnAjaxCall ...
> > > >
> > > > so the tracking is pretty easy, it is the handling after that.
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > the question is, how exactly you want to track the changing of
> > > focus?
> > > > >
> > > > > -Matej
> > > > >
> > > > > Johan Compagner wrote:
> > > > > > if i have an ajax behavior on a text field event: onfocus
> > > > > >
> > > > > > and i set the background and then add that component to the
ajax
> > > event
> > > > > for
> > > > > > redraw
> > > > > > then i loose focus. Ofcourse there are ways to go around
that..
> > > > > > for example i could just write the style tag out instead of
the
> > > > complete
> > > > > > component.
> > > > > > But what when it gets a bit harder? (like a parent is altered
> and
> > > > > > rerendered)
> > > > > >
> > > > > > i could attach a behavior (onfocus) to all components and let
> them
> > > set
> > > > > > the last know focus component. And then append to every ajax
> call
> > > a
> > > > > script:
> > > > > > if (lastfocuscomponent) lastfocuscomponent.focus();
> > > > > > the problem with this is that this focus gained should be
> ignored
> > > if
> > > > > there
> > > > > > was an ajax focus
> > > > > > gained event that the server wants to receive , else you could
> > > have an
> > > > > > endless loop.
> > > > > >
> > > > > > Can't wicket do this for the developer?
> > > > > > so track the latest focus component when an ajax call is
> > > dispatched.
> > > > And
> > > > > > when it returns
> > > > > > set the focus back (and then ignore that focus gained
event...)
> > > > > >
> > > > > > johan
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: Line endings, again [Re: svn commit: r509300 - in /incubator/wicket/branches/wicket-1.x]
i have no idea if i do it correctly now, i dropped that file (that was reported here) into my svn dir But i don't know if that is the right file and if that svn dir is used for eclipse (using the binary bindings) johan On 2/19/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: * Jean-Baptiste Quenot: > Author: jbq > Date: Mon Feb 19 11:05:50 2007 > New Revision: 509300 > > URL: http://svn.apache.org/viewvc?view=rev&rev=509300 > Log: > Adding missing SVN properties > > Modified: > incubator/wicket/branches/wicket-1.x/wicket-threadtest/src/main/java/wicket/threadtest/StartJetty.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/html/WicketEventReference.java (contents, props changed) > incubator/wicket/branches/wicket-1.x /wicket/src/main/java/wicket/markup/html/wicket-event.js (contents, props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/TestFilePageStore.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/WebRequestCycleProcessor.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/portlet/AbstractPortletRequestCycleProcessor.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressingWebCodingStrategy.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressingWebRequestProcessor.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressor.java (props changed) > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/request/AbstractRequestCycleProcessor.java (props changed) Hi Wicket Team, Some of you still have bad setups, could you please make sure that your SVN clients are configured correctly? Did you make sure to install Subversion binaries for your OS? Did you add the proper configuration in your home directory? If you need help in setting-up the environment, please tell which OS you run and which SVN tool (+version number) you use. If you are reluctant to change your development environment and have good reasons for that, would you be kind enough to contact [EMAIL PROTECTED] in order to find a solution that works for all of us? Maybe they have the ability to do something at the server-side, who knows? Thanks! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: this has to be easier.....
if you want something specific then you can already do ajaxtarget.focus()
ajaxtarget.appendjavascript("document.getelementbyid
('"+c.getmarkupid()+"').focus();")
if you want this more general so it works transparently its trickier. then
like you said you need to keep track of focus in a var and append it to ajax
urls. which we can do. this new event stuff allows us to attach onfocus
event to everything so we can track it easily.
-igor
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
What i want is this:
component.add(new ajaxbehaviour("onfocus"))
then in the onEvent i do
ajaxtarget.add(component)
but then the focus is gone.
So what should happen is that the focus is tracked on the page
and when a ajax request comes back then it does focus() again.
What we also can do is that i do it on the server side:
onEvent(AjaxTarget)
{
ajaxtarget.add(component);
ajaxtarget.setFocus(component,ignoreEvents)
}
then i can controll it on the serverside completely
johan
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> really?
> matej, do tell!
>
> i can work on it also because i really need it :)
>
> johan
>
>
> On 2/19/07, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> >
> > yes, tracking is easy with our new event thing :)
> >
> > get on it matej!
> >
> > -igor
> >
> >
> > On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > >
> > > attach an onfocus event on all focusable components
> > > then have a javascript variable in the page that gets that assigned
> > >
> > >
> > >
> > > then i prepend a script that uses that lastfocuscomponent variable
to
> > get
> > > the focus back in.
> > > Ofcourse the onFocus event should be cleared or ignored for one time
> > if
> > > there is an MaybeAnAjaxCall ...
> > >
> > > so the tracking is pretty easy, it is the handling after that.
> > >
> > > johan
> > >
> > >
> > >
> > > On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > > >
> > > > the question is, how exactly you want to track the changing of
> > focus?
> > > >
> > > > -Matej
> > > >
> > > > Johan Compagner wrote:
> > > > > if i have an ajax behavior on a text field event: onfocus
> > > > >
> > > > > and i set the background and then add that component to the ajax
> > event
> > > > for
> > > > > redraw
> > > > > then i loose focus. Ofcourse there are ways to go around that..
> > > > > for example i could just write the style tag out instead of the
> > > complete
> > > > > component.
> > > > > But what when it gets a bit harder? (like a parent is altered
and
> > > > > rerendered)
> > > > >
> > > > > i could attach a behavior (onfocus) to all components and let
them
> > set
> > > > > the last know focus component. And then append to every ajax
call
> > a
> > > > script:
> > > > > if (lastfocuscomponent) lastfocuscomponent.focus();
> > > > > the problem with this is that this focus gained should be
ignored
> > if
> > > > there
> > > > > was an ajax focus
> > > > > gained event that the server wants to receive , else you could
> > have an
> > > > > endless loop.
> > > > >
> > > > > Can't wicket do this for the developer?
> > > > > so track the latest focus component when an ajax call is
> > dispatched.
> > > And
> > > > > when it returns
> > > > > set the focus back (and then ignore that focus gained event...)
> > > > >
> > > > > johan
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
Re: this has to be easier.....
What i want is this:
component.add(new ajaxbehaviour("onfocus"))
then in the onEvent i do
ajaxtarget.add(component)
but then the focus is gone.
So what should happen is that the focus is tracked on the page
and when a ajax request comes back then it does focus() again.
What we also can do is that i do it on the server side:
onEvent(AjaxTarget)
{
ajaxtarget.add(component);
ajaxtarget.setFocus(component,ignoreEvents)
}
then i can controll it on the serverside completely
johan
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
really?
matej, do tell!
i can work on it also because i really need it :)
johan
On 2/19/07, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
>
> yes, tracking is easy with our new event thing :)
>
> get on it matej!
>
> -igor
>
>
> On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > attach an onfocus event on all focusable components
> > then have a javascript variable in the page that gets that assigned
> >
> >
> >
> > then i prepend a script that uses that lastfocuscomponent variable to
> get
> > the focus back in.
> > Ofcourse the onFocus event should be cleared or ignored for one time
> if
> > there is an MaybeAnAjaxCall ...
> >
> > so the tracking is pretty easy, it is the handling after that.
> >
> > johan
> >
> >
> >
> > On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > >
> > > the question is, how exactly you want to track the changing of
> focus?
> > >
> > > -Matej
> > >
> > > Johan Compagner wrote:
> > > > if i have an ajax behavior on a text field event: onfocus
> > > >
> > > > and i set the background and then add that component to the ajax
> event
> > > for
> > > > redraw
> > > > then i loose focus. Ofcourse there are ways to go around that..
> > > > for example i could just write the style tag out instead of the
> > complete
> > > > component.
> > > > But what when it gets a bit harder? (like a parent is altered and
> > > > rerendered)
> > > >
> > > > i could attach a behavior (onfocus) to all components and let them
> set
> > > > the last know focus component. And then append to every ajax call
> a
> > > script:
> > > > if (lastfocuscomponent) lastfocuscomponent.focus();
> > > > the problem with this is that this focus gained should be ignored
> if
> > > there
> > > > was an ajax focus
> > > > gained event that the server wants to receive , else you could
> have an
> > > > endless loop.
> > > >
> > > > Can't wicket do this for the developer?
> > > > so track the latest focus component when an ajax call is
> dispatched.
> > And
> > > > when it returns
> > > > set the focus back (and then ignore that focus gained event...)
> > > >
> > > > johan
> > > >
> > >
> > >
> > >
> > >
> >
>
Re: this has to be easier.....
well we have the new Wicket.Event thing you can use to install events. so really what you do is create a javascript variable, then install a 'domready' event that traverses the dom tree looks for formcomponents and adds an onfocus event. then we just need to make the ajax stuff aware of this. see wicket-event.js and new method in iheaderresponse i have also been bitten by this, and recently there was a thread on the list about this as well. -igor On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: really? matej, do tell! i can work on it also because i really need it :) johan On 2/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > yes, tracking is easy with our new event thing :) > > get on it matej! > > -igor > > > On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > attach an onfocus event on all focusable components > > then have a javascript variable in the page that gets that assigned > > > > > > > > then i prepend a script that uses that lastfocuscomponent variable to > get > > the focus back in. > > Ofcourse the onFocus event should be cleared or ignored for one time if > > there is an MaybeAnAjaxCall ... > > > > so the tracking is pretty easy, it is the handling after that. > > > > johan > > > > > > > > On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > > > > the question is, how exactly you want to track the changing of focus? > > > > > > -Matej > > > > > > Johan Compagner wrote: > > > > if i have an ajax behavior on a text field event: onfocus > > > > > > > > and i set the background and then add that component to the ajax > event > > > for > > > > redraw > > > > then i loose focus. Ofcourse there are ways to go around that.. > > > > for example i could just write the style tag out instead of the > > complete > > > > component. > > > > But what when it gets a bit harder? (like a parent is altered and > > > > rerendered) > > > > > > > > i could attach a behavior (onfocus) to all components and let them > set > > > > the last know focus component. And then append to every ajax call a > > > script: > > > > if (lastfocuscomponent) lastfocuscomponent.focus(); > > > > the problem with this is that this focus gained should be ignored if > > > there > > > > was an ajax focus > > > > gained event that the server wants to receive , else you could have > an > > > > endless loop. > > > > > > > > Can't wicket do this for the developer? > > > > so track the latest focus component when an ajax call is dispatched. > > And > > > > when it returns > > > > set the focus back (and then ignore that focus gained event...) > > > > > > > > johan > > > > > > > > > > > > > > > > > > >
Re: this has to be easier.....
really? matej, do tell! i can work on it also because i really need it :) johan On 2/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: yes, tracking is easy with our new event thing :) get on it matej! -igor On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > attach an onfocus event on all focusable components > then have a javascript variable in the page that gets that assigned > > > > then i prepend a script that uses that lastfocuscomponent variable to get > the focus back in. > Ofcourse the onFocus event should be cleared or ignored for one time if > there is an MaybeAnAjaxCall ... > > so the tracking is pretty easy, it is the handling after that. > > johan > > > > On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > > the question is, how exactly you want to track the changing of focus? > > > > -Matej > > > > Johan Compagner wrote: > > > if i have an ajax behavior on a text field event: onfocus > > > > > > and i set the background and then add that component to the ajax event > > for > > > redraw > > > then i loose focus. Ofcourse there are ways to go around that.. > > > for example i could just write the style tag out instead of the > complete > > > component. > > > But what when it gets a bit harder? (like a parent is altered and > > > rerendered) > > > > > > i could attach a behavior (onfocus) to all components and let them set > > > the last know focus component. And then append to every ajax call a > > script: > > > if (lastfocuscomponent) lastfocuscomponent.focus(); > > > the problem with this is that this focus gained should be ignored if > > there > > > was an ajax focus > > > gained event that the server wants to receive , else you could have an > > > endless loop. > > > > > > Can't wicket do this for the developer? > > > so track the latest focus component when an ajax call is dispatched. > And > > > when it returns > > > set the focus back (and then ignore that focus gained event...) > > > > > > johan > > > > > > > > > > > >
Re: i think i have asked/proposed this before: IBehavior.isEnabled();
not a flag just a overridable method johan On 2/19/07, James McLaughlin <[EMAIL PROTECTED]> wrote: Fwiw, I would love to have this. But if you are going to add a flag to disable a behavior, it doesn't seem like too much more work to add a mechanism to remove it as well. On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > Any objections now? (for 1.3 and 2.0) > > Because you can't remove a behavior from a component and now you > also can't dynamically disabled one either. So thats a bit annoying. > > johan >
Re: [Vote] wicket modules
yes, on large scale maybe. i am talking about small self-contained modules. and this isnt really InstallHook :) not all approaches like this are bad. eclipse/osgi is one example where there are a ton of tiny modules that work together really well. -igor On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: we do disagree. i don't believe in the ability of module designers to create modules that seamlessly interoperate. we had this problem almost 20 years ago with windows hooks and it was a complete disaster. i've seen it repeated in other places in oo systems and it's a mess there too. i think you want to provide a mechanism where someone (possibly the authors of one or more modules, but ultimately the user if need be) can very explicitly determine how those modules interoperate. if you make the glue explicit you make interoperation a little more verbose, but at that expense it is extremely simple and deterministic. when you start to have really difficult problems or even unresolvable conflicts between what modules need in terms of resources, you will eventually discover the limits of automatic mixing. the results have not been pretty in the past. igor.vaynberg wrote: > > see this is where we would disagree. if a strategy adds some annots for > you > to use the compoudness is seamless. as long as the strategy in the module > is > designed as an "mixin" it should work just fine no matter what user has > got > going. thats why its an interface :) > > -igor > > > On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> set once and exception does work because only the module sets it. >> >> trying to make multiple strategies co-operate seamlessly is a losing >> battle that i have seen many times before. i think when you want to >> make that happen it's better to explicitly code a compound strategy >> (or use the simple compound strategy provided already). >> >> >> igor.vaynberg wrote: >> > >> > 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: >> >> >> >> >> >> >> >> >> >> >> >> h. 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
Re: [Vote] wicket modules
we do disagree. i don't believe in the ability of module designers to create modules that seamlessly interoperate. we had this problem almost 20 years ago with windows hooks and it was a complete disaster. i've seen it repeated in other places in oo systems and it's a mess there too. i think you want to provide a mechanism where someone (possibly the authors of one or more modules, but ultimately the user if need be) can very explicitly determine how those modules interoperate. if you make the glue explicit you make interoperation a little more verbose, but at that expense it is extremely simple and deterministic. when you start to have really difficult problems or even unresolvable conflicts between what modules need in terms of resources, you will eventually discover the limits of automatic mixing. the results have not been pretty in the past. igor.vaynberg wrote: > > see this is where we would disagree. if a strategy adds some annots for > you > to use the compoudness is seamless. as long as the strategy in the module > is > designed as an "mixin" it should work just fine no matter what user has > got > going. thats why its an interface :) > > -igor > > > On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> set once and exception does work because only the module sets it. >> >> trying to make multiple strategies co-operate seamlessly is a losing >> battle that i have seen many times before. i think when you want to >> make that happen it's better to explicitly code a compound strategy >> (or use the simple compound strategy provided already). >> >> >> igor.vaynberg wrote: >> > >> > 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: >> >> >> >> >> >> >> >> >> >> >> >> h. 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. >> >> >> > >> >> >> >
Line endings, again [Re: svn commit: r509300 - in /incubator/wicket/branches/wicket-1.x]
* Jean-Baptiste Quenot: > Author: jbq > Date: Mon Feb 19 11:05:50 2007 > New Revision: 509300 > > URL: http://svn.apache.org/viewvc?view=rev&rev=509300 > Log: > Adding missing SVN properties > > Modified: > > incubator/wicket/branches/wicket-1.x/wicket-threadtest/src/main/java/wicket/threadtest/StartJetty.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/html/WicketEventReference.java >(contents, props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/markup/html/wicket-event.js >(contents, props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/TestFilePageStore.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/WebRequestCycleProcessor.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/portlet/AbstractPortletRequestCycleProcessor.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressingWebCodingStrategy.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressingWebRequestProcessor.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/request/urlcompressing/UrlCompressor.java >(props changed) > > incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/request/AbstractRequestCycleProcessor.java >(props changed) Hi Wicket Team, Some of you still have bad setups, could you please make sure that your SVN clients are configured correctly? Did you make sure to install Subversion binaries for your OS? Did you add the proper configuration in your home directory? If you need help in setting-up the environment, please tell which OS you run and which SVN tool (+version number) you use. If you are reluctant to change your development environment and have good reasons for that, would you be kind enough to contact [EMAIL PROTECTED] in order to find a solution that works for all of us? Maybe they have the ability to do something at the server-side, who knows? Thanks! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [Vote] wicket modules
see this is where we would disagree. if a strategy adds some annots for you to use the compoudness is seamless. as long as the strategy in the module is designed as an "mixin" it should work just fine no matter what user has got going. thats why its an interface :) -igor On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: set once and exception does work because only the module sets it. trying to make multiple strategies co-operate seamlessly is a losing battle that i have seen many times before. i think when you want to make that happen it's better to explicitly code a compound strategy (or use the simple compound strategy provided already). igor.vaynberg wrote: > > 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: >> >> >> >> >> >> >> >> h. 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
Re: [Vote] wicket modules
set once and exception does work because only the module sets it. trying to make multiple strategies co-operate seamlessly is a losing battle that i have seen many times before. i think when you want to make that happen it's better to explicitly code a compound strategy (or use the simple compound strategy provided already). igor.vaynberg wrote: > > 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: >> >> >> >> >> >> >> >> h. 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
Re: [Vote] wicket modules
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: >> >> >> >> h. 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
Re: [Vote] wicket modules
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: >> >> >> >> h. 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 ge
Re: [Vote] wicket modules
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: h. 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 havin
Re: i think i have asked/proposed this before: IBehavior.isEnabled();
+1 -igor On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: Any objections now? (for 1.3 and 2.0) Because you can't remove a behavior from a component and now you also can't dynamically disabled one either. So thats a bit annoying. johan
Re: this has to be easier.....
yes, tracking is easy with our new event thing :) get on it matej! -igor On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: attach an onfocus event on all focusable components then have a javascript variable in the page that gets that assigned then i prepend a script that uses that lastfocuscomponent variable to get the focus back in. Ofcourse the onFocus event should be cleared or ignored for one time if there is an MaybeAnAjaxCall ... so the tracking is pretty easy, it is the handling after that. johan On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > the question is, how exactly you want to track the changing of focus? > > -Matej > > Johan Compagner wrote: > > if i have an ajax behavior on a text field event: onfocus > > > > and i set the background and then add that component to the ajax event > for > > redraw > > then i loose focus. Ofcourse there are ways to go around that.. > > for example i could just write the style tag out instead of the complete > > component. > > But what when it gets a bit harder? (like a parent is altered and > > rerendered) > > > > i could attach a behavior (onfocus) to all components and let them set > > the last know focus component. And then append to every ajax call a > script: > > if (lastfocuscomponent) lastfocuscomponent.focus(); > > the problem with this is that this focus gained should be ignored if > there > > was an ajax focus > > gained event that the server wants to receive , else you could have an > > endless loop. > > > > Can't wicket do this for the developer? > > so track the latest focus component when an ajax call is dispatched. And > > when it returns > > set the focus back (and then ignore that focus gained event...) > > > > johan > > > > > >
Re: VOTE: apply WICKET-298 to Wicket 1.2.x
+1 but i still think an exception is better -igor On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: +1 On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > I'd like to apply the fix for issue WICKET-298 > > (http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The > > fix is completely transparent/ doesn't break the API. > > +1 > > Eelco >
Re: i think i have asked/proposed this before: IBehavior.isEnabled();
Fwiw, I would love to have this. But if you are going to add a flag to disable a behavior, it doesn't seem like too much more work to add a mechanism to remove it as well. On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: Any objections now? (for 1.3 and 2.0) Because you can't remove a behavior from a component and now you also can't dynamically disabled one either. So thats a bit annoying. johan
Re: [Vote] wicket modules
yeah, we never intended for base class inheritance to be our design here. it just ended up that way because we ran out of time and it served as an example people could cut and paste from... Erik van Oosten wrote: > > Hi Igor, Jonathan, > > Good idea, I have never liked the way I had to inherit from the > application base classes. > > From a users point of view, I agree with Jonathan on the config thing, > I'd rather have one line of code somewhere (on a predictable place, e.g. > application#init). This also makes it immediately clear when it does not > work: you get a classnotfoundexception. When it is implicit you can > search for hours before you realize that a jar is missing. Especially > when you are talking about annotations. > > Regards, > Erik. > > > Jonathan Locke 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. >> > > -- > Erik van Oosten > http://www.day-to-day-stuff.blogspot.com/ > > > -- View this message in context: http://www.nabble.com/wicket-modules-tf3250868.html#a9045750 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] wicket modules
h. 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 >>>
Re: [Vote] wicket modules
yes. the generalization is what i'm more afraid of here...
igor.vaynberg wrote:
>
> i guess another thing to consider is that in both of these cases there are
> no sideeffects of installing these things. if you dont use the annots
> everything is as it was before. so its not like you drop this file in and
> all of a sudden things get weird.
>
> -igor
>
>
> On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> 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
Re: [Vote] wicket modules
if you're installing them explicitly, you have a nice type-safe constructor with code completion help. and if you do need a config parameter later you can add it and everyone on earth will know what happened. igor.vaynberg wrote: > > unlike jmx this isnt part of core, so if you dont want to activate it dont > put it on your classpath. furthermore, like i said, there are no > sideffects > in activating it. > > the only downside i can think of is how to configure these things. usually > you would do it when installing them, but when they install themselves it > gets trickier. in case of wicket-spring there is no configuration > > -igor > > > On 2/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> >> I like the idea. It's very much like the IInitializer idea anyway, and >> I agree it's funny we didn't actually think of this before. The only >> catch with auto-discovery/config/whateveryoucallit is - like we can >> see now with JMX - what do you do when people want it to be not >> activated. If we can have that as part of the pattern, I'm all for it. >> >> Eelco >> >> >> On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> 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 si
Re: [Vote] wicket modules
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.
Re: DatePicker (then new one in wicket-datetime)
It looks like you can also use things like: myCal.outerContainer.style.top=100px; myCal.outerContainer.style.left=100px; when initializing the calendar widget. Maybe you could investigate the YUI widget a bit (and their mailing lists). See http://developer.yahoo.com/yui/calendar/ and http://tech.groups.yahoo.com/group/ydn-javascript/ Eelco On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: Filtered! So i couldn't see that nice picture :( How do you place the field itself? For servoy we use all CSS fixed positioning Then it doesn't work. I have to include that left:xxx else it will be completely in the front. johan On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > that value is just something that works for my field because that field > was > > almost that big. > > But i don't want it to be after the field, but i want it to be over the > > field bu then completely to the right. > > > > But i think we just need to have a over ridable method yes. But what to > > extract? > > the complete img? or just the style? > > It's the div, not the image you're after here, correct? The image is > for the datepicker icon, so that would be a separate call. > > The default actually works great for me, as it always places the > calendar right under the text field I'm coupling it to, it's right > aligned to the right of the field (see attached image if that doesn't > get filtered by apache). > > Eelco >
Re: DatePicker (then new one in wicket-datetime)
Frank, you are using this new datepicker... how do you use it? Eelco On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: Filtered! So i couldn't see that nice picture :( How do you place the field itself? For servoy we use all CSS fixed positioning Then it doesn't work. I have to include that left:xxx else it will be completely in the front. johan On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > that value is just something that works for my field because that field > was > > almost that big. > > But i don't want it to be after the field, but i want it to be over the > > field bu then completely to the right. > > > > But i think we just need to have a over ridable method yes. But what to > > extract? > > the complete img? or just the style? > > It's the div, not the image you're after here, correct? The image is > for the datepicker icon, so that would be a separate call. > > The default actually works great for me, as it always places the > calendar right under the text field I'm coupling it to, it's right > aligned to the right of the field (see attached image if that doesn't > get filtered by apache). > > Eelco >
i think i have asked/proposed this before: IBehavior.isEnabled();
Any objections now? (for 1.3 and 2.0) Because you can't remove a behavior from a component and now you also can't dynamically disabled one either. So thats a bit annoying. johan
Re: DatePicker (then new one in wicket-datetime)
Filtered! So i couldn't see that nice picture :( How do you place the field itself? For servoy we use all CSS fixed positioning Then it doesn't work. I have to include that left:xxx else it will be completely in the front. johan On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > that value is just something that works for my field because that field was > almost that big. > But i don't want it to be after the field, but i want it to be over the > field bu then completely to the right. > > But i think we just need to have a over ridable method yes. But what to > extract? > the complete img? or just the style? It's the div, not the image you're after here, correct? The image is for the datepicker icon, so that would be a separate call. The default actually works great for me, as it always places the calendar right under the text field I'm coupling it to, it's right aligned to the right of the field (see attached image if that doesn't get filtered by apache). Eelco
Re: this has to be easier.....
attach an onfocus event on all focusable components then have a javascript variable in the page that gets that assigned then i prepend a script that uses that lastfocuscomponent variable to get the focus back in. Ofcourse the onFocus event should be cleared or ignored for one time if there is an MaybeAnAjaxCall ... so the tracking is pretty easy, it is the handling after that. johan On 2/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote: the question is, how exactly you want to track the changing of focus? -Matej Johan Compagner wrote: > if i have an ajax behavior on a text field event: onfocus > > and i set the background and then add that component to the ajax event for > redraw > then i loose focus. Ofcourse there are ways to go around that.. > for example i could just write the style tag out instead of the complete > component. > But what when it gets a bit harder? (like a parent is altered and > rerendered) > > i could attach a behavior (onfocus) to all components and let them set > the last know focus component. And then append to every ajax call a script: > if (lastfocuscomponent) lastfocuscomponent.focus(); > the problem with this is that this focus gained should be ignored if there > was an ajax focus > gained event that the server wants to receive , else you could have an > endless loop. > > Can't wicket do this for the developer? > so track the latest focus component when an ajax call is dispatched. And > when it returns > set the focus back (and then ignore that focus gained event...) > > johan >
Re: this has to be easier.....
the question is, how exactly you want to track the changing of focus? -Matej Johan Compagner wrote: if i have an ajax behavior on a text field event: onfocus and i set the background and then add that component to the ajax event for redraw then i loose focus. Ofcourse there are ways to go around that.. for example i could just write the style tag out instead of the complete component. But what when it gets a bit harder? (like a parent is altered and rerendered) i could attach a behavior (onfocus) to all components and let them set the last know focus component. And then append to every ajax call a script: if (lastfocuscomponent) lastfocuscomponent.focus(); the problem with this is that this focus gained should be ignored if there was an ajax focus gained event that the server wants to receive , else you could have an endless loop. Can't wicket do this for the developer? so track the latest focus component when an ajax call is dispatched. And when it returns set the focus back (and then ignore that focus gained event...) johan
Re: VOTE: apply issue WICKET-215 to 1.2.x
Can't you mention the issue in some kind of «release errata» with a link to JIRA? Sure. I'll happily keep that for Martijn to do. I'm done with this issue. Eelco
Re: DatePicker (then new one in wicket-datetime)
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote: that value is just something that works for my field because that field was almost that big. But i don't want it to be after the field, but i want it to be over the field bu then completely to the right. But i think we just need to have a over ridable method yes. But what to extract? the complete img? or just the style? It's the div, not the image you're after here, correct? The image is for the datepicker icon, so that would be a separate call. The default actually works great for me, as it always places the calendar right under the text field I'm coupling it to, it's right aligned to the right of the field (see attached image if that doesn't get filtered by apache). Eelco
Re: VOTE: apply WICKET-298 to Wicket 1.2.x
+1 On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I'd like to apply the fix for issue WICKET-298 > (http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The > fix is completely transparent/ doesn't break the API. +1 Eelco
this has to be easier.....
if i have an ajax behavior on a text field event: onfocus and i set the background and then add that component to the ajax event for redraw then i loose focus. Ofcourse there are ways to go around that.. for example i could just write the style tag out instead of the complete component. But what when it gets a bit harder? (like a parent is altered and rerendered) i could attach a behavior (onfocus) to all components and let them set the last know focus component. And then append to every ajax call a script: if (lastfocuscomponent) lastfocuscomponent.focus(); the problem with this is that this focus gained should be ignored if there was an ajax focus gained event that the server wants to receive , else you could have an endless loop. Can't wicket do this for the developer? so track the latest focus component when an ajax call is dispatched. And when it returns set the focus back (and then ignore that focus gained event...) johan
Re: VOTE: apply issue WICKET-215 to 1.2.x
* Eelco Hillenius: > That's my point: they can't be depending on it, as it doesn't > work. At all. Your application wouldn't even start up if you > would use it as it would throw an exception that the session > doesn't exist. And as no-one can even use it, it cannot be a > real API break. Can't you mention the issue in some kind of « release errata » with a link to JIRA? -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: DatePicker (then new one in wicket-datetime)
that value is just something that works for my field because that field was
almost that big.
But i don't want it to be after the field, but i want it to be over the
field bu then completely to the right.
But i think we just need to have a over ridable method yes. But what to
extract?
the complete img? or just the style?
johan
On 2/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
So this: "left:140px;" <--
is the difference, correct?
I guess the thing to do here is to append the div and maybe the image
in a separate overridable methods.
Eelco
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> i see this in that behavior:
>
> public void onRendered(Component component) {
> super.onRendered(component);
> // Append the span and img icon right after the rendering of the
> // component. Not as pretty as working with a panel etc, but
works
> // for behaviors and is more efficient
> Response response = component.getResponse();
> response
> .write("\n 9;position:absolute;\" id=\"");
> response.write(getCalendarMarkupId());
> response
> .write("\"> none;\" id=\"");
> response.write(getIconId());
> response.write("\" src=\"");
> CharSequence iconUrl = getIconUrl();
> response.write(Strings.escapeMarkup(iconUrl != null ? iconUrl
> .toString() : ""));
> response.write("\" />");
> }
>
> but that doesnt work at my place, because everything is position in css.
> this works for me: (as an example if the component had a width of 140px
)
>
> public void onRendered(Component component) {
> super.onRendered(component);
> // Append the span and img icon right after the rendering of the
> // component. Not as pretty as working with a panel etc, but
works
> // for behaviors and is more efficient
> Response response = component.getResponse();
> response
> .write("\n 9;position:absolute;\" id=\"");
> response.write(getCalendarMarkupId());
> response
> .write("\"> none;position:absolute;left:140px;\" id=\"");
> response.write(getIconId());
> response.write("\" src=\"");
> CharSequence iconUrl = getIconUrl();
> response.write(Strings.escapeMarkup(iconUrl != null ? iconUrl
> .toString() : ""));
> response.write("\" />");
> }
>
>
> ofcourse i can override the complete onRendered again and do that
> implementation.
> or we give a few more call backs like generateImgTag()??
>
> Also the popup when i click on the img is to small. for example i miss
the
> arrow button to scroll forward in the months
> Where is that specified?
>
> johan
>
Re: [Vote] wicket modules
On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: unlike jmx this isnt part of core, so if you dont want to activate it dont put it on your classpath. furthermore, like i said, there are no sideffects in activating it. JMX isn't part of core for 1.3, which was the version I had in mind when I made the comment. But even then, you would still have to provide a way to turn it off 'by hand'. You might not want to use the functionality of a module, but still need to include it because otherwise your app won't compile. For instance. The point is that you need an ultimate override. Eelco
Re: DatePicker (then new one in wicket-datetime)
So this: "left:140px;" <--
is the difference, correct?
I guess the thing to do here is to append the div and maybe the image
in a separate overridable methods.
Eelco
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
i see this in that behavior:
public void onRendered(Component component) {
super.onRendered(component);
// Append the span and img icon right after the rendering of the
// component. Not as pretty as working with a panel etc, but works
// for behaviors and is more efficient
Response response = component.getResponse();
response
.write("\n ");
}
but that doesnt work at my place, because everything is position in css.
this works for me: (as an example if the component had a width of 140px )
public void onRendered(Component component) {
super.onRendered(component);
// Append the span and img icon right after the rendering of the
// component. Not as pretty as working with a panel etc, but works
// for behaviors and is more efficient
Response response = component.getResponse();
response
.write("\n ");
}
ofcourse i can override the complete onRendered again and do that
implementation.
or we give a few more call backs like generateImgTag()??
Also the popup when i click on the img is to small. for example i miss the
arrow button to scroll forward in the months
Where is that specified?
johan
Re: DateTimeField.updateModel() method
Yep. Thanks.
Eelco
On 2/19/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
shouldn't this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
try {
TimeZone zone = getClientTimeZone();
if (zone != null) {
date.setZone(DateTimeZone.forTimeZone(zone));
}
if (hours != null) {
date.set(DateTimeFieldType.hourOfHalfday(), hours
.intValue());
date.setMinuteOfHour((minutes != null) ?
minutes.intValue()
: 0);
}
if (amOrPm == AM_PM.PM) {
date.set(DateTimeFieldType.halfdayOfDay(), 1);
} else {
date.set(DateTimeFieldType.halfdayOfDay(), 0);
}
} catch (RuntimeException e) {
DateTimeField.this.error(e.getMessage());
invalid();
}
// the date will be in the server's timezone
Date d = date.toDate();
setModelObject(d);
} else {
setModelObject(null);
}
}
be this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
try {
TimeZone zone = getClientTimeZone();
if (zone != null) {
date.setZone(DateTimeZone.forTimeZone(zone));
}
if (hours != null) {
date.set(DateTimeFieldType.hourOfHalfday(), hours
.intValue());
date.setMinuteOfHour((minutes != null) ?
minutes.intValue()
: 0);
}
if (amOrPm == AM_PM.PM) {
date.set(DateTimeFieldType.halfdayOfDay(), 1);
} else {
date.set(DateTimeFieldType.halfdayOfDay(), 0);
}
// the date will be in the server's timezone
Date d = date.toDate();
setModelObject(d);
} catch (RuntimeException e) {
DateTimeField.this.error(e.getMessage());
invalid();
}
} else {
setModelObject(null);
}
}
So only set the model object to the date if there is no exception?
Re: VOTE: apply WICKET-298 to Wicket 1.2.x
I'd like to apply the fix for issue WICKET-298 (http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The fix is completely transparent/ doesn't break the API. +1 Eelco
VOTE: apply WICKET-298 to Wicket 1.2.x
I'd like to apply the fix for issue WICKET-298 (http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The fix is completely transparent/ doesn't break the API. Eelco
DateTimeField.updateModel() method
shouldn't this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
try {
TimeZone zone = getClientTimeZone();
if (zone != null) {
date.setZone(DateTimeZone.forTimeZone(zone));
}
if (hours != null) {
date.set(DateTimeFieldType.hourOfHalfday(), hours
.intValue());
date.setMinuteOfHour((minutes != null) ?
minutes.intValue()
: 0);
}
if (amOrPm == AM_PM.PM) {
date.set(DateTimeFieldType.halfdayOfDay(), 1);
} else {
date.set(DateTimeFieldType.halfdayOfDay(), 0);
}
} catch (RuntimeException e) {
DateTimeField.this.error(e.getMessage());
invalid();
}
// the date will be in the server's timezone
Date d = date.toDate();
setModelObject(d);
} else {
setModelObject(null);
}
}
be this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
try {
TimeZone zone = getClientTimeZone();
if (zone != null) {
date.setZone(DateTimeZone.forTimeZone(zone));
}
if (hours != null) {
date.set(DateTimeFieldType.hourOfHalfday(), hours
.intValue());
date.setMinuteOfHour((minutes != null) ?
minutes.intValue()
: 0);
}
if (amOrPm == AM_PM.PM) {
date.set(DateTimeFieldType.halfdayOfDay(), 1);
} else {
date.set(DateTimeFieldType.halfdayOfDay(), 0);
}
// the date will be in the server's timezone
Date d = date.toDate();
setModelObject(d);
} catch (RuntimeException e) {
DateTimeField.this.error(e.getMessage());
invalid();
}
} else {
setModelObject(null);
}
}
So only set the model object to the date if there is no exception?
DatePicker (then new one in wicket-datetime)
i see this in that behavior:
public void onRendered(Component component) {
super.onRendered(component);
// Append the span and img icon right after the rendering of the
// component. Not as pretty as working with a panel etc, but works
// for behaviors and is more efficient
Response response = component.getResponse();
response
.write("\n ");
}
but that doesnt work at my place, because everything is position in css.
this works for me: (as an example if the component had a width of 140px )
public void onRendered(Component component) {
super.onRendered(component);
// Append the span and img icon right after the rendering of the
// component. Not as pretty as working with a panel etc, but works
// for behaviors and is more efficient
Response response = component.getResponse();
response
.write("\n ");
}
ofcourse i can override the complete onRendered again and do that
implementation.
or we give a few more call backs like generateImgTag()??
Also the popup when i click on the img is to small. for example i miss the
arrow button to scroll forward in the months
Where is that specified?
johan
Re: Questions about SecondLevelCacheSessionStore
it is not a question about storing the entire session or not. The idea is that the second level cache keeps the session small. Because if we just rely on the session to serialize by the container then how many pages or page versions should we keep in memory? we did see by the AccessStackPageMap which defaults to 7 that they can grow quite large on big pages that are also changing a lot. and also saving just the page is much less then serializing the complete session for sure if we have that 7 page/versions in by default. the problem is that we are trying to find a balance between session usage and speed. We are still tweaking the Serialization and FileStore implementation as for clustering, i don't think that is a big problem, sticky session is the way to go anyway (i don't believe in the none sticky session variant at all, thats doesn't gain you anything) And then only in the situation where one server goes down and you have a failover AND the next request of a client is the backbutton. Then they will get a page expired They didn't loose the session info, or the current pages of all the current pagemaps only the old pages if you don't share the directory over all the servers. But i don't know if that really gains you anything.. You could drop in a DB save implementation ofcourse if you really need it. johan On 2/19/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: Hi Wicket devs, Sorry for jumping in on this list since I'm barely a Wicket user (much less a developer), but I wanted to share some thoughts/ questions regarding your work on the SecondLevelCacheSessionStore. 1) If the main purpose is to move sessions out of RAM and onto disk or a database, aren't you largely duplicating functionality already (and probably more appropriately) provided at the container level (e.g. Tomcat's PersistentManager)? I realize that SecondLevelCacheSessionStore moves only part of a session out of memory rather than the whole thing and so, in effect, keeps the literal session size small. But why is it necessarily better to swap a part of every session in and out of RAM vs swapping entire idle sessions out of RAM and back in only when needed (this is PersistentManager's strategy)? It seems like the PersistentManager approach would be more efficient (less disk writes) and should provide similar RAM savings in the long run. 2) Doesn't the SecondLevelCacheSessionStore create another data repository that must be shared or distributed across clustered application servers? I mean, in addition to normal session clustering wouldn't one also have to cluster whatever gets persisted by SecondLevelCacheSessionStore since it stores data that is essentially an extension of the session? 3) I'm afraid that a file based session store (the default implementation, I believe) will actually perform so badly that it won't be useful in the type of high load environment SecondLevelCacheSessionStore is intended to address. In my experience with a fairly high traffic PHP site, file-based session storage is extremely slow and you have to switch to a database-backed solution to handle any kind of serious load (assuming that you can't hold the sessions in RAM, which is basically not an option anyway with PHP). I know a database implementation of SecondLevelCacheSessionStore has been discussed, but I guess what I'm trying to point out is that the default implementation may actually perform and scale worse than no SecondLevelCacheSessionStore at all would. Furthermore, if a database- backed solution works well, why not just let the container store entire sessions in a database and avoid adding a second layer of session storage that must be managed in a cluster? I apologize if these questions/suggestions are ignorant or come across as rude. I certainly don't mean to disparage anyone's efforts in making Wicket more scalable and I don't pretend to be a scalability guru (although I do have a decent amount of experience in this area that I'll be glad to talk about if that's useful). I was just reading through some of your past discussions about SecondLevelCacheSessionStore and I couldn't help but see a few red flags. Thanks, -Ryan
Re: wicket modules
i get an error when i put @Foo on a field in eclipse (give its not the standard) so i dont know if javac is supposed to ignore them or not. can you try? as far as logging, i think a single INFO: Wicket-Spring Module Initialized is very easy to check for. -igor On 2/19/07, Erik van Oosten <[EMAIL PROTECTED]> wrote: Forgive me if I am wrong, but I thought that unknown annotations must be ignored by the Java compiler. If not, I stand corrected. About logging: there is usually too much logging already. Logging is mostly useful for negative messages. Extracting more information from a log takes the hours I was talking about. :( Debugging is more effective most of the time. Regards, Erik. Igor Vaynberg wrote: > all these cons are invalid > you would also get class not found on the annotations like @SpringBean > and a log message tells you what modules have been initialized > > :) > > -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: wicket modules
Forgive me if I am wrong, but I thought that unknown annotations must be ignored by the Java compiler. If not, I stand corrected. About logging: there is usually too much logging already. Logging is mostly useful for negative messages. Extracting more information from a log takes the hours I was talking about. :( Debugging is more effective most of the time. Regards, Erik. Igor Vaynberg wrote: all these cons are invalid you would also get class not found on the annotations like @SpringBean and a log message tells you what modules have been initialized :) -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
