Re: Autogenerating HTML files ...?
Hi Ashley, I actually wrote the list regarding a similar idea about a year ago. It seems like a handy thing for RAD and for newbies struggling with keeping simple CRUD pages in sync. However I can offer nothing but an encurraging great idea, go for it. :) /Casper Igor Vaynberg wrote: i dont see why it wouldnt be possible. if you can instantiate a page you can use a visitor to visit all the components and generate approximately appropriate markup. perhaps if you had something working you would get more interest. -igor On Mon, Nov 9, 2009 at 1:57 AM, Ashley Aitken mrhat...@mac.com wrote: Dear All, I have seen a feature in Wicket Bench (I think it is) that can automatically generate the Web component object construction hierarchy for a given Web form with Wicket ids. It's a neat feature. However, I am wondering if it would be possible to do the reverse. Could Wicket classes be extended to automatically generate the HTML file (based on the Wicket object hierarchy) if the HTML file doesn't already exist? Obviously, it couldn't generate the non-dynamic HTML aspects of a Web page, but at least it could provide a skeleton page? This could be configured to overwrite (or not) existing files each time the code changed. Perhaps it could be configured to include (for debugging purposes) some Wicket information for each item in the page (almost like a RAD solution but the intention is not for RAD). Perhaps it could even use a form of the generation gap pattern by putting each dynamic chunk into a separate HTML file and then #include them into a main HTML file which it doesn't get overwritten. Though I'm not sure how this would exactly work ... I've seen Wicket RAD and Wicket Web Beans but these are not what I am thinking about. Eventually, I would want a graphics / Web designer to complete the page around the skeleton dynamic HTML parts (that perhaps Wicket has autogenerated). I know this would never be the full solution but it may allow one to concentrate just on the Java code and not even have to worry about the HTML to start with. I think it could be an interesting approach. Is this possible? Has this already been done? Any comments appreciate. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!) - 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
Re: avoid setters / getters by using ?
Use Lombok (http://projectlombok.org/), it allows you to generate setters and getters through annotations: @Getter @Setter private String name; /Casper David Chang wrote: Martin, Thanks for your input. My intention is how to get rid of these boring setters/getters from service beans that are usually generated only for the purpose of spring-injection. Cheers! --- On Sun, 9/27/09, Martin Makundi martin.maku...@koodaripalvelut.com wrote: From: Martin Makundi martin.maku...@koodaripalvelut.com Subject: Re: avoid setters / getters by using ? To: users@wicket.apache.org Date: Sunday, September 27, 2009, 3:55 PM At least in wicket you can access the fields themselves using propertymodels. ** Martin 2009/9/27 David Chang david_q_zh...@yahoo.com: Hello, I have Wicket+Spring application. It has a service object which has a few DAO members. I can use Spring's autowiring to avoid mentioning the DAO dependencies for the service bean. However, in the Java program for the service bean, I still have to add setters and getters for each DAO member, which I don't like. How can I avoid these setters and getters? Using AOP? Any examples? I understand that this question is not strictly a Wicket, but I definitely want to ask my Wicket friends here. Thank you! - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GWT vs. Wicket?
P.S. people say my article is one sided but no-one can explain *why ;) - ok, ok this has been discussed to death in the comments there ... I should mention I love wicket (coming from JSF) but has only limited exposure to it while having no experience at all with GWT. However while reading, I did pick up a slight bias towards Wicket in the article, perhaps unintentional on your part but not really unexpected since you obviously do hang out here on the WIcket group. I guess the feeling comes from the fact that the pro/con comparisons don't seem quite balanced. I.e. there's no mentioning of the scalability adressability problem of holding state on the server, the managability problem in needing a java file for each html file (and keeping these in sync), nor the inherent bennefits of having a specialized compiler validate, optimize and strip data that's really primarily meant for the browser anyway. I did enjoy the article though, thanks for writing it. :) /Casper
Re: Wicket and (or) restlet
restlet is for building services not uis, that quote makes absolutely no sense. While I agree the quote smells of FUD, one doesn't necessarily exclude the other. The beauty of REST is its statelessness, addressability, representation negotiation, caching and other ways it embraces HTTP rather than run away from it (and use overloaded POST's with tiny RPC handlers for everything). In Jersey it's also possible to serve (dynamic) HTML through a standard templating engine, I'm doing this currently and achieving very high scalability while keeping things simple. The caveat with this approach is that you are stuck to the classic templating model and components don't really exist apart from whatever jQuery/ExtJS stuff you wire up manually. So probably like the OP, I can't help but wonder about the possebility of Wicket running on top as a model-view technology - or perhaps just a programming model adopted after Wicket. /Casper
Re: Wicket and (or) restlet
True, but as I said, one does not necessarily exclude the other. In its current state such a use of Jersey is best suited for low-interactivity, data-driven applications - but the same could be said for other web frameworks such as Stripes. Jersey provides implicit and explicit views through JSP's out of the box: http://blogs.sun.com/sandoz/entry/mvcj That's the way I use it, people have plugged in their own template layers. I'd be interested in a component model such as Wicket on top, which is why I reacted to this thread. I think there's a broad understanding that the Wicket model makes programmers happy. /Casper On Wed, Apr 1, 2009 at 7:25 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: huh? wicket is trying to address a completely different problem space - which is orthogonal to what restlet and other rest-like services are trying to achieve. do any of these restlet-like services provide anything to help you generate the ui? do they have jstl tags? components? templating? nothing out of the box right? you have to glue that yourself on top of them. -igor On Wed, Apr 1, 2009 at 10:05 AM, Casper Bang cas...@jbr.dk wrote: restlet is for building services not uis, that quote makes absolutely no sense. While I agree the quote smells of FUD, one doesn't necessarily exclude the other. The beauty of REST is its statelessness, addressability, representation negotiation, caching and other ways it embraces HTTP rather than run away from it (and use overloaded POST's with tiny RPC handlers for everything). In Jersey it's also possible to serve (dynamic) HTML through a standard templating engine, I'm doing this currently and achieving very high scalability while keeping things simple. The caveat with this approach is that you are stuck to the classic templating model and components don't really exist apart from whatever jQuery/ExtJS stuff you wire up manually. So probably like the OP, I can't help but wonder about the possebility of Wicket running on top as a model-view technology - or perhaps just a programming model adopted after Wicket. /Casper - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setting up REST API that can respond to requests alongside Wicket
Allow me to jump in, since it kinda touches on a related subject we discussed earlier today: http://www.nabble.com/Wicket-and-(or)-restlet-tt22822162.html#a22833918 What I understand from Jamie is to do kind of the reverse from what I wanted, that is, hook into the raw data Wicket is using to serve Ajax components etc. and use it to serve public REST requests. If this was possible, I would no longer be using Jersey to serve occasional web content but rather use Wicket to serve occasional REST requests. If I have completely misunderstood you Jamie and is thus stealing your thread, I apologize. /Casper On Thu, Apr 2, 2009 at 5:01 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: yeah, you can map wicket to /* and services to /services/*. wicket filter will let requests that do not map fallthrough, just make sure you have no wicket mounts that are on /services/*. i still dont get what you mean by wicket daos. wicket has no daos. if you put your services handling into the same webapp then it will all live in the same classloader. if you were using spring or guice then wicket would obtain the daos from spring or guice inside its components, and the same would happen inside your services classes. if you deploy this as a single webapp then the shared space is the servlet context which every filter and servlet can access. -igor On Wed, Apr 1, 2009 at 7:51 PM, jpswain jpsw...@gmail.com wrote: Igor, Thanks for the response. Sorry, I wasn't very clear when I said wicket realm. What I meant was to be able to access the Wicket DAO's and stuff like that. Maybe what I am talking about is only directly possible with objects that share the same classloader? Would the best way to offload the incoming REST requests with RMI? Also, would it be possible to map wicket to /* and services to /services/*? Finally, thanks for everything you and all the other Wicket developers do to advance Wicket and make it the best Web Framework on the planet!! It's really a pleasure to work with :) Jamie igor.vaynberg wrote: map your wicket filter to /app/* and your services filter/servlet to /services/* im not sure what you mean by services impl calling objects in the wicket realm - all that is or should be in the wicket realm are ui objects you wont have a need to reuse in your services.. -igor On Wed, Apr 1, 2009 at 6:03 PM, Jamie Swain jpsw...@gmail.com wrote: I'm sorry this isn't directly a Wicket question, but I thought you guys in here might be able to help :). What I'm doing is building a Wicket-based web app, and I would additionally like to offer some data to other sites/clients in the form of an HTTP-REST API (that responds to simple GET and POST requests and returns XML and/or JSON). (It would be something that works kind of like the Twitter API http://apiwiki.twitter.com/REST+API+Documentation). My question is what is the best way to access the objects and classes that Wicket can see and call methods on from my REST Web Service API. Do I create a separate servlet running the the same Tomcat Server that can call somehow objects in the Wicket realm? Or is there a class I can implement within my Wicket-based app that can respond to these REST requests? It would probably be most feasible for now to have it all integrated into the same app. I have been working with Wicket for a while, and feel pretty comfortable with it, but I don't really have any experience working with servlets, so I'd really appreciate a little guidance on this. I appreciate the help guys! Thanks, Jamie - 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 -- View this message in context: http://www.nabble.com/setting-up-REST-API-that-can-respond-to-requests-alongside-Wicket-tp22839000p22839851.html Sent from the Wicket - User 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Twenty Six Wicket Tricks
Sounds interesting, although it would be nice if you could mention a trick or two such as to provide us with a little more info. I'm guessing its different from what you'd find in the wiki?! Casper Jonathan Locke wrote: Well, over the break here I've started something I swore I would never do again (well, two things, if you include the JavaOne talk I'm working on). I'm writing a (hopefully relatively short) book. It's called Twenty-Six Wicket Tricks. Each trick in the book (lettered from A-Z) demonstrates something that people typically want to do and in the process builds a reusable and educational component. I've got 13 tricks coded up now and ideas for a handful more, but if there are any requests out there, please let me know. I'd also be interested in getting some idea how many people would be interested in this book (would provide some fuel for me to get it done). It does not cover any of the same ground as Wicket in Action (which you should buy if you have not already!), BTW. It's more of a companion to that book. Happy Holidays! Best, Jonathan -- View this message in context: http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p21214772.html Sent from the Wicket - User 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
Re: [OT] wicket users around the world
Work in Denmark, live in Canada (don't you just love technology?) and planning my strategy for converting my JSF-masochistic colleagues over to try Wicket. ;) /Casper Wadi Jalil Maluf wrote: Argentinians working on wicket and mobile apps integration Wadi -Mensaje original- De: Nino Saturnino Martinez Vazquez Wael [mailto:nino.marti...@jayway.dk] Enviado el: viernes, 12 de diciembre de 2008 5:48 Para: users@wicket.apache.org Asunto: Re: [OT] wicket users around the world Work in Denmark pimping wicket at every opportunity i get, lived all my life in Denmark, so half from Denmark and half from Spain :) francisco treacy wrote: to know a little bit more of our great (and vast) community, i was just wondering if you're keen on sharing where you come from and/or where you work with wicket... for instance, here argentinian/belgian working with wicket in antibes, france francisco - 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
Re: using annotation @AuthorizeInstantiation
Yeah, I asked about this last week or so when running into the same
problem. I now also do it the class way, and although that does feel
better than using strings, in my opinion it still isn't type safe. It
gives no syntax lookup and people are free to write Object.class which
will compile just fine. Marker interfaces are better for composability,
however if you are going to make a truly role based system, chances are
you'll want a backing roles table and that can get tricky with inheritance.
I'll probably go back to the enum way, which works fine enough IF you
are ok with having the role definitions mixed with the authorization
code. It's a small price to pay, I rewrote some of the annotation stuff
to make it easier to use anyway (AccessableTo, EnabledTo and VisibleTo )
which now just takes an array of values which means clean code like this:
@VisibleTo({Administrator.class, User.class})
...rather than:
|@AuthorizeAction(action = Action.RENDER, roles = {Roles.ADMIN,
Roles.USER})|
Anyway, just my 2 cents on the topic.
/Casper
Jeremy Thomerson wrote:
If you were going to do this, it would be much better (IMHO) to use
interfaces... This gives you interesting possibilities:
(Disclaimer - the following is not an original thought - Igor mentioned this
last week - give credit where it's due)
interface User
interface Admin extends User
interface ProjectManager extends Admin
interface SalesManager extends Admin
HERE'S THE KICKER:
interface TheBigBoss extends ProjectManager, SalesManager
Since those are just marker interfaces, I guess each of those would need
something like a single public static final implementation like:
public static final TheBigBoss INSTANCE = new TheBigBoss() {};
Something like that - anyway, MULTIPLE INHERITANCE FOR ROLES RULES!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why can't I initialize PasswordTextField?
Yeah I thought of the security issue, it seems though quite a few PHP
sites works like that (not to mention, build-in browser functionality
which does the same kind of unsafe client side caching).
In the idiom outlined in your source code, how can the server then
re-authorize without username and password. I assume the user table then
have to include a session field that is transferred and stored upon
initial login, and which is used to match up against on successive logins?
/Casper
Jeremy Thomerson wrote:
May I answer your question with a question?
Why would you want your password field to have the value pre-filled on the
page? Then the password is in plain text available to the user (and
assuming you're not on https, anyone in between). I've never seen an
instance where this was a good idea.
If you're trying to do an auto-login, you shouldn't show the login page at
all. Pseudo code would be:
if (getYourSession().isSignedIn() == false) {
String token = getCookie(someCookieID);
if (token not null and not empty) {
User user = lookupUser(token);
if (user != null) {
getYourSession().signIn(user);
} else {
// only here would you show login page, without anything pre-filled
because
// they're not already signed in and they don't have a cookie to sign
them in
setResponsePage(YourLoginPage.class);
}
}
}
On Tue, Dec 2, 2008 at 9:26 PM, Casper Bang [EMAIL PROTECTED] wrote:
I'm trying to implement credentials memory functionality for a login form
using cookies. I know there's an official example (
http://wicketstuff.org/wicket13/signin2/?x=7*:org.apache.wicket.examples.signin2.SignIn2)
however it simply delegates to some panel which is not available as source
on the page. So anyway, it should be simple, and all works great except that
I can not get the password field to get filled out upon page load. In my
constructor of my panel I do the following:
Cookie credentials =
((WebRequest)getRequestCycle().getRequest()).getCookie(credentials);
remember = credentials != null;
if(remember){
String[] credentialParts = credentials.getValue().split(:);
username = credentialParts[0];
password = credentialParts[1];
}
The fields username and password of the panel are bound to the form using a
CompoundPropertyModel. When I sniff request and response headers, I can see
that indeed the cookie info is sent around fine. I guess it has to do with
security somehow, but shouldn't this be possible even if I am using a
PasswordTextField?
Thanks in advance,
Casper
-
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: Why can't I initialize PasswordTextField?
James Carman wrote: The browser's saved passwords support doesn't transmit your password over HTTP along with the rest of the markup, though. It just remembers it and auto-populates it for you once it receives the HTML from the site. So, it's as unsafe as your computer is (hopefully you use a password on your computer). :) I guess I have a hard time seeing the security differences between retrieving a cookie vs. submitting credentials in a POST - both are insecure from man-in-the-middle attacks if not using SSL!? Anyway back to my original issue, as Timo points out, HTML just works that way. I guess what I see on java.net is browser functionality rather than application/cookie functionality. /Casper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why can't I initialize PasswordTextField?
I'm trying to implement credentials memory functionality for a login
form using cookies. I know there's an official example
(http://wicketstuff.org/wicket13/signin2/?x=7*:org.apache.wicket.examples.signin2.SignIn2)
however it simply delegates to some panel which is not available as
source on the page. So anyway, it should be simple, and all works great
except that I can not get the password field to get filled out upon page
load. In my constructor of my panel I do the following:
Cookie credentials =
((WebRequest)getRequestCycle().getRequest()).getCookie(credentials);
remember = credentials != null;
if(remember){
String[] credentialParts = credentials.getValue().split(:);
username = credentialParts[0];
password = credentialParts[1];
}
The fields username and password of the panel are bound to the form
using a CompoundPropertyModel. When I sniff request and response
headers, I can see that indeed the cookie info is sent around fine. I
guess it has to do with security somehow, but shouldn't this be possible
even if I am using a PasswordTextField?
Thanks in advance,
Casper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does org.apache.wicket.authorization revolve around string tokens?
Yeah I suppose that's the only viable alternative then, but it plays a little less nice with a JPA backed role table and also appears to be a step back to rely on inheritance rather than composition. Oh well, can't have it all - hopefully an extendable and more lenient Enum makes it into Java at some point to allow that kind of static modeling - it's in the Kijaro sandbox after all (http://freddy33.blogspot.com/search/label/abstract%20enum). /Casper Igor Vaynberg wrote: this is where the classes variation comes in. class AdminRole extends UserRole - done -igor On Thu, Nov 27, 2008 at 6:56 PM, Casper Bang [EMAIL PROTECTED] wrote: Yeah. First I actually didn't understand why until Igor pointed it out. I'm no longer using wicket-auth-roles, if one can live with the roles being defined along side the authorization code it works quite nicely (and with somewhat cleaner code). I ran into another issue however, trying to model how an ADMIN transitively is also a USER. Sadly the Sun compiler does not allow Enum forward referencing to itself, only the Eclipse compiler does. /Casper Ned Collyer wrote: Interestingly we used a similar approach with using classes as pseudo enums. Not being able to extend enums is a bit suckfull. igor.vaynberg wrote: the problem is that the enum would have to live *inside* the wicketstuffauth code. so wicketstuffauth would be the library that would need to define the enum - and it doesnt know about your application specific roles. at least this was the issue when it was first being designed. i havent really looked at it since than. -igor - 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]
Prototyping mode: Automatic markup generation
While I understand the Wicket authors do not want a magic framework, I wonder if anyone else than me ever wished for a development mode or option on the error page when protyping and receiving the very typical org.apache.wicket.WicketRuntimeException: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup. Would it not be possible for Wicket to simply ignore the markup aspect if so instructed, and generate the required markup on-the-fly from the Java tree? Perhaps it's because I am new, but I sure run into that wicket message a lot. Anyway, just a though. /Casper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why does org.apache.wicket.authorization revolve around string tokens?
What attracts me to Wicket is how it tries to do as much in type-safe Java code as possible, so I was a bit surprised with the finding that the org.apache.wicket.authorization stuff is not based upon Enum and EnumSet but rather type-unsafe string tokens. Are there good reasons for this design that outweighs the benefits of having code completion and static verification? (Extendability, decoupling, transitive relationships, runs on Java 1.4 etc.) Also, before I delve deeper into it, would it be a trivial matter to write a type safe version? Thanks in advance, Casper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does org.apache.wicket.authorization revolve around string tokens?
No but an application is designed for a given number of roles, what would you possibly accomplish by adding new roles without editing source code and account for the new behavior you are putting in? Seems to me the application would always need to be revised to work with these new roles (say modify web-pages annotations) no-matter if you do it with strings or enums. Anyway, perhaps I am being anal about it, but it doesn't strike me as fitting the Wicket philosophy I've picked up in other corners of the API. I was hoping for consensus that it would be beneficial to make it type-safe since it is part of a very visible and convenient API, but I'll try to write my own Enum version instead then. Thanks, Casper Igor Vaynberg wrote: because you cannot add custom enum values without editing source code. there is a version implemented using classes in wicketstuff somewhere. -igor On Thu, Nov 27, 2008 at 10:33 AM, Casper Bang [EMAIL PROTECTED] wrote: What attracts me to Wicket is how it tries to do as much in type-safe Java code as possible, so I was a bit surprised with the finding that the org.apache.wicket.authorization stuff is not based upon Enum and EnumSet but rather type-unsafe string tokens. Are there good reasons for this design that outweighs the benefits of having code completion and static verification? (Extendability, decoupling, transitive relationships, runs on Java 1.4 etc.) Also, before I delve deeper into it, would it be a trivial matter to write a type safe version? Thanks in advance, Casper - 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: Why does org.apache.wicket.authorization revolve around string tokens?
Yeah. First I actually didn't understand why until Igor pointed it out. I'm no longer using wicket-auth-roles, if one can live with the roles being defined along side the authorization code it works quite nicely (and with somewhat cleaner code). I ran into another issue however, trying to model how an ADMIN transitively is also a USER. Sadly the Sun compiler does not allow Enum forward referencing to itself, only the Eclipse compiler does. /Casper Ned Collyer wrote: Interestingly we used a similar approach with using classes as pseudo enums. Not being able to extend enums is a bit suckfull. igor.vaynberg wrote: the problem is that the enum would have to live *inside* the wicketstuffauth code. so wicketstuffauth would be the library that would need to define the enum - and it doesnt know about your application specific roles. at least this was the issue when it was first being designed. i havent really looked at it since than. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: Wicket Session grows too big real fast
Session/state-fullness is the no. #1 concern for me about Wicket. If you like to keep an eye on certain object trees during runtime, as an alternative to external profiling (which I've always found cumbersome) you can use TopCoders memory usage component: http://software.topcoder.com/catalog/c_component.jsp?comp=7220243ver=2 /Casper Bruno Cesar Borges wrote: Maybe would be a good idea if Wicket could report memory usage for non-Wicket_Components (and non-standard Java objects, like String and Collections) in memory. I don't know if this could ever be possible. -Mensagem original- De: Ladislav Thon [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:21 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast Agree. I was almost shocked :-) by Martijn's e-mail about keeping references between pages. I believed it is a standard practice to keep reference to previous page for the purpose of cancelling, and of course do it all the time. It seems very natural to me. O-oops. LT 2008/11/26 Piller Sébastien [EMAIL PROTECTED] I vote for such a document, too. I am now trying to reduce my session size too, and if I could find some hints somewhere (ie, be extremly carefull with anonymous subclasses, etc) it may be a big plus. jhp a écrit : Removing references pointing to previous pages solved a lot, very good point. Also making sure that individual domain objects don't get stored to session makes a difference. I have still a lot of code to go through to make sure that all unnecessary references don't get stored to session, but making a few changes in the most important pages makes already a big difference. I noticed that this is a problem that others have experienced too. I guess it is pretty easy unintentionally stuff the session with domain objects ,and if using modern day persistence framework, those domain objects can be quite large if they have collections etc. I think there is a need for small document outlining the common pitfalls and remedies for them. I haven't seen such. Wicket reference of course tells about LoadableDetachableModel, but this thread has info that I haven't found anywhere else. I might try compose such a document, if I just have the time and energy in the near future. Thanks to Martijn, Johan and John for your responses! BR, Jukka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. *** - 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]
Authorization and authentication
I'm trying to use the build-in authentication and authorization stuff of Wicket (1.4-rc1), as demonstrated on the examples page: http://wicketstuff.org/wicket13/index.html (there does not appear to be a http://wicketstuff.org/wicket14/index.html). However I can not see org.apache.wicket.authorization.strategies.role.Roles nor the entire package org.apache.wicket.authentication. It looks like it's part of the Wicket core, so I am going to guess this is due to changes between 1.3 and 1.4-rc1 which I am currently running up against. Is there an up-to-date example somewhere, has it been factored into the WASP/SWARM stuff or am I simply doing something wrong? Thanks in advance, /Casper -- View this message in context: http://www.nabble.com/Authorization-and-authentication-tp20629077p20629077.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]
Open FAQ/wiki somewhere?
In Wicket in Action it's mentioned briefly how one could use a
SimpleAttributeModifier to limit the text length of an input, by binding to
a JPA @Column annotation and its length attribute. This sounds nice DRY to
me (albeit perhaps a bit expensive?!) so I gave it a try:
protected String getColumnLength(Class entityName, String fieldName){
try {
Field field = entityName.getDeclaredField(fieldName);
field.setAccessible(true);
return
String.valueOf(field.getAnnotation(Column.class).length());
} catch (Exception ex) {
return ;
}
}
Which got me thinking (after spending an hour figuring out I had to use
setAccessible) if there's an open FAQ/wiki for these kind of things? I have
not been able to find any except the locked down official confluence. Google
is nice, but as a newbie it would be nice to have a central place with lots
of micro-examples/snippets to get you going.
/Casper
--
View this message in context:
http://www.nabble.com/Open-FAQ-wiki-somewhere--tp20607065p20607065.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]
Re: Open FAQ/wiki somewhere?
Oh wow, that's a virtual gold mine. Thanks!.
/Casper
jWeekend wrote:
Casper,
Something like
http://cwiki.apache.org/WICKET/how-to-do-things-in-wicket.html this ?
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Casper Bang wrote:
In Wicket in Action it's mentioned briefly how one could use a
SimpleAttributeModifier to limit the text length of an input, by binding
to a JPA @Column annotation and its length attribute. This sounds nice
DRY to me (albeit perhaps a bit expensive?!) so I gave it a try:
protected String getColumnLength(Class entityName, String fieldName){
try {
Field field = entityName.getDeclaredField(fieldName);
field.setAccessible(true);
return
String.valueOf(field.getAnnotation(Column.class).length());
} catch (Exception ex) {
return ;
}
}
Which got me thinking (after spending an hour figuring out I had to use
setAccessible) if there's an open FAQ/wiki for these kind of things? I
have not been able to find any except the locked down official
confluence. Google is nice, but as a newbie it would be nice to have a
central place with lots of micro-examples/snippets to get you going.
/Casper
--
View this message in context:
http://www.nabble.com/Open-FAQ-wiki-somewhere--tp20607065p20607796.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]
Re: Noob question: Wicket and statefull/stateless
Ok. It sounds like the general philosophy behind Wicket is server side
statefulness. I was kind of hoping this was not the case. Just out of
curiosity, haven't anyone tried serializing and embedding state out on the
webpage that could then be POST'ed between requests - a kind of hybrid model
between session and request scope? This homemade hybrid seems to work for
JSF, though oddly not an official strategy.
I actually just joined the mailinglist and posted, after not seeing my
message show up after 24h I tried posting again - this time it worked. I
apologize, now posting via Napple - latency and behavior somewhat more
deterministic.
/Casper
Jeremy Thomerson-5 wrote:
Tip: don't double post or some people will jump on you - it doesn't help
you
get a good answer.
Anyway, for completely stateless page transitions, etc, and how to put
data
into the URL rather than session, you need to use BookmarkablePageLink,
which will invoke the YourPage(PageParameters) constructor. Give those a
shot. For forms that put their data in the URL, search the list on
nabble
- there's been two threads this week dealing with it. Basically, mount a
bookmarkable page, don't use a Wicket form, just use an HTML form, and
make
it do a GET to the bookmarkable page URL. You can then use the
YourPage(PageParameters) constructor again.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 19, 2008 at 6:30 AM, [EMAIL PROTECTED] wrote:
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it
passed
along, such as to remain stateless? In JSF you would typically create a
request scoped backing bean and create some hidden inputs on the webpages
which can hold relevant id's or even base64 encoded and encrypted model
data. I thought perhaps Wicket were able to do this transparantly, as
suggested by the following example:
// LetterChoice.java
final ListString someLetters = Arrays.asList(A, D, C);
final DropDownChoice letter = new DropDownChoice(letter, new
ModelString(), someLetters);
StatelessForm form = new StatelessForm(keyForm) {
@Override
protected void onSubmit() {
setResponsePage( new LetterResult( someLetters,
Integer.parseInt( letter.getValue() ) ) );
}
};
// LetterResult.java
public LetterResult(ListString someLetters, int letterId) {
String selectedLetter = someLetters.get( letterId );
}
It appears you can pass both the model as well as the selection on to a
new page, but there's no special/hidden content in the generated
LetterChoice webpage. Does this simply mean what I am doing i tied to my
session by Wicket? Is there a way ensure there's no (or just a bare
minimum) of session state between each request? In general, what is the
mission goal when it comes to statefullness/statelessness of Wicket?
Thanks in advance,
Casper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20581578.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]
Re: Noob question: Wicket and statefull/stateless
Yes we've experienced issues with multiple browser windows as well as
synchronization of shared session resources. Again, this has nothing to do
with optimization but everything to do with craving a solid, simple
programming model for frontend developers.
/Casper
Johan Compagner wrote:
We tried that once, to have state transfered to the client, we didnt
like it (where it did go to) and we dropped it.
Cpu time and bandtwidth is way more expensive then memory. Wicket
takes now memory on the server but the overhead it would generate by
serializing and base64 every page into the result and the other way
around is just way way to expensive.
Did you encounter any real issues with state on the server or is this
again premature optimization??
On 11/19/08, Casper Bang [EMAIL PROTECTED] wrote:
Ok. It sounds like the general philosophy behind Wicket is server side
statefulness. I was kind of hoping this was not the case. Just out of
curiosity, haven't anyone tried serializing and embedding state out on
the
webpage that could then be POST'ed between requests - a kind of hybrid
model
between session and request scope? This homemade hybrid seems to work for
JSF, though oddly not an official strategy.
I actually just joined the mailinglist and posted, after not seeing my
message show up after 24h I tried posting again - this time it worked. I
apologize, now posting via Napple - latency and behavior somewhat more
deterministic.
/Casper
Jeremy Thomerson-5 wrote:
Tip: don't double post or some people will jump on you - it doesn't help
you
get a good answer.
Anyway, for completely stateless page transitions, etc, and how to put
data
into the URL rather than session, you need to use BookmarkablePageLink,
which will invoke the YourPage(PageParameters) constructor. Give those
a
shot. For forms that put their data in the URL, search the list on
nabble
- there's been two threads this week dealing with it. Basically, mount
a
bookmarkable page, don't use a Wicket form, just use an HTML form, and
make
it do a GET to the bookmarkable page URL. You can then use the
YourPage(PageParameters) constructor again.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 19, 2008 at 6:30 AM, [EMAIL PROTECTED] wrote:
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it
passed
along, such as to remain stateless? In JSF you would typically create a
request scoped backing bean and create some hidden inputs on the
webpages
which can hold relevant id's or even base64 encoded and encrypted model
data. I thought perhaps Wicket were able to do this transparantly, as
suggested by the following example:
// LetterChoice.java
final ListString someLetters = Arrays.asList(A, D, C);
final DropDownChoice letter = new DropDownChoice(letter, new
ModelString(), someLetters);
StatelessForm form = new StatelessForm(keyForm) {
@Override
protected void onSubmit() {
setResponsePage( new LetterResult( someLetters,
Integer.parseInt( letter.getValue() ) ) );
}
};
// LetterResult.java
public LetterResult(ListString someLetters, int letterId) {
String selectedLetter = someLetters.get( letterId );
}
It appears you can pass both the model as well as the selection on to a
new page, but there's no special/hidden content in the generated
LetterChoice webpage. Does this simply mean what I am doing i tied to
my
session by Wicket? Is there a way ensure there's no (or just a bare
minimum) of session state between each request? In general, what is the
mission goal when it comes to statefullness/statelessness of Wicket?
Thanks in advance,
Casper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20581578.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]
--
View this message in context:
http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20584228.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]
Noob question: Wicket and statefull/stateless
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it
passed along, such as to remain stateless? In JSF you would typically
create some hidden inputs which can hold relevant id's or even base64
encoded and encrypted model data. I thought perhaps Wicket were able to
do this transparantly, as suggested by the following example:
// LetterChoice.java
final ListString someLetters = Arrays.asList(A, D, C);
final DropDownChoice letter = new DropDownChoice(letter, new
ModelString(), someLetters);
StatelessForm form = new StatelessForm(keyForm) {
@Override
protected void onSubmit() {
setResponsePage( new LetterResult( someLetters,
Integer.parseInt( letter.getValue() ) ) );
}
};
// LetterResult.java
public LetterResult(ListString someLetters, int letterId) {
String selectedLetter = someLetters.get( letterId );
}
It appears you can pass both the model as well as the selection on to a
new page, but there's no special/hidden content in the generated
LetterChoice webpage. Does this simply mean what I am doing i tied to my
session or what exactly is going on?
Thanks in advance,
Casper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
