LinkedIn poll about Wicket
http://polls.linkedin.com/p/33616/pikzw <http://www.linkedin.com/e/plh/http%3A%2F%2Fpolls%2Elinkedin%2Ecom%2Fp%2F33616%2Fpikzw/FkIa/> -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941
Re: Extensible wicket application
Daniel Dominik Holúbek wrote: I have looked at OSGi a bit, but I do not understand it (basically I do not even now how to build a project with it :) ) Does anybody have any clue? I hope I have written this clearly enough. If not, feel free to ask :) Daniel, designing modular applications using classloader is not easy as it might seem. Your specific problem could be even simple, but soon you'll find more complex cases. So, if modules are important to you, I suggest you look at what others have done or to existing framework. You have cited OSGi an if you search a few weeks ago back in the archive of this mailing list there was a guy that linked a paper about how to use OSGi and Wicket. I've done something similar with the NetBeans Platform. You might also have a look at Glassfish v3 which is extensible by means of OSGi and could be a starting point. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [OT] Simple file repository?
Kaspar Fischer wrote: User's of my application will upload, edit, and delete files. For this, I'd like to have a simple "file repository" with the following features: - Files are stored on the file system. - Files are distributed over several folders (to avoid a single folder with 10,000 files, say). - Support for transactions Does anybody know of a simple Java library that satisfies these requirements? For example: a Hibernate database with a relation "Files" holding tuples (DocId, FilePath), and a service with: - id store(stream): creates from the stream a new file on the file system and inserts a new tuple into the relation, returns id - stream edit(id): returns a stream to a temporary copy of the file with the given id; updates the corresponding tuple to point to the temp file - void remove(id): removes the corresponding tuple form the relation ... and a background job which deletes dangling files. I suggest you something implemented on the top of JackRabbit (Java Content Repository). You might have a look at Brix, which is a CMS based on Wicket and JackRabbit. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: mountBookmarkablePage changes delimiter of PageParameters
Of course the arguments in my example have been copied in a hurry from working code, the former is the path and the latter the page class: mount(new QueryStringUrlCodingStrategy(path, class)); -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: mountBookmarkablePage changes delimiter of PageParameters
Steve Swinsburg wrote:
Hi all,
I have just noticed that mountBookmarkablePage changes
the delimiters of query string object to be all forward slashes. Why
is this?
For instance I want to get a url to a page class:
urlFor(MyPage.class, new PageParameters("id=" + userId)).toString());
which gives:
?wicket:bookmarkablePage=:my.package.here.MyPage&id=123456789
which is fine, but I wanted to get rid of the package name, so I
mounted the page like so:
mountBookmarkablePage("/myPage", MyPage.class);
and the same urlFor result gives:
myPage/id/123456789/
In my circumstances I cannot have slashes (legacy restriction) and
must have the ?&= style parameters but I still need the package to be
hidden, how could I go about doing this?
Use this:
mount(new QueryStringUrlCodingStrategy(pages[i+1], pageClass));
This will use the coding strategy you need. BTW, I'd like to have
something as:
myPage/123456789
that is "id" should be treated as a default parameter. I've searched but
I didn't find a preset UrlCodingStrategy: I suppose I need to write my
own, right?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941
Re: Using Eclipse & Wicket for Modular Webapps
Thomas Mäder wrote:
I don't know. What's the class loader model the Netbeans uses?
It should be similar to Eclipse, but I must confess my ignorance about
Eclipse. I'm investigating about this detail, thanks to the stuff you
pointed out in your interesting paper.
Thomas
BTW, I'm trying to understand why I didn't have to deal with the
IClassResolver for bookmarkable pages...
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941
Re: Using Eclipse & Wicket for Modular Webapps
The conclusion says: "But most important: it would be really interesting to actually build a real Wicket application with Eclipse. Only real world experience can show whether itʻs worth the hassle in the end." I think it's definitely possible. I'm running two customizations of a Wicket application based on the NetBeans Platform (I posted a few weeks ago a link about that: http://netbeans.dzone.com/articles/using-netbeans-platform-server) and so far everything works fine, in spite of the application being relatively complex. I was worried about some potential issues with the classloaders, which is a constant risk every time you deal with modular frameworks such as Eclipse Platform or NetBeans platform, but none manifested so far. BTW, I'm trying to understand why I didn't have to deal with the IClassResolver for bookmarkable pages... Thijs Vonk wrote: Looks really interresting, I've read the pdf. but it seems that there is a part missing at the end... On 2/6/09 6:02 PM, Thomas Mäder wrote: Hi Folks, I've been experimenting with getting the Eclipse plugin engine up inside a wicket application. The idea is to build Wicket applications out of plugins. You can find an article about my experiences (+sample code) here: http://devotek-it.ch/stuff.html I'm grateful for any feedback, both concerning the Eclipse/OSGI and the Wicket part. enjoy the weekend Thomas -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
GMap2: development mode + putting maps in a Panel = Google Maps broken
Hi. I've seen a strange error in GMap2 - as I've a very limited knowledge in HTML / Ajax, it might be a Google Maps API issue, I don't know. What happened is that I put the GMap2 component in another Panel - and Google Maps didn't work. I only saw a blank area and the Google logo put at the top of the map area. After a long work of exclusion, I've isolated two HTML fragment, one working and one not: WORKING Balestrino 17 [SV] As Simple as it may get. style="margin-left: auto; margin-right: auto; width: 600px; height: 400px;" wicket:id="mmmap"> style="display:none" wicket:id="infoWindow"> style="width: 100%; height: 100%; position: relative;" class="gmap" wicket:id="map"> NOT WORKING Balestrino 17 [SV] As Simple as it may get. style="margin-left: auto; margin-right: auto; width: 600px; height: 400px;" wicket:id="mmmap"> style="display:none" wicket:id="infoWindow"> style="width: 100%; height: 100%; position: relative;" class="gmap" wicket:id="map"> The only difference is that wicket:panel element around the div "infoWindow2b". Its presence screw up things. Configuring Wicket in deployment mode, the HTML is cleaned up and the wicket:panel element is removed, thus fixing things. "mmmap2a" is the div that matches the GMap2 component (I've partially tweaked the style for debugging); the component with wicket:id="map" is a Panel I'm using. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google Maps / GMap2?
Martin Funk wrote: its part of wicketstuff-core now checkout: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ and do the 'mvn install' there examples can be found here: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/gmap2-parent/gmap2-examples/ after core is installed the examples should run with: mvn jetty:run in the examples directory. Thank you, the backport worked fine (only 3 generics to drop and a funny Wicket 1.3.x typo in the APIs). I've seen a strange problem that I'm reporting in a separate message. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google Maps / GMap2?
Martin Funk wrote: Hi Fabrizio, basically this still holds true: http://www.nabble.com/where-is-wicket-contrib-gmap3-1.3.4-td20063260.html#a20064098 Thanks - but the URL of SVN seems to be wrong: [Mistral:Apache/Wicket/gmap2] fritz% svn co https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2 svn: URL 'https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2' doesn't exist Looking at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ these are the subdirectories I see: * .. * active-widgets-parent/ * pickwick/ * wicket-calendar/ * wicket-cluster/ * wicket-contrib-accordion/ * wicket-contrib-accordion-examples/ * wicket-contrib-bbcodecomponent/ * wicket-contrib-jamon/ * wicket-contrib-jasperreports/ * wicket-contrib-mootools/ * wicket-contrib-mootools-examples/ * wicket-iolite/ * wicket-persistence-template/ * wicket-security/ * wicketstuff-animator/ * wicketstuff-core/ * wicketstuff-dojo-1.1/ * wicketstuff-jmx-panel/ * wicketstuff-lightbox/ * wicketstuff-merged-resources/ * wicketstuff-merged-resources-examples/ * wicketstuff-picnik/ * wicketstuff-progressbar/ -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Google Maps / GMap2?
I need to integrate Google Maps in my Wicket application. I searched in the Wiki and found GMap2 - but I only see artifacts for Wicket 1.4 Is it possible to use it, or some alternative, with Wicket 1.3.x? Thanks. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Architectural dilemma: Wicket + REST (JSR311)
Erik van Oosten wrote: Wicket is all about stateful applications (though stateless stuff is useful and is supported). REST is all about stateless resources (though you sometimes need stateful hacks for login/authentication). Given these premises, I would not implement REST resources with Wicket (well, maybe if you have just 1 or 2). If you want to be more powerful, I would rather implement REST stuff with Spring MVC. Currently I am using Restlets which works very well also. Jersey sounds fine as well. I'm aware of the Wicket focus on stateful stuff. But, as you say, sometimes a few things are stateless - and, yes, I have just a few resources (three "categories" of objects, each would get its own URL). So, hmmm, still I don't see a strong motivation to go either way... -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Architectural dilemma: Wicket + REST (JSR311)
Hi there. My application, along with the usual HTML pages generated with Wicket, should also expose some RESTful services. These REST calls should return documents of various types: images, movies, as well as RDF/XML and N3 and so far. In an architectural spike I've made, I've used Jersey (implementation of JSR-311) and of course the two things can co-exist; so everything works and I don't have "technical" problems to solve (at the moment). The dilemma is architectural: I'm guessing whether getting JSR-311 in increases complexity in a way that can be avoided. In other words, could Wicket be able to serve the same facilities provided by JSR-311 (I mean, the subset I need)? Actually, Wicket can serve non-HTML contents by means of DynamicWebResource, so it seems doable. There are two specific questions now: 1. Security. For HTML pages, protected areas shoud handle login in the WIcket way (or what I assume is the normal Wicket way), i.e. rendering a specific HTML login page. For other types of documents, instead, I need HTTP authentication and perhaps in future some token-based approach. The point is that in any case either I deny the access or I give the resource, but I can't send back an HTML login page when the client expects a different document type. Would I be able to handle this with Wicket? 2. Having the same URL delivering different contents according to the Accept header. For instance, http://foo.bar/blah should normally render an HTML page; but if a Accept: text/n3 header is specified, a N3 should be returned. This means that in the former case the default Wicket workflow would be ok; in the latter, a DynamicWebResource should be provided. I think I can solve this using JSR-311: I could implement a super-filter that discriminates on the presence of the Accept: header and dispatches either to the Wicket or to the Jersey filter (of course I would implement a custom URL mount scheme so Wicket accepts the same URL as Jersey). Hints? I'm searching to find ASAP a reason for deciding to keep Jersey or to get rid of it, so I can go on with the development without too many fears of having to change something in future. Thanks. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket + NetBeans Platform (Platform, not IDE!)
Comments welcome... http://netbeans.dzone.com/articles/using-netbeans-platform-server -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 25, 2008, at 3:20 , Eelco Hillenius wrote: That can be a pain sometimes, or at least something to get used to. But that's Wicket's price for the stateful programming model it provides. Thanks Eelco :-) this is a good conclusion of the point (at least for me). As I said, I'll keep on using Wicket, because overall it's a lot better than others. But I'd like a "stateless" Wicket (or an option to become stateless). To be precise: I'm not asking for it, I understand statefulness is one of the fundamental architectural choices of the platform, so I think that a RFE here would be out of scope. But I'd like to know how many of the Wicket users would appreciate that. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 22:32 , Jeremy Thomerson wrote: There are other, just as simple options. A couple of examples below. Really, you're not being "forced" to do this by Wicket. If you want to hold *anything*, in *any* framework, in the HTTP session, it should be ... I'm only disagreeing on the part about it being Wicket forcing you to do it. Guys, but I'm ___not___ talking of the session :-) I'm not putting those things in the session. The problem is with __pages__ that get serialized, I think because they get into the session for the versioning. So it's Wicket doing that, right? -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 20:39 , Jeremy Thomerson wrote: It looks like my earlier message didn't go through. If really your big problem is that you have singleton restraints, where there must be only one instance ever of a particular object, Wicket is NOT the problem. Anytime you have that constraint, there are defensive programming things that you need to consider, even without Wicket. Joshua Bloch describes this well in Effective Java. To get around the problem you have, simply override readResolve and return the unique instance of that class. This can also be done with enums, etc, by overriding the serialization methods to provide custom serialization. And this *should* be done at any time that you think something is going to be serialized and you have unique constraints such as this. I know that technique (but thanks for the pointer), I've implemented it for other "unique" objects in a different project, where they _need_ to be serializable, because they are transferred over the network. But in that case the extra work is justified by the network - I mean, you must do that because it's a distributed environment. I find still funny to be forced to do the same in an application which is not distributed in nature. If I'm forced to write extra code, probably some model wrapper is better at this point, and probably it's worth while spend a few time to try finding something that can be extensively reused in the same project for different classes (this is what I referred to "design workaround" in my first mail). But, I repeat, I feel like it would be better if I wouldn't be forced to do that. BTW, things are more complex than your example: my objects are not "singletons", rather they are similar to "flyweights", they are instantiated in multiple instances, but have an uniqueness constraint - that is, each instance represents a concept (say, with an internal id) and there can't be two instances with the same id. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 12:14 , Johan Compagner wrote: what you are describing are services and yes those shouldnt be hold on to in wicket components/models In my case, it's an entity that has the uniqueness constraint, not a service; for what concern images, first you have to write some code because BufferedImage isn't serializable by itself; and, second, it would have some memory consumption impacts. Keeping the discussion more in general, as per thread subject, my point is that Wicket is imposing me too many constraints on my design. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 10:38 , Johan Compagner wrote: It is just simple if you want to play safe an nice be sure everything you put in the session is serializable It _isn't_ that simple. If you have to put an Image, or classes made by third parties, or classes made by me for which ___I don't want___ that Wicket duplicates an object because the related class has been designed to guarantee a single instance for each object identity. I have to use detachable wrappers, which is not the end of the world, but a great annoyance and a source of code proliferation... -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 10:22 , Johan Compagner wrote: no this is not true. Tomcat, the default tomcat installation, already uses serialization by default. But you can disable it, right? httpsessionstore does work but has its drawbacks yes. And those can really only be solved by using serialization because we need to be able to create clones Or you as a developer disable page versioning on all your pages and then just use the back button for pages itself and make a simple store that just keeps 5 pages in history or something like that. Well, actually I don't want page versioning on my application, even though I'm not yet sure I can avoid it (I still have to study the implications of the specs for v2.0). In any case, I believe (but again there are high chances I am wrong) things have changed in 1.4. In other words, I think I have disabled page versioning in my application using Wicket 1.3 and everything is fine, but I fear I won't be able to port is as is to Wicket 1.4. Right? -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 24, 2008, at 8:58 , Johan Compagner wrote: Its not just wicket who expects serializable.. A webcontainer also expects every thing in the http session to be serializeable and not just for clustering.. Also for restarts or the AFAIK it's not true: J2EE application *may* ask for serialization if you enable some kind of clustering in the webserver. But above all that happens for the *session*, not for each datum I manage :-) container could flush idle session to disk to conserve memory. And wicket only wants it if you use the diskpagestore so if you dont use that then wicket doesnt really care AFAIK (but here with higher margins of error) you can't avoid the use of the diskpagestore on Wicket 1.4. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 23, 2008, at 13:52 , Michael Sparer wrote: "The thing that really frustrates me is the fact you're forcing me to use serializable objects, even if I don't need to (and when I go with clustering, I'll use Terracotta). But I'm confident I'll find some design work-around on that." I don't agree with you in this point. The "design work-around" you're talking about is the proper use of models. We're clustering with Terracotta and none of our model objects actually is Serializable ... Well, it just sounds as the point where I want to go :-) At the moment most of my models are not serializable, but I'm still with Wicket 1.3. AFAIK in Wicket 1.4 I'll have problems with that, unless I use the detachable stuff. Or am I wrong? -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "This time last year" .... is Wicket really a disappointment?
On Jul 23, 2008, at 13:19 , Alex Objelean wrote: I've recently found this post on dzone: http://java.dzone.com/news/this-time-last-year This time last year ... What is your oppinion about this? In short, I could compare (partially) it with my feelings about Apple. I was so excited when I abandoned Windows for Mac OS X, but after four years Mac OS X is not up to my expectations; but I consider it still the best of competitors (the parallel stops here: today I'd happily leave Mac OS X and Apple if I could, but I can't; while I'm not willing to abandon Wicket). The v1 of my most strategic web project (a direct customer) has been developed in Wicket (1.3), and now I'm working on v2, which will be developed on Wicket of course. The thing that really frustrates me is the fact you're forcing me to use serializable objects, even if I don't need to (and when I go with clustering, I'll use Terracotta). But I'm confident I'll find some design work-around on that. Also, I appreciated Wicket for its simplicity and control put in my hands in comparison with JSF; but I must say that after two years, I think the simplicity thing is still true, but not to the extent I expected. Given that, I'm still involved in other technologies such as JSF (consulting for customers) and in the comparison Wicket wins hands down. A point worth to be noted, though, is that I was surprised how productive some people is with JSF and the NetBeans Visual Designer, even people that I discovered is not proficient with Java at all (please note that while I'm a member of the NetBeans Dream Team, so you bet I'm a NetBeans enthusiast, I never use JSF and the NetBeans Visual Designer when I make the decision on the framework ant the tool). -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
On May 22, 2008, at 0:24 , Jonathan Locke wrote: For myself (and I think a lot of the Java community), I would have preferred an awesome version of generics that was easier to use, less efficient and broke backwards compatibility. At a deeper level, I think there was a key ... and in this way the other million of people would have complained. early mistake in not planning for and providing mechanisms for breaking backwards compatibility in Java in order to improve the platform. The generics fiasco is just one manifestation of this larger problem. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
On Mar 16, 2008, at 16:58 , Phil Grimm wrote: Another YES for 1.5 Phil +1 -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Our new and shiny Wicket site!
+1, especially if the site is really shiny, you can understand things that can be done with the framework and have some inspiration. On 28/feb/08, at 08:19, Nino Saturnino Martinez Vazquez Wael wrote: +1, it also kind of opens up allowing for questions to the site announced... regards Nino Matej Knopp wrote: I don't think there is anything wrong with posting emails about new wicket based sites. Not everyone has the time to be checking wiki pages constantly. -Matej On Wed, Feb 27, 2008 at 11:30 AM, C. Bergström <[EMAIL PROTECTED]> wrote: On Wed, 2008-02-27 at 11:22 +0100, Daniel Frisk wrote: > After a couple of months coding we have released our Wicket website! > It has generally been a pleasure porting our jsp site and we have been > able to add a lot of functionality as well. Check it out at http://jalbum.net I think this sort of enthusiasm is great, but a wiki page 'sites using wicket' has been created for this reason. I didn't read the site, but [1] is especially slow. I'd definitely profile that page and make sure you're both using caching and that your cache is tuned properly. Success! ./C [1] http://jalbum.net/skins/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
Again with missing update with AJAX...
Hello.
I've still got problems with updating a page component from AJAX,
this time from a popup window.
Everything starts with a specific component for entering a date (it's
a special date, so I can't use the component provided with Wicket):
public class VRCDateField extends Panel
{
public VRCDateField (final String id, final IModelT
date, final VRCDateModalWindow modal)
{
super(id);
final String notSet = "not set";
final Label label = new Label("label", new
DefaultModelT()
{
@Override
public String getValue()
{
return DateFormat.format(date.getValue(), notSet);
}
});
label.setOutputMarkupId(true);
label.setOutputMarkupPlaceholderTag(true);
add(modal.createOpenLink("edit", date, label));
}
}
public class VRCDateModalWindow extends ModalWindow
{
private VRCDatePage datePage;
private Label label;
private IModelT dateModel;
public VRCDateModalWindow (final String id, final Page page)
{
super(id);
setPageCreator(new ModalWindow.PageCreator()
{
public Page createPage()
{
datePage = new VRCDatePage(VRCDateModalWindow.this);
datePage.setDateModel(dateModel);
return datePage;
}
});
setInitialWidth(500);
setInitialHeight(170);
setResizable(false);
}
@Override
public void close (final AjaxRequestTarget target)
{
super.close(target);
target.addComponent(label);
}
public AjaxLink createOpenLink (final String id, final
IModelT dateModel, final Label label)
{
final AjaxLink ajaxLink = new AjaxLink(id)
{
public void onClick (final AjaxRequestTarget target)
{
VRCDateModalWindow.this.dateModel = dateModel;
VRCDateModalWindow.this.label = label;
VRCDateModalWindow.super.show(target);
}
};
ajaxLink.add(label);
return ajaxLink;
}
}
I'm not attaching the whole listing of VRCDatePage, but the key
points are:
form.add(new AjaxSubmitButton("okButton", form)
{
protected void onSubmit (final AjaxRequestTarget
target, final Form form)
{
updateDate();
modalWindow.close(target);
}
});
where updateDate() updates the date model. Indeed the model gets
correctly updated since I see the new value gets to the database. But
the label doesn't get updated. I supposes everything was with the
setOutputMarkupId() and eventually with the
setOutputMarkupPlaceholderTag(), but clearly I'm missing something else.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[EMAIL PROTECTED] - mobile: +39 348.150.6941
Thanks for the fixes about serialization
It looks that disabling versioning and changing the store made all of my problems to disappear, including the deterministic session expiration with my popups. Thanks. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
Using Ajax to hide/show components
Hello.I have a custom component called CollapsiblePanel that has a header with an icon; clicking on the icon, the panel get shown or hidden (see picture in attachment for a quick view). The first listing is the current version of the link used to do the thing, and it works, but uses a regular request/response cycle, while I'd like to do this in the Ajax fashion.So I changed it into the second listing, where I've used the AjaxFallbackLink, I've set setOutputMarkupId(true) and I'm adding the component whose state I'm changing to the ajaxTarget.But it doesn' work (it does nothing). What's I'm doing wrong?Thanks.
Picture 1.png
Description: application/applefile
<>public class CollapseLink extends Link // AjaxLink { private final Panel target; private final VRCSession session; private final String attributeName; public CollapseLink (final String id, final Panel target, final boolean initialVisibilityState) { super(id); this.target = target; session = VRCSession.get(); attributeName = target.getClass().getName() + "_isVisible"; boolean visible = initialVisibilityState; if (session.getObject(attributeName) != null) { visible = isExpanded(); } target.setVisible(visible); session.putObject(attributeName, visible); } public boolean isExpanded () { return (Boolean)session.getObject(attributeName); } [EMAIL PROTECTED] public void onClick() { boolean visible = isExpanded(); visible = !visible; target.setVisible(visible); session.putObject(attributeName, visible); final String imageName = isExpanded() ? "expanded.png" : "collapsed.png"; this.replace(new Image("collapseIcon", new Model(imageName))); } }public class CollapseLink extends AjaxFallbackLink { private final Panel target; private final VRCSession session; private final String attributeName; public CollapseLink (final String id, final Panel target, final boolean initialVisibilityState) { super(id); this.target = target; session = VRCSession.get(); attributeName = target.getClass().getName() + "_isVisible"; boolean visible = initialVisibilityState; if (session.getObject(attributeName) != null) { visible = isExpanded(); } target.setVisible(visible); target.setOutputMarkupId(true); session.putObject(attributeName, visible); } public boolean isExpanded () { return (Boolean)session.getObject(attributeName); } [EMAIL PROTECTED] public void onClick (final AjaxRequestTarget ajaxRequestTarget) { boolean visible = isExpanded(); visible = !visible; target.setVisible(visible); session.putObject(attributeName, visible); final String imageName = isExpanded() ? "expanded.png" : "collapsed.png"; this.replace(new Image("collapseIcon", new Model(imageName))); ajaxRequestTarget.addComponent(target); } } -- Fabrizio Giudici, Ph.D. - Java Architect, Project ManagerTidalwave s.a.s. - "We make Java work. Everywhere."weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog[EMAIL PROTECTED] - mobile: +39 348.150.6941
Re: Customizing logging
On 07/feb/08, at 20:36, Igor Vaynberg wrote:
do you have slf4j adapter for jdk logging jar?
http://www.slf4j.org/api/org/slf4j/impl/JDK14LoggerAdapter.html
Yes, I've added it when I upgraded to 1.3.0 (I bet that without it I
wouldn't have any logging at all from Wicket). But I always had that
problem, since when I started developing with 1.2.
-igor
On Feb 7, 2008 5:13 AM, Fabrizio Giudici
<[EMAIL PROTECTED]> wrote:
Ok, that's really silly. In my application I use java.util.logging
(and I need/want to use it, since some external components use it).
For all the projects I've developed in every contest, from JSP to JSF
to Swing etc... I've always used a custom logging formatter that puts
every event in a single line (grep friendly) and with specific tabs
that I've got acquainted to use and allow me to inspect thousands of
lines in a very short time.
So far, I wasn't able to install it in my Wicket application.
This is what I have in my WebApplications subclass that gets
initialized at startup:
private void setupLogging ()
{
try
{
InputStream is = getClass().getResourceAsStream("/
log.properties");
LogManager.getLogManager().readConfiguration(is);
is.close();
final PlainLogFormatter formatter = new
PlainLogFormatter
();
Logger rootLogger = Logger.getLogger(CLASS);
while (rootLogger.getParent() != null)
{
rootLogger = rootLogger.getParent();
}
for (final Handler handler : rootLogger.getHandlers())
{
handler.setFormatter(formatter);
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
Indeed, log.properties is read and evaluated, in fact I can control
the logging levels etc. I can configure everything BUT the formatter.
If I specify it, I get the nigthmare XML formatter.
Even the code that navigates the loggers and manually sets the
formatter doesn't work (for instance, I use it in a NetBeans RCP
application where I know that the formatter can't be applied for
classloader issues). But here it doesn't work. This is somewhat a
minor issue, but now that I'm doing the final polishing I'd like to
have logs like I want to see :-)
Thanks.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[EMAIL PROTECTED] - mobile: +39 348.150.6941
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[EMAIL PROTECTED] - mobile: +39 348.150.6941
users@wicket.apache.org
Hello. My navigator panels (e.g. from AjaxFallbackDefaultDataTable, GridView, etc... looks like << < 1 2 3 > >>. I'd like to replace the lt and gt with icons, and to control the style of the numbers. How do I do that? Thanks. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
Customizing logging
Ok, that's really silly. In my application I use java.util.logging
(and I need/want to use it, since some external components use it).
For all the projects I've developed in every contest, from JSP to JSF
to Swing etc... I've always used a custom logging formatter that puts
every event in a single line (grep friendly) and with specific tabs
that I've got acquainted to use and allow me to inspect thousands of
lines in a very short time.
So far, I wasn't able to install it in my Wicket application.
This is what I have in my WebApplications subclass that gets
initialized at startup:
private void setupLogging ()
{
try
{
InputStream is = getClass().getResourceAsStream("/
log.properties");
LogManager.getLogManager().readConfiguration(is);
is.close();
final PlainLogFormatter formatter = new PlainLogFormatter
();
Logger rootLogger = Logger.getLogger(CLASS);
while (rootLogger.getParent() != null)
{
rootLogger = rootLogger.getParent();
}
for (final Handler handler : rootLogger.getHandlers())
{
handler.setFormatter(formatter);
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
Indeed, log.properties is read and evaluated, in fact I can control
the logging levels etc. I can configure everything BUT the formatter.
If I specify it, I get the nigthmare XML formatter.
Even the code that navigates the loggers and manually sets the
formatter doesn't work (for instance, I use it in a NetBeans RCP
application where I know that the formatter can't be applied for
classloader issues). But here it doesn't work. This is somewhat a
minor issue, but now that I'm doing the final polishing I'd like to
have logs like I want to see :-)
Thanks.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[EMAIL PROTECTED] - mobile: +39 348.150.6941
Re: Some questions - mainly about session expiration and serialization
On 06/feb/08, at 19:31, Igor Vaynberg wrote: sure, you can disable the versioning completely, but then you also wont have a proper backbutton support. versioning is there for a reason... -igor I understand it, but I don't like backbutton support :-) When I disable the versioning (I suppose I just need to call setVersioned(false) in the base page of my hierarchy) what is the behaviour when I hit the back button? Will I get "page expired" or will I just make the relevant page class to be run? -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
Re: Some questions - mainly about session expiration and serialization
Are you using our modal window implementation or your own?
Wicket implementation. BTW, I have another modal window that doesn't
create problem. I'll later post the code, when I'm able to cut it down.
3. I have still some confusion about serialization of things
in sessions. I've always got some objects that are not
serializable and caused tons of exceptions in log files, but
no harm other than it. I'm now wondering whether they can
trigger one of the above problems, and anyway before going
into production I'd like to face with this issue in a
definitive fashion. I know about the possibility of using
detachable objects, nevertheless I need first to understand
why this serialization thing can't be disabled - after all
I've got no need for clustering in near future (and if I
should do it, I'd probably go with Terracotta). Also, in
version 1.2 I once saw that there was a UserSession (?)
method that looked like it was useful for disabling
serialization, and I had a mental note about using it, but
it looks like it disappeared in 1.3.0. Hints?
Serialization has always been needed in wicket for things other then
cluster replication. Versioning has been one of those reasons. We
would use serialization mostly for cloning an object, so that we can
keep a reference to its previous state for rolling back a version.
With 1.3.1 this has changed dramatically. In order to free up session
space (1.2 would keep x pages in session) 1.3.1 only keeps the most
current page in session and spools older pages to disk via
serialization. So if you hit a page that has a serialization problem
and later come back to it via back button and click a link/submit a
form you will get a page expired error. My recommendation is to make
sure you use detachable models or make your objects serializable. In
the meantime, try
class MyApplication extends WebApplication { ISessionStore
newSessionStore() { return new HttpSessionStore();}}
that will turn off disk spooling and will make 1.3 behave more like
1.2 in that regard.
Ok, I'll try this just to see if it can at least solve immediately
the problem, then go for some refactoring. My question is: but if I
don't need (and don't want) page versioning, and I disable it, is
serialization still necessary?
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[EMAIL PROTECTED] - mobile: +39 348.150.6941
