Re: getCallbackFunctionBody - Wicket.Ajax.ajax?
On Mon, Jul 22, 2013 at 9:13 AM, Martin Grigorov mgrigo...@apache.orgwrote:
Hi,
On Fri, Jul 19, 2013 at 5:10 PM, Bertrand Guay-Paquet
ber...@step.polymtl.ca wrote:
Hi,
I use the javascript generated by getCallbackFunction just fine. Here's
an
actual function used as an onclick callback:
function (event) {
var attrs = {u:./103?1-1.**IBehaviorListener.0-,i:**veil};
If there is no event (attribute 'e') in the attributes then 'domready' is
assumed.
I.e. Wicket.Ajax.ajax() will call Wicket.Ajax.Call.ajax() as soon as the
component is available in the DOM. If there is no component (attribute 'c')
then the window object is used.
thanks for explaining. This should allow me to simplify things here and
there.
cheers, Frank
var params = {'tourAction': 1};
attrs.ep = params;
Wicket.Ajax.ajax(attrs);
}
The java code that generated it is :
// Collect the extra parameters
CallbackParameter[] parameters = new CallbackParameter[2];
parameters[0] = CallbackParameter.context(**event);
parameters[1] = CallbackParameter.resolved(**tourAction, 1);
// Generate callback function
CharSequence callbackFunction =
getCallbackFunction(**parameters);
This definitely does an ajax call. I haven't looked closely at the
Wicket.Ajax.ajax() code, but it works fine.
Bertrand
On 19/07/2013 9:58 AM, Frank van Lankvelt wrote:
hi all,
in the process of upgrading to wicket 6, I have to do some wicket ajax
calls from custom javascript callbacks. The AbstractDefaultAjaxBehavior
seems to provide a bunch of tools to help me out. But I cannot make
sense
of the javadoc ( implementation) of #getCallbackFunction:
* Generates a javascript function that can take parameters and
performs
an
AJAX call which
* includes these parameters. The generated code looks like this:
*
* pre
* function(param1, param2) {
*var attrs = attrsJson;
*var params = {'param1': param1, 'param2': param2};
*attrs.ep = jQuery.extend(attrs.ep, params);
*Wicket.Ajax.ajax(attrs);
* }
* /pre
But AFAIK the last line of the generated function
Wicket.Ajax.ajax(attrs)
does not do an ajax call.
It just uses jQuery to register event listeners.
So have I missed something, or is this a bug?
thanks, Frank
--**--**-
To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org
users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
getCallbackFunctionBody - Wicket.Ajax.ajax?
hi all,
in the process of upgrading to wicket 6, I have to do some wicket ajax
calls from custom javascript callbacks. The AbstractDefaultAjaxBehavior
seems to provide a bunch of tools to help me out. But I cannot make sense
of the javadoc ( implementation) of #getCallbackFunction:
* Generates a javascript function that can take parameters and performs an
AJAX call which
* includes these parameters. The generated code looks like this:
*
* pre
* function(param1, param2) {
*var attrs = attrsJson;
*var params = {'param1': param1, 'param2': param2};
*attrs.ep = jQuery.extend(attrs.ep, params);
*Wicket.Ajax.ajax(attrs);
* }
* /pre
But AFAIK the last line of the generated function Wicket.Ajax.ajax(attrs)
does not do an ajax call.
It just uses jQuery to register event listeners.
So have I missed something, or is this a bug?
thanks, Frank
--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
Re: Wicket mentioned at Server Side Symposium
On Mon, Mar 21, 2011 at 9:52 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: While we strive to keep binary compatibility between minor releases, i.e. the z releases of an x.y.z release path, sometimes things slip by. In principle we only allow security or blocker issues to break the API in a .z release. So we strive to make the upgrade path of 1.4.0 to 1.4.16 to be just a version number change, with an API surface the size of Wicket's it is nigh impossible to achieve 100% binary compatiblity between all minor releases (.z releases). If the speaker is talking about the y part, then yes we allow breakages and possibly even large ones. But those are always fairly easy to upgrade. The upgrade from 1.3 to 1.4 was mainly generics: a painful upgrade, but worth the effort. It could've been a x release, but we only modified the type parameter, and the rest of the API was only changed to support the generification. We voted upon the release number and with our previous 2.0 fiasco still in memory we decided to up the y part only. With Wicket 1.5 we improved the internals considerably, and improved the API as well. The upgrade path is detailed in our migration guide in the wiki. The upgrade from 1.4 to 1.5 should be not too much work. I'd rather have a framework that breaks some API in minor ways with each .y release, than a stagnant framework that is afraid to improve on its API and internals. +1 Such an API gives way to a utility library that makes up for the stagnation, taking experience into account on a higher level. Thereby it effectively becomes the API itself. In my experience, .z wicket upgrades are a no-brainer, the .y upgrade I've seen gave me a working build in a day; remaining upgrade steps (deprecation / generification) can be dealt with when touching the code for new development. cheers, Frank So while he technically has a point, I think it is a category z point. Not a major one. Martijn On Mon, Mar 21, 2011 at 9:22 PM, Clint Checketts checke...@gmail.com wrote: Take the following with a grain of salt since I was told by a friend, of a friend that attended the Server Side Symposium last week. I don't have any of the details either so bear with me. Apparently in a session related to 'corporations using open source' the speaker asked if any companies were using Wicket. He cautioned that Wicket was an example of mis-managing by being known to break it's APIs in minor point-releases. In my experience with the Wicket API, I've only seen major API changes in the major releases: 1.3 - 1.4 and the upcoming 1.5. (In my book API *additions *like adding onConfigure don't count) So of course I stood up for Wicket. Even when I've proposed changes myself the core developers have done a great job of not breaking APIs. So, does anyone else know what this speaker may have been referring to regarding API breakages? -Clint -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Re: preferred php framework by wicketeers...
On Tue, Mar 8, 2011 at 1:21 PM, Antoine van Wel antoine.van@gmail.comwrote: Since you can't always have what you want.. Is there any PHP framework out there which comes even close to Wicket; component based, strict separation between HTML and programming, stateful, out-of-the-box Ajax support, event handling, URL mapping, excellent testing features, and great community support? it would probably have turned up in your google search if it existed ;-) A prototype is easy to make though; you should get a lot of benefits already from adopting the wicket session mgmt, component rendering model to php. In fact, I built something like this for fun some time ago. No ajax, url mapping, models, other fancy stuff. But event handling and markup/code separation is pretty easy to accomplish. You'ld probably want to use smarty for the rendering though. It doesn't make a lot of sense to parse html on each request and smarty probably has the best tooling for php templating. cheers, Frank regards Antoine - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
howto integrate third-party ajax with channels?
I'm regularly running into problems when integrating client-side ajax code. The issue is that the client-side code is doing throttled asynchronous calls to wicket ajax behaviors. Now, this generally works fine until I want to integrate this with native wicket calls (links, buttons). Then, such throttled calls should be flushed before the native request is sent to the server. The only way I can see/make this work is by registering pre-call handlers and doing the requests synchronously from the pre-call handler. A short explanation; the request cannot be done asynchronously as there is no guarantee that it will arrive at the server before the original call (that triggered the pre-call handler) arrives. This is clumsy and, generally, error-prone. It also appears to be partly re-doing what Wicket's channels already do, as channels take care of request ordering. So I wonder whether I am overlooking something. How do you guys handle this? Thinking out loud: would it be possible to have a 'throttled' channel that is flushed whenever a request is scheduled on the default channel (0|s)? That way, third-party JS lib integrations could schedule calls to this channel on every key-stroke, having the synchronization handled automatically. cheers, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Re: howto integrate third-party ajax with channels?
I can, and generally I'm able to resolve the race between multiple xhr requests. But only by using synchronous requests. I was hoping to be able to do it using async only (synchronous xhr is evil, as I've seen Mathej remark in an old thread). So being able to schedule a request on a channel, before the call that invokes the pre-call listener is sent, would be the perfect solution. Perhaps hooking the channel manager would provide a way to schedule a flush before the actual call is made? Should at least keep everything async, so UI responsive. Thanks for reading my rambling, Cheers, Frank Op 18 jan. 2011 om 01:35 heeft Igor Vaynberg igor.vaynb...@gmail.com het volgende geschreven: can you do the flushing yourself by registering a wicket.ajax.pre-call-handler? -igor On Mon, Jan 17, 2011 at 2:57 AM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: I'm regularly running into problems when integrating client-side ajax code. The issue is that the client-side code is doing throttled asynchronous calls to wicket ajax behaviors. Now, this generally works fine until I want to integrate this with native wicket calls (links, buttons). Then, such throttled calls should be flushed before the native request is sent to the server. The only way I can see/make this work is by registering pre-call handlers and doing the requests synchronously from the pre-call handler. A short explanation; the request cannot be done asynchronously as there is no guarantee that it will arrive at the server before the original call (that triggered the pre-call handler) arrives. This is clumsy and, generally, error-prone. It also appears to be partly re-doing what Wicket's channels already do, as channels take care of request ordering. So I wonder whether I am overlooking something. How do you guys handle this? Thinking out loud: would it be possible to have a 'throttled' channel that is flushed whenever a request is scheduled on the default channel (0|s)? That way, third-party JS lib integrations could schedule calls to this channel on every key-stroke, having the synchronization handled automatically. cheers, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
howto track translations
in the process of expanding the number of languages my wicket application is available in, I'm running into the question of tracking properties files. In particular, I want to be able to get some kind of feedback about missing translations; mismatches between property files would be sufficient. How do you do this? Is there a maven plugin that I've missed, or perhaps a standalone tool? cheers, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: howto track translations
thanks; I seem to be getting this hint more and more often. It's not built into my IDE, eclipse, hopefully there is a plugin with similar functionality. cheers, Frnak On Fri, Dec 3, 2010 at 11:43 AM, Peter Miklosko peter.b...@gmail.com wrote: Not sure how other IDEs but in IntelliJ once you have at least one translation beside default and you open any of them there at the bottom of the freame are two tabs to switch between Text and Resource bundle. In Resource bundle view it will highlight in red any property that is not available in some translations. This is default functionality of IDE. Peter On 3 December 2010 09:40, Frank van Lankvelt f.vanlankv...@onehippo.comwrote: in the process of expanding the number of languages my wicket application is available in, I'm running into the question of tracking properties files. In particular, I want to be able to get some kind of feedback about missing translations; mismatches between property files would be sufficient. How do you do this? Is there a maven plugin that I've missed, or perhaps a standalone tool? cheers, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to hide ListView rows the right way?
wouldn't you be better off wrapping your model/dataprovider in a filter that does the processing that's required? That way, you can keep populating the views simple, without even needing to use setVisible. cheers, Frank On Mon, Nov 8, 2010 at 4:34 PM, MattyDE ufer.mar...@gmail.com wrote: Hi Folks, i abuse the ListView Component (2 of them nested) to iterate over a bunch of type-save objects to build my own GridView Component, which works very well. But now, i want to spare out the showing of some rows in the outer ListView component, but ALSO want to process the inner ListView:populateItem for some special object processing over ALL Items (espacially the hidden ones), but NOT showing the row to the client at all. I try setVisible(false) and this works very well... for hiding, but the inner ListView will not be processed anymore for this particular hidden row. Any ideas how to hide the row AND process/render the inner ListView? A CSS-Hiding is not a solution, i have to limit the shown items for peformance matter so i dont want to responde the hidden html-lines to the client at all. Thanks in Advance for any hint, and apologise my terrible English. Its not my mothers tongue. - Matty -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-hide-ListView-rows-the-right-way-tp3032125p3032125.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-ajax header from url?
I think it would make sense to have any requests targeting an abstract-ajax-behavior be marked as 'ajax', without requiring client-side logic. This makes client-side integration quite straightforward. One then only needs to implement the server side of the protocol, without having to intercept the request creation process. It also makes request handling more robust in the face of concurrent requests, as I experienced. Implementing this behavior with the wicket:ajax parameter in the url does require support when rendering urls; should be easy in 1.5, is currently not possible in 1.4 since the webrequestcodingstrategy does not render user-defined request parameters. I'm now doing it by simply appending 'wicket:ajax=true' in the getCallbackUrl method. There are probably alternative solutions that do not require a parameter in the url; I haven't looked into those yet. thanks for clarifying, Frank On Tue, Nov 2, 2010 at 7:03 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: the url parameter is there only as a workaround for when we cannot set the header. i think the only usecase is for fileuploads where we have to set an ajax url on iframe's src attribute. the header is the preferred way to do this and you can set it yourself i you need or use wicket's ajax js to perform the request - which will set it for you. -igor On Mon, Nov 1, 2010 at 11:59 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: well, the two kinds of ajax requests differ; the WebRequest#isAjax method returns true for wicket-ajax, but false for non-wicket-ajax requests. The 'wicket-ajax' request has the Wicket-Ajax header, the other does not. So I should have said that the first (locking) request was non-wicket-ajax; i.e. an ajax request but without the Wicket-Ajax header set. Some further digging turned up the wicket:ajax request parameter; I guess I should simply append it to the URL for the non-wicket-ajax behavior. Perhaps that could happen in the base class AbstractAjaxBehavior? cheers, Frank On Tue, Nov 2, 2010 at 1:14 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: so why is there the non-ajax request? once the page is loaded everything else - communication with ext - should be happening via ajax requests... -igor On Mon, Nov 1, 2010 at 1:20 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: it returned false because a) the locking request was not ajax b) the current request was ajax c) they shared the same page version Page versioning is disabled, though that shouldn't matter. (that might be a worthwhile additional check before comparing versions; I'm not very familiar with versions) It's a concurrency issue for one page, with some non-wicket-ajax behaviors, so it might be pushing what people have seen? Both ext-js integration projects I've found have the same basic setup; use AbstractAjaxBehavior to provide data services, use AbstractDefaultAjaxBehavior subclasses for listening to Ext events. So that's also where my bug occurs; I'm switching between ext components on the client as the result of some action. The action leads to a notification to wicket, the new component starts fetching data. thanks, Frank On Mon, Nov 1, 2010 at 5:28 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: did you check why it returns false? ajax requests should not increment the page version, so they should always be current. people have built extjs integrations before, you may look into one of those for hints. -igor On Mon, Nov 1, 2010 at 9:14 AM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: In my attempts to integrate a javascript client-side framework (ext-js) to wicket, I'm running into the problem that the client-side framework expects URLs to send requests to, expecting a JSON/XML response. This is of course perfectly natural behavior for a js framework. The documentation I could find suggested to use an AbstractAjaxBehavior. However, this doesn't quite work. Concurrent proper wicket-ajax requests (abstractdefaultajaxbehavior) are aborted due to WebSession#isCurrentRequestValid returning false. Am I doing something wrong here, or should I simply override the isCurrentRequestValid method to always return true? thanks, Frank PS: I'm using wicket-1.4.9; but couldn't find relevant issues that have been fixed since this release -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
Re: wicket-ajax header from url?
well, the two kinds of ajax requests differ; the WebRequest#isAjax method returns true for wicket-ajax, but false for non-wicket-ajax requests. The 'wicket-ajax' request has the Wicket-Ajax header, the other does not. So I should have said that the first (locking) request was non-wicket-ajax; i.e. an ajax request but without the Wicket-Ajax header set. Some further digging turned up the wicket:ajax request parameter; I guess I should simply append it to the URL for the non-wicket-ajax behavior. Perhaps that could happen in the base class AbstractAjaxBehavior? cheers, Frank On Tue, Nov 2, 2010 at 1:14 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: so why is there the non-ajax request? once the page is loaded everything else - communication with ext - should be happening via ajax requests... -igor On Mon, Nov 1, 2010 at 1:20 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: it returned false because a) the locking request was not ajax b) the current request was ajax c) they shared the same page version Page versioning is disabled, though that shouldn't matter. (that might be a worthwhile additional check before comparing versions; I'm not very familiar with versions) It's a concurrency issue for one page, with some non-wicket-ajax behaviors, so it might be pushing what people have seen? Both ext-js integration projects I've found have the same basic setup; use AbstractAjaxBehavior to provide data services, use AbstractDefaultAjaxBehavior subclasses for listening to Ext events. So that's also where my bug occurs; I'm switching between ext components on the client as the result of some action. The action leads to a notification to wicket, the new component starts fetching data. thanks, Frank On Mon, Nov 1, 2010 at 5:28 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: did you check why it returns false? ajax requests should not increment the page version, so they should always be current. people have built extjs integrations before, you may look into one of those for hints. -igor On Mon, Nov 1, 2010 at 9:14 AM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: In my attempts to integrate a javascript client-side framework (ext-js) to wicket, I'm running into the problem that the client-side framework expects URLs to send requests to, expecting a JSON/XML response. This is of course perfectly natural behavior for a js framework. The documentation I could find suggested to use an AbstractAjaxBehavior. However, this doesn't quite work. Concurrent proper wicket-ajax requests (abstractdefaultajaxbehavior) are aborted due to WebSession#isCurrentRequestValid returning false. Am I doing something wrong here, or should I simply override the isCurrentRequestValid method to always return true? thanks, Frank PS: I'm using wicket-1.4.9; but couldn't find relevant issues that have been fixed since this release -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
wicket-ajax header from url?
In my attempts to integrate a javascript client-side framework (ext-js) to wicket, I'm running into the problem that the client-side framework expects URLs to send requests to, expecting a JSON/XML response. This is of course perfectly natural behavior for a js framework. The documentation I could find suggested to use an AbstractAjaxBehavior. However, this doesn't quite work. Concurrent proper wicket-ajax requests (abstractdefaultajaxbehavior) are aborted due to WebSession#isCurrentRequestValid returning false. Am I doing something wrong here, or should I simply override the isCurrentRequestValid method to always return true? thanks, Frank PS: I'm using wicket-1.4.9; but couldn't find relevant issues that have been fixed since this release -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
Re: wicket-ajax header from url?
it returned false because a) the locking request was not ajax b) the current request was ajax c) they shared the same page version Page versioning is disabled, though that shouldn't matter. (that might be a worthwhile additional check before comparing versions; I'm not very familiar with versions) It's a concurrency issue for one page, with some non-wicket-ajax behaviors, so it might be pushing what people have seen? Both ext-js integration projects I've found have the same basic setup; use AbstractAjaxBehavior to provide data services, use AbstractDefaultAjaxBehavior subclasses for listening to Ext events. So that's also where my bug occurs; I'm switching between ext components on the client as the result of some action. The action leads to a notification to wicket, the new component starts fetching data. thanks, Frank On Mon, Nov 1, 2010 at 5:28 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: did you check why it returns false? ajax requests should not increment the page version, so they should always be current. people have built extjs integrations before, you may look into one of those for hints. -igor On Mon, Nov 1, 2010 at 9:14 AM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: In my attempts to integrate a javascript client-side framework (ext-js) to wicket, I'm running into the problem that the client-side framework expects URLs to send requests to, expecting a JSON/XML response. This is of course perfectly natural behavior for a js framework. The documentation I could find suggested to use an AbstractAjaxBehavior. However, this doesn't quite work. Concurrent proper wicket-ajax requests (abstractdefaultajaxbehavior) are aborted due to WebSession#isCurrentRequestValid returning false. Am I doing something wrong here, or should I simply override the isCurrentRequestValid method to always return true? thanks, Frank PS: I'm using wicket-1.4.9; but couldn't find relevant issues that have been fixed since this release -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
wicket and ext-js
I'm in the process of integrating Ext-JS into our Wicket application. So there are a number of questions, such as: What are your experiences of using wicket and ext together? Do these projects help at all, or do you rather roll a custom behavior each time? Is there some project that is not indexed by Google (see below)? Are there some fundamental problems one runs into when building more complex UIs? I found two projects that provide an integration; - wicket-ext at http://code.google.com/p/wicket-ext/ - wicket-extjs-integration http://code.google.com/p/wicket-extjs-integration/ Neither of these is very active, but I'm hoping that some of you have experience with them. The wicket-ext project has lots of widgets already integrated, but I don't really understand the reason for creating two hierarchies; one of Components and one of Behaviors. It seems to me that mapping ext components onto wicket components should be sufficient; behaviors can then be added to provide services to the client-side code. The wicket-extjs-integration project is in its infancy, but has a lot of potential; it maps ext components directly onto wicket components, has been explicitly designed to do composition and even has a nice way of invoking ext client-side methods from server-side code. I also like the annotation-based configuration of the client-side components. I would like to continue work on the second approach, but would like to get some feeling for the task at hand first ;-) thanks, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
Re: wicket and ext-js
I haven't; the main reason being that we are using Ext-JS for another application we're developing and we'ld like to limit the number of technologies in our stack. We are already using a mix of custom developed javascript functionality and some standard YUI 2 components. A major motivation for moving to Ext is the large number of components it has. Of course, these will all have to be integrated into Wicket separately, but the hope is that a set of suitable helpers/abstractions can help keep the development costs low. cheers, Frank On Wed, Sep 29, 2010 at 1:33 PM, Alexander Morozov alexander.v.moro...@gmail.com wrote: Hi, the integration projects, you mention above, seems inactive for a long time. Is it critical for your project to use exactly the Ext-JS javascript framework ? Have you looked at WiQuery project (jQuery integration) ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-and-ext-js-tp2718664p2718787.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
Re: wicket and ext-js
hi Fabio, good to hear it is in active use and development! There might be more users than you think; perhaps you can get them to voice their enthousiasm. Might help to find the time to publish the changes? Concerning your example, some behaviors are definitively offered best as actual wicket behaviors. Tooltips, data stores, other services you need from the client. But I still wonder whether that justifies the overhead, considering the large number of components. Are there other motivations like, I could imagine, needing to subclass the FormComponent to be able to participate in form processing? thanks, Frank On Wed, Sep 29, 2010 at 3:45 PM, Fabio Fioretti windom.macroso...@gmail.com wrote: Hi, I am one of the developers behind wicket-ext. The project hasn't been updated lately even though it is still used, maintained and developed behind closed doors. We stopped updating it both because of lack of public interest (we have received only few external contributions) and because of the fact that the Ext-JS components we found most useful for our applications are already supported (i.e. we currently have no real interest in driving the endeavour further). In addition, we had no time to clean-up the latest code to the extent of releasing it publicly. I can say that the integration was quite straightforward and Wicket proved to work very well with Ext-JS; in particular, we found grid components (GridPanel, GroupingView, etc.) extremely useful. The separation of Behaviors and Components hierarchies was a design decision rooted in flexibility and actually inspired by Wicket: we wanted to allow the application of Ext behaviors to standard Wicket components. Just to give an example, think of a PersistentTip applied to a Wicket TextField through a simple textField.add(new ExtBaloonBehavior(model)). Why would you need a custom TextField for that? Good luck for your integration effort and, should you decide to build on top of wicket-ext, feel free to ask. Cheers, Fabio Fioretti On Wed, Sep 29, 2010 at 12:09 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: I'm in the process of integrating Ext-JS into our Wicket application. So there are a number of questions, such as: What are your experiences of using wicket and ext together? Do these projects help at all, or do you rather roll a custom behavior each time? Is there some project that is not indexed by Google (see below)? Are there some fundamental problems one runs into when building more complex UIs? I found two projects that provide an integration; - wicket-ext at http://code.google.com/p/wicket-ext/ - wicket-extjs-integration http://code.google.com/p/wicket-extjs-integration/ Neither of these is very active, but I'm hoping that some of you have experience with them. The wicket-ext project has lots of widgets already integrated, but I don't really understand the reason for creating two hierarchies; one of Components and one of Behaviors. It seems to me that mapping ext components onto wicket components should be sufficient; behaviors can then be added to provide services to the client-side code. The wicket-extjs-integration project is in its infancy, but has a lot of potential; it maps ext components directly onto wicket components, has been explicitly designed to do composition and even has a nice way of invoking ext client-side methods from server-side code. I also like the annotation-based configuration of the client-side components. I would like to continue work on the second approach, but would like to get some feeling for the task at hand first ;-) thanks, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com
pagemap locking
Hi all, hoping to get some debugging tips on a concurrency issue I've run into. What we're seeing is concurrent access to a Page instance, when our application is under a lot of stress. The backend is taking a lot of time, which should be handled by Wicket by locking on the pagemap. This is what I see in the (wicket) code and appears to be working fine in ordinary circumstances. (i.e. request being aborted after a minute) What's probably funny about our application is that multiple pages from the same pagemap can be involved in one request cycle. After handling the action, but before rendering, we process events that have been delivered to the session. This involves invoking listeners on different page instances. (we're not serializing pages to disk) I'm happy to give more details of the way we use wicket (it's all open source anyway), but perhaps there are some gotcha's that I've been missing. Does anyone have a clue? thanks, Frank
Re: pagemap locking
yeah, that's why I thought that I would be safe when only dispatching events during the request processing to a page from the page-map. thanks, Frank On Wed, Apr 28, 2010 at 4:48 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: most likely this concurrent access happens when you are iterating over pages in the pagemap and invoking listeners on them and another thread access one of the pages you are iterating over. you will have to lock your iteration loop on the same lock wicket uses. as a rule of thumb we do not recommend accessing pages in the pagemap yourself... -igor On Wed, Apr 28, 2010 at 6:44 AM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: Hi all, hoping to get some debugging tips on a concurrency issue I've run into. What we're seeing is concurrent access to a Page instance, when our application is under a lot of stress. The backend is taking a lot of time, which should be handled by Wicket by locking on the pagemap. This is what I see in the (wicket) code and appears to be working fine in ordinary circumstances. (i.e. request being aborted after a minute) What's probably funny about our application is that multiple pages from the same pagemap can be involved in one request cycle. After handling the action, but before rendering, we process events that have been delivered to the session. This involves invoking listeners on different page instances. (we're not serializing pages to disk) I'm happy to give more details of the way we use wicket (it's all open source anyway), but perhaps there are some gotcha's that I've been missing. Does anyone have a clue? thanks, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket YUI integration
we've been developing a wicket application for some time now, where the client keeps pushing for more and more fancy UI components. We've been building some of them by hand, including browser version checks, and have some code to enable YUI widgets. This is a costly business where we are severely hampered by compatibility requirements. (IE6!) Are there widget libraries out there, in particular that integrate with YUI, that I've been missing? Related to this, about a year ago there was a discussion about Wicket Ajax Next Generation. Does anyone know if that is still scheduled for Wicket 1.5? thanks, Frank PS: I don't think it would be a problem to donate the code we have developed so far (it's APL already), though it would need to be decoupled from the rest of our code first. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Observation and page (map) eviction
After working things through once more, I opted for a simple model where I maintain a global registry of (jcr) event listeners using weak references. Events are queued to be processed later during a request cycle. So, in fact I managed to evade the page eviction problem; at the cost of additional cpu time (pages that have been discarded by the session store will still receive events, even though those will never be processed). The snags of (de)serialization are handled automatically if listeners are re-registered when the object under observation is deserialized. (i.e. implementing readObject()) This should work independent of session store; any kind of caching scheme is supported this way. It should also work with replication. I'm not sure if this is the solution that Igor suggested, but it sure makes sense to me. Thanks for the help! Cheers, Frank -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: 25 January 2009 21:55 To: users@wicket.apache.org Subject: Re: Observation and page (map) eviction Maybe if you want listeners then only the session listen to those? And pages/components when they render pull the changes out of the session? On 25/01/2009, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: But how is a view to know if its model (object) has changed in the pull model? One way that I see this working is if views extract all state that they need to do the rendering into a separate object. This object is then recalculated from the model that is used by the view on each request. Is this what you're suggesting? Of course one should not go about (de)serializing listeners carelessly. I was a bit simplistic in describing what I want there, sorry 'bout that. What I'm doing at the moment (with the listener leak) is that the listeners that actually get registered with the object are stored in the session. When they're called (asynchronously), they store events in a queue. Then, when a request comes in, this queue is emptied by the page that is being rendered; the events are processed by the in-page listeners. This mechanism does depend on the use of sticky sessions, as it has to be possible for an external service to invoke the (session) listeners. The problem is now how to manage the listeners in the session. They only need to be present for the current pages in pagemaps, i.e. those pages that are shown and that will generate a request every now and then using an ajax-timer. Other pages in the pagemap will be redrawn completely when they need to respond to a request, so there is no need for observation for them. Just realised that I can detect pagemap eviction by simply enumerating the pagemaps when the session is detached. It seems to me that for wicket to support comet/bayeux, there will have to be a solution for the kind of problems I'm running into here. I don't think pushing the problem to the application developer (as I think you are suggesting) is acceptable in the long run. Cheers, Frank From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: 24 January 2009 19:58 I think having references to or from pages is a bad idea in wicket. We serialize pages so if pages would have listeners then the are also serialized. If others reference pages then after serialization/deserialization they point to the wrong instance. Way better is pure pull support. Components know where thet get its data from and they pull it on render and/or on a visitor that checks all components if they are changed. (and if changes add them to ajax request target) On 24/01/2009, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: I'm trying to get a page to observe a business object that can send events. The changes don't warrant a full page refresh, so I want to update only those parts of the page that have changed as a result of the events. I've seen wicketstuff-push, where a similar kind of observation is present in the Application. From what I could see, the chat example has the drawback that there is no *unregistering* of listeners when pages are disposed of, so there is a memory leak. (all pages will be kept in memory, being referenced directly by the service in the application) There doesn't seem to be any support for cleaning up pages, e.g. in the form of listeners that an application could register with the session store. An alternative seems to be to implement my own PageMap, but I'm reluctant to do that as there will be a lot of copy/paste involved and the existing PageMap implementations rely on the fact that they're in the same package as Session. A different
RE: Observation and page (map) eviction
But how is a view to know if its model (object) has changed in the pull model? One way that I see this working is if views extract all state that they need to do the rendering into a separate object. This object is then recalculated from the model that is used by the view on each request. Is this what you're suggesting? Of course one should not go about (de)serializing listeners carelessly. I was a bit simplistic in describing what I want there, sorry 'bout that. What I'm doing at the moment (with the listener leak) is that the listeners that actually get registered with the object are stored in the session. When they're called (asynchronously), they store events in a queue. Then, when a request comes in, this queue is emptied by the page that is being rendered; the events are processed by the in-page listeners. This mechanism does depend on the use of sticky sessions, as it has to be possible for an external service to invoke the (session) listeners. The problem is now how to manage the listeners in the session. They only need to be present for the current pages in pagemaps, i.e. those pages that are shown and that will generate a request every now and then using an ajax-timer. Other pages in the pagemap will be redrawn completely when they need to respond to a request, so there is no need for observation for them. Just realised that I can detect pagemap eviction by simply enumerating the pagemaps when the session is detached. It seems to me that for wicket to support comet/bayeux, there will have to be a solution for the kind of problems I'm running into here. I don't think pushing the problem to the application developer (as I think you are suggesting) is acceptable in the long run. Cheers, Frank From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: 24 January 2009 19:58 I think having references to or from pages is a bad idea in wicket. We serialize pages so if pages would have listeners then the are also serialized. If others reference pages then after serialization/deserialization they point to the wrong instance. Way better is pure pull support. Components know where thet get its data from and they pull it on render and/or on a visitor that checks all components if they are changed. (and if changes add them to ajax request target) On 24/01/2009, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: I'm trying to get a page to observe a business object that can send events. The changes don't warrant a full page refresh, so I want to update only those parts of the page that have changed as a result of the events. I've seen wicketstuff-push, where a similar kind of observation is present in the Application. From what I could see, the chat example has the drawback that there is no *unregistering* of listeners when pages are disposed of, so there is a memory leak. (all pages will be kept in memory, being referenced directly by the service in the application) There doesn't seem to be any support for cleaning up pages, e.g. in the form of listeners that an application could register with the session store. An alternative seems to be to implement my own PageMap, but I'm reluctant to do that as there will be a lot of copy/paste involved and the existing PageMap implementations rely on the fact that they're in the same package as Session. A different alternative is to store all the listeners in a registry and use a separate thread to remove any listeners that are associated with pages that are no longer stored. Is there a better way? Thanks, Frank f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional
Observation and page (map) eviction
I'm trying to get a page to observe a business object that can send events. The changes don't warrant a full page refresh, so I want to update only those parts of the page that have changed as a result of the events. I've seen wicketstuff-push, where a similar kind of observation is present in the Application. From what I could see, the chat example has the drawback that there is no *unregistering* of listeners when pages are disposed of, so there is a memory leak. (all pages will be kept in memory, being referenced directly by the service in the application) There doesn't seem to be any support for cleaning up pages, e.g. in the form of listeners that an application could register with the session store. An alternative seems to be to implement my own PageMap, but I'm reluctant to do that as there will be a lot of copy/paste involved and the existing PageMap implementations rely on the fact that they're in the same package as Session. A different alternative is to store all the listeners in a registry and use a separate thread to remove any listeners that are associated with pages that are no longer stored. Is there a better way? Thanks, Frank f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RE: Things I miss in Wicket
You could take a look at the Hippo blog project, (follow the README)
http://svn.hippocms.org/repos/hippo/experimental/hippo-blog/trunk
It is composed of a customized CMS and a site web-application.
The cms has the blog document types added as an additional jar to the
standard packaged cms war. The frontend is built with the Hippo site
toolkit, http://www.onehippo.org/site-toolkit, using jsp for the
rendering. (yes, I would love to see a wicket frontend there too!)
The console should make clear what I've hinted to in this thread.
Plugins are configured with nodes in the (jcr) repository, and they are
started and stopped in groups/clusters.
(see /hippo:configuration/hippo:frontend/cms)
It is useful to think of plugins as units of configuration; if a plugin
is evolving to the point where its configuration becomes intimidating,
it's about time to break the plugin up into parts. Conversely, if a set
of plugins needs to be kept closely in sync with their configuration,
they probably aren't as independent as you would like and you're better
off coding it in java.
Coming back to an earlier post: I don't see the web-application
builder happening though; the one where you never need to touch code.
An interesting application will have many components with complex
interactions, by definition. Of course, one should decouple as many
components as possible and make the way they work and hang together
configurable. But the complexity of an application flow is still there
and you have to express it either in configuration or in code. I think
we can all agree that code works better here, or we wouldn't be using
Wicket!
thanks for the interest!
cheers, Frank
On Fri, 2009-01-16 at 20:40 +0100, Tobias Marx wrote:
Great!
Are there any demo/reference websites that run Hippo CMS or Hippo Portal?
Original-Nachricht
Datum: Fri, 16 Jan 2009 16:12:13 +0100
Von: Frank van Lankvelt f.vanlankv...@onehippo.com
An: users@wicket.apache.org
Betreff: RE: Things I miss in Wicket
Sure these kinds of things exist. In Hippo CMS 7, we're nesting panels
that each have their own instance-specific configuration. Different
document types have a corresponding (admittedly quite simple) plugin
configuration that can be edited within the cms. The cms itself is
mostly a (more involved) configuration of such loosely-coupled generic
panels.
This approach is actually opposite to Wickets philosophy (only Java +
HTML). But the great thing about combining opposites is that there is a
sliding scale for doing things. You can start out using the generic
building blocks, giving you limited flexibility in terms of how these
panels can interact, but at least they can be easily configured using a
web interface. Then, as your needs transcend the possibilities of this
simplistic solution, you can write your own plugins with the full power
of Wicket at your disposal.
Cheers, Frank
-Original Message-
From: Tobias Marx [mailto:superoverdr...@gmx.de]
Sent: 16 January 2009 14:10
To: users@wicket.apache.org
Subject: Re: Things I miss in Wicket
Brix only works the way it works because it does not need a
database..with a flexible achitecture and a database this
would not be possible without too many limitations either.
The ultimate goal would be a web-application builder...or at
least a highly configurable website (whatever kind of) that
only needs to be written once and can be customized easily
without changing the code.
So far this does not existthe thing that comes closed is
Typo3, Drupal or something like that...or the Dolphin
community builder - but this is all at a very early stage and
so far starting from scratch is often the better option in
the long-term.
Original-Nachricht
Datum: Fri, 16 Jan 2009 07:59:11 -0500
Von: Richard Allen richard.l.al...@gmail.com
An: users@wicket.apache.org
Betreff: Re: Things I miss in Wicket
What I don't like about Wicket is, that it is like writing normal
Java applications - although rich clients applications are being
replaced
with
web-based solutions and there is a fundamental difference between
web-applications and normal java applications. If you have a java
application as a product, it is normal to employ software
developers
that
work on bug fixes and new features all the time - they constantly
develop
and it is expensiveeverything has to be done by a software
developer.
Being more like a normal Java application (whatever that is :) is
precisely why some of us like Wicket.
An ideal web-application is developed once and the Java code is
never touched again for 3-5 years until there are a lot of new
features necessary but in this time there could be
several small
changes
RE: Things I miss in Wicket
Sure these kinds of things exist. In Hippo CMS 7, we're nesting panels that each have their own instance-specific configuration. Different document types have a corresponding (admittedly quite simple) plugin configuration that can be edited within the cms. The cms itself is mostly a (more involved) configuration of such loosely-coupled generic panels. This approach is actually opposite to Wickets philosophy (only Java + HTML). But the great thing about combining opposites is that there is a sliding scale for doing things. You can start out using the generic building blocks, giving you limited flexibility in terms of how these panels can interact, but at least they can be easily configured using a web interface. Then, as your needs transcend the possibilities of this simplistic solution, you can write your own plugins with the full power of Wicket at your disposal. Cheers, Frank -Original Message- From: Tobias Marx [mailto:superoverdr...@gmx.de] Sent: 16 January 2009 14:10 To: users@wicket.apache.org Subject: Re: Things I miss in Wicket Brix only works the way it works because it does not need a database..with a flexible achitecture and a database this would not be possible without too many limitations either. The ultimate goal would be a web-application builder...or at least a highly configurable website (whatever kind of) that only needs to be written once and can be customized easily without changing the code. So far this does not existthe thing that comes closed is Typo3, Drupal or something like that...or the Dolphin community builder - but this is all at a very early stage and so far starting from scratch is often the better option in the long-term. Original-Nachricht Datum: Fri, 16 Jan 2009 07:59:11 -0500 Von: Richard Allen richard.l.al...@gmail.com An: users@wicket.apache.org Betreff: Re: Things I miss in Wicket What I don't like about Wicket is, that it is like writing normal Java applications - although rich clients applications are being replaced with web-based solutions and there is a fundamental difference between web-applications and normal java applications. If you have a java application as a product, it is normal to employ software developers that work on bug fixes and new features all the time - they constantly develop and it is expensiveeverything has to be done by a software developer. Being more like a normal Java application (whatever that is :) is precisely why some of us like Wicket. An ideal web-application is developed once and the Java code is never touched again for 3-5 years until there are a lot of new features necessary but in this time there could be several small changes or complete re-designs...and in that time this should be a pure matter of HTMLing without the need of touching the Java code. If a new input field is added or some new strings.or whateveror maybe a new Flash component etcthis should still work without changing the -war file that carries the Java code...only changes in the templates or the database should be made. This sounds quite unrealistic to me for most applications. But I think a CMS (such as Brix: http://code.google.com/p/brix-cms/) comes close to what you are asking for if I understand what you are trying to get at. Wicket does does not really allow this. Or assume you have a web-application you want to sell - and don't want the customer to know Javathey would be really restricted in the changes that are possible. Another advantage of Wicket is that it creates a session for every visitor - no matter whether it is a crawler/search engine that does not need a session or a logged in user Again, a CMS. -Richard - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Technologies to use with large scale Wicket application
Brix Jackrabbit Our application will need some heavy duty CMS features, and this project looks powerful enough to do the job. Jackrabbit is used by Brix to store content. Alternatively, you could try Hippo CMS7. It's also built with Wicket on top of a JCR repository, but with some extensions that you might like. (workflow, authorization, virtual trees based on facets) The CMS itself features things like a document type editor, allowing you to create custom node types from within the cms. And as its composed of plugins, you can reconfigure a running system on the fly. (and yes, it's all APL) See http://www.onehippo.org/cms7 for details. Cheers, Frank f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: an lost in the dark exception question
According to a conversation I had with Johan, only the last shown page is kept in memory. Earlier versions are written to disk. When using ajax, the page does not have to be actually written to disk as you cannot reach the previous state by using the back button. When using a BookmarkableLink, the previous page _can_ be reached by the back button so it has to be written out. Are you using the development mode of Wicket? It always checks whether the page is serializable, if I recall correctly. The problem remains that the ManagedItemDecorator is not serializable. (see java.io.ObjectStreamClass.lookup) cheers, Frank On Tue, 2008-05-13 at 12:01 +0300, Eyal Golan wrote: First of all, thanks. (most of) all the above I found out. I mentioned weird because if that was the problem (Serialization or invalid constructor), then the Expand link would have never worked. Am I correct? BUT, The exception happens only after I go to a BookmarkableLink. It's not we didn't try to discover the problem before :) On Tue, May 13, 2008 at 11:16 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: On 5/13/08, Eyal Golan [EMAIL PROTECTED] wrote: We have a weird exception in our system. Not so weird when you read the exception trace. It is a dark art, but worth the effort of learning. My team mates created a non standard DataView: Uh oh... :) So read this part: 2008-05-13 10:55:21,885 ERROR [org.apache.wicket.RequestCycle] - Could not deserialize object using `org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory` object factory What does that mean? (Don't read ahead just yet, think about the message) It means that an object, your Item's model object, could not be deserialized. This means that one of your objects that are attached to the page does not honor the serialization contract. Specifically when you go through the stack trace and find the cause: Caused by: java.io.InvalidClassException: com.eurekify.tms.web.common.campaign.ManagedItemDecorator; no valid constructor It seems that there is something wrong with ManagedItemDecorator - it is missing some valid constructor. Now if you don't know why this is, then look up the InvalidClassException using google. This points to the following JavaDoc [1] and states: Thrown when the Serialization runtime detects one of the following problems with a Class. * The serial version of the class does not match that of the class descriptor read from the stream * The class contains unknown datatypes * The class does not have an accessible no-arg constructor Voila, there is your problem, which you could discover yourself given a bit of brain excercise. Martijn [1] http://java.sun.com/j2se/1.4.2/docs/api/java/io/InvalidClassException.html -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Good wicket patterns
You could have a look at the broadcaster that is discussed in
https://issues.apache.org/jira/browse/WICKET-1312
The solution that is proposed there uses a visitor instead of
registration. That has the advantage that you don't have to
_unregister_ at the appropriate time. Because Wicket does not have
lifecycle management of components you would have to do this by hand.
Of course, if your components are never replaced, this is not an issue.
cheers, Frank
On Thu, 2008-05-08 at 18:15 -0700, Scott Swank wrote:
e.g.
public class AjaxEvent
{
private SetComponent listeners = new HashSetComponent();
public void register(Component listener)
{
listeners.add(listener);
}
public void fire(AjaxRequestTarget request)
{
for (Component listener : listeners)
request.addComponent(listener);
}
}
On Thu, May 8, 2008 at 6:07 PM, Scott Swank [EMAIL PROTECTED] wrote:
Ajax
3. Now im working with more Ajax. What is a good inter component
communication scheme? Swing has its listeners, but in wicket i tend to
call
methods on dependent components from ajax event handlers. Is this a good
approach - (it atleast dont feel so good)?
I try to have my components just be a view of their model. Then it's
just a matter of setting the model(s) appropriately and refreshing the
components.
Alternately, create a AjaxEvent class that you subclass to represent
each of the actions in which you're interested. Put a collection of
those on your Page. Then have allow each component to register itself
as a listener of an event. Then an ajax call would result in
SomeAjaxEvent.fire(AjaxTargetRequest) and that would in turn call
addComponent() for each registered listener component.
- Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA
94952-3329 +1 (707) 773-4646
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Wicket + CMS
Hi, that is correct, Hippo CMS 7 should be ready for release in a few months time. It is a rewrite where the CMS itself is implemented in Wicket. plug shameless=true The repository is a JCR (JackRabbit) repository extended with workflow and faceted navigation. The CMS is composed as a set of plugins. These Wicket components can be configured and that can be dynamically swapped in and out of the application. We use this for example for the templates. Templates consist of a set of (template) plugins and a configuration in the repository. The template configuration can be edited in the CMS itself! /plug At the moment we're rethinking the architecture, so I can't give details on how plugins are implemented or how they are linked together at runtime. cheers, Frank On Thu, 2008-04-17 at 14:12 +0200, Noz, Felix wrote: Hi, I've also read about plans to use wicket integration in Hippo Cms and I will keep an eye on it. I've also managed to access OpenCms content with wicket but because we have a lot of JSP that we would like to reuse and we contemporary need a solid frontend framework integration we will - as a start - concentrate on a classic rerquest-based one with jsp view for now. Maybe we will recur to wicket again later. Thanks for your and all other people's answers. Regards Felix Noz -Ursprüngliche Nachricht- Von: StephenP [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. April 2008 11:57 An: users@wicket.apache.org Betreff: Re: Wicket + CMS Our project has tied in HippoCMS for pulling a portion of content into wicket pages. I don't have many details to hand but it wasn't too hard. Hippo has a xml over http interface that we use to cache content, before putting the xml elements into wicket models. We are using hippo version 6, but I think hippo version 7 (the next version) will be using wicket internally. I don't know if this will allow any stronger integration with a wicket app. Noz, Felix wrote: Hello everybody, I'm currently evaluating different Frontend Frameworks to use them with a Java-Based CMS (OpenCms) and I'm very interested in trying wicket. The CMS has got its own Template mechanism which is based on JSP. Because it would be a problem for us to throw away all existing Templates and JSP Tags my idea was to implement a ResourceStreamLocator that connects to the CMS via http and delivers the resources directly from the CMS so that the CMS is rather a pure persistence and template system. My questions are: - Is this a passible way to connect wicket to a jsp based system? - Are there any better solutions? - Does anybody else has experience in connecting OpenCms + wicket? Regards i.A. Felix Noz __ __ Felix Noz Junior IT-Berater Dipl. Informatiker (FH) comundus GmbH Schüttelgrabenring 3, 71332 Waiblingen Telefon +49 (0) 71 51-5 00 28-22 Internet www.comundus.com Geschäftsführer: Klaus Hillemeier Amtsgericht Stuttgart, HRB 264290 comundus ist ein Unternehmen der IT EXCELLENCE Group. __ __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-%2B-CMS-tp16696564p16720234.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Wicket + CMS
Hi Uwe, plug shameless=true The repository is a JCR (JackRabbit) repository extended with workflow and faceted navigation. The CMS is composed as a set of plugins. These Wicket components can be configured and that can be dynamically swapped in and out of the application. We use this for example for the templates. Templates consist of a set of (template) plugins and a configuration in the repository. The template configuration can be edited in the CMS itself! /plug will the actual delivery be done by a JSP frontend, or a Wicket frontend? at the moment, we're focussing on JSP. A custom tag library is under development that accesses the repository and allows url mapping. It should certainly be possible to develop a frontend in Wicket; the models that we use to access the repository are easily reused. To embed plugins, e.g. those used by the CMS, does require some support from the environment. The Wicket session needs to provide a valid JCR session, for example. And if JSP will be delivering, can we build CMS-agnostic wicket components that could wor as they would in a normal wicket app (wrapped by some plugin adapter of course)? yes, if you're components don't need to have any interaction with the CMS then this is certainly possible. When you do want to have an interaction, some additional constaints will (likely) be present due to the possible actions of other plugins. If you want to further discuss the Hippo CMS, then we should move the discussion to the hipporepos-dev mailing list. You can subscribe and visit the archives at http://lists.hippo.nl/mailman/listinfo/hipporepos-dev The traffic mainly consists of JIRA updates and svn-logs, but it should be possible to filter these out if you want to. thanks for the interest! cheers, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
object sharing between pages
Hi, please excuse my newbie question; is it correct that pages cannot share objects? (any pointers on the subject of wickets serialization would be greatly appreciated) I want to provide some feedback to the main page from a modal-window, and now do this by putting meta-data in the session. Is there a cleaner way to do this? thanks, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared how can this be? Aren't different pages written to different streams and thereby incapable of sharing objects? But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! ok, I'll go ahead with storing the object in the session directly (as meta-data) and use models in the pages to access this object. cheers, Frank Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
ok, I'll go ahead with storing the object in the session directly (as meta-data) and use models in the pages to access this object. May I ask what your use case is? it's very simple; when carrying out an action on page A, I want to display a modal window (are you sure? with ok/cancel). The modal window creates a separate page, B, with the label and the buttons. The information (a boolean) about what option was chosen determines what to do on page A when the modal window is closed. cheers, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
