sorry, only had time for a few short answers below... i have to work on getting wicket out the door!
jon
Dave E Martin wrote:
I have stumbled across wicket quite by accident (there are something like 5 frameworks just at apache.org to choose from, sigh), and am seriously looking into it.
I have the following concern however: The URLs it generates seem a bit revealing, and they also seem that they would encourage users to play with them (I certainly did, and got some interesting results). Are there any security implications to this (can a user manually "generate" a valid URL that they shouldn't?).
all wicket urls are session relative. you cannot accidentally or intentionally discover anything in another session by playing with urls. this is one of the advantages of wicket in terms of security.
Would it be/is it possible to have an obfuscated/encrypted URL option (they would still need to be legal URL strings of course) to: a: discourage the user from playing with it b: hide the implementation from the user c: make it unlikely that they could manaully generate some other valid URL into the application (even if doing so is safe/secure, which I hope it is). (it would also be nice to not have things like IPageView (or whatever) in bookmarkable URLs. (i've just started converting my app so i'm not really sure what bookmarkable URLs look like yet; in my case, I only have two URLs I want bookmarkable anyway: the end-user main menu, and the backoffice user main menu.)
i've thought about this for some time now. it would not be /too/ hard to do this, although it would cost you something in terms of memory for each URL generated. please submit an RFE if you want this looked at and we'll take a look for 1.1.
we try. don't know how successful we are from your point of view, but the components are all first class java components implemented with an ordinary java class.
===
And now the product of my swiss-cheesed mind, which ended up being rather lengthly. Some of it are concerns that I hope wicket (its developers) have thought about and considered, and some of it is ranting/raving (well not to bad I hope).
I have been implementing a project using JSF, but I have become disillusioned with JSF. In particular, it seems to require things to be defined in an average of 3 separate places, and they have to be kept consistent. It also seems to throw type-safety to the wind (one reason I dislike using PHP/perl). Bad/undefined outcomes don't generate an error, they just reload the current page. Bad/undefined values turn into blanks; sometimes you get a variableResolver exception, sometimes you just get a blank or a property whose value never updates. Also, detection of a number of errors is deferred until the last possible moment (a risk when relying on reflection to resolve things).
I also can't imagine handing a JSF page over to the web designer guy and getting taken seriously (and probably also for faces-config).
I was just about to start tenatively using Tapestry, when I stumbled across wicket (looking for Tapestry vs JSF articles). So far I am encouraged (in spite of having to learn the differences between the available documentation and how it actually works now (I am assuming however that the javadocs are up-to-date, at least they seem to be)).
I am looking for something which will:
Let me adhere to "once-and-only-once"; (I have to put it in web.xml, and in faces-config, and in my code, and somewhere under WEB-INF????, and I had to do lots of cut'n'paste because the reuse facilities are inadequate?)
Maintains type safety/compile-time-checking as much as possible;
Allows dynamic generation of lists and lets the user manipulate the individual rows separately or together). (example: 5 rows in a shopping cart, user can change quantity fields individually in all rows, then hit update at bottom of list, and have all rows updated to their individual new values. Each row can also have its own button (for instance "delete") that affects only that row. (this seems to *barely* work in jsf, and only after I took over the bean management, see below).
you can put anything you want into listview rows. each is a container that you get to populate. we've got delete/move-up/move-down links.
Allows me to easily reuse stuff (even multiple times on one page; for instance, I have an address form, and a place where I need a billing address and a physical address, and I only want to perform validation on the second form if the user indicated the two addresses aren't the same, and it would be nice to only actually code the form once. Again, in JSF this *barely* works, and enough contortions were involved that I seriously considered cut'n'paste as an alternative method of code reuse. Even so, I still had to put the billing and the physical addresses on separate pages to get the validation to not have a cow, and keep the backing properties separate (i'm using one address form, which is <jsp:include 'ed) (I just skip the second page if the user indicated that the addresses are the same)).
reusability is really a major focus in wicket. you can reuse components in all kinds of interesting ways, including creating Panels that hold complex, arbitrarily nested components and Borders (and soon markup inheritance) which decorate pages with common components. all very easy to do in wicket.
Realises that some things need to live longer than a request and shorter than a session (I gave up letting JSF "manage" my beans for me. I ended up with only one session-scope bean, and I let *that* bean manage the rest of my beans, under my control; and now i'm reluctant to give faces-config.xml over to the web design guy either, who would probably just be confused anyway). Perhaps i'm misusing/understanding JSF, but it doesn't seem to fit my thought processes very well. I generally prefer Eiffel/Java over Smalltalk/Perl when it comes to their paradigms. JSF seems designed to make the "whats a type?" crowd happy.
Allows for differing security levels for different parts of the application (anyone, must be in "installer" role, but be in "manager" role, must be in "manager" AND "netadmin" roles...), and makes it easy to keep track of whats what, and to change them, and make it unlikely that something will accidentally end up in the wrong constraint. (JSF/Tomcat's method of defining security makes me somewhat nervous in this regard. Its sort of nice having the container manage security, but its also somewhat concern generating as well. I've taken to making my web page layout mirror my security heirarchy, and just hope I never need to change something. (I take it in wicket I can just have "FireEmployee" inherit from "ManagerPage" and "AddDevice" inherit from "NetAdmin" page and "BuyWidget" inherit from "WebPage" where these superclases do the appropriate login/role checking, and changing a security requirement is as easy as changing the relevant base class, or pointing to a different base class?)
see library example. security in wicket is going to be its own thing. no need to deal with container security stuff. you can use inheritance and soon pagesets to manage access to pages. this won't really be fleshed out until 1.1 though... still a lot to do there, but the basic checkAccess() method in Page should accomplish quite a lot. no concept of roles yet, but we're looking at JAAS for 1.1.
(I like Wicket's keeping the pages right next to the code they go with. I find having to maintain separate mirrored (or not) hiearchies a bit of a pain. The reality seems to be that the pages aren't as independent of the code as they'd like to pretend to be).
yup.
Remains relatively stable (at least in 1.0+) or at least allows for easy migration (don't maintain a bad interface for a 100,000 years because you don't want to inconvenience the 5 users using it now... but on the other hand, don't unnecessarily inconvenience them either...)
this has been tricky with wicket for months. it should be stabilizing soon, but it's an OS project and we reserve the right to change things for the better if we missed something important that requires an incompatible change. i personally am starting to feel like we've gone through most of the big changes by now, but that's just a feeling. we've felt that way before and were missing some significant things.
Lets me forceably terminate/invalidate/logout the session in a portable way.
not sure i understand. you can call invalidate() on your session in onEndRequest() and that's guaranteed to work.
Still works when cookies are disabled, but tries to avoid humugous URLs when possible (JSF mostly works with cookies disabled, but something failed, ah, it was tomcat's login. Tomcat was managing the security, but apparently doesn't work without cookies).
should do.
If any state is stored in the client end, the client must not be able to alter it in some way which would still allow it to be valid but different (For instance, storing the current login identity as a serialized bean in a hidden form variable. While unlikely, a conniving and smart enough user could alter that...)
client side state is a 1.1 feature. you are not required to use any such feature in wicket. you can keep all your state server side for security. i personally would prefer that in all but the largest applications. then it might be worth tuning the hardest-hit pages with client-side models.
Oh, lastly i'd like some kind of text escaper thats smart enough to convert newlines into <p> or <br> tags, while still escaping all other constructs. (so far, in what i've used, i've had to turn off escaping completely and massage my output text by hand to get this effect). Basically, the goal is to get what a user types into a <textarea> to appear on output as they typed it (if they hit return twice to create a new paragraph, then it would be nice to appear that way on output, and I want to just store what they typed directly in my database. An even smarter escaper might let them use the "safe" html tags (and still convert newlines to <br> or <p>).
i think this might be MultilineLabel
Well, sorry, I didn't mean this to turn into a rant, but being confronted with 40+ choices that all claim to be the answer gets on ones mind/nerves after a while and I just don't have the time to look at them all beyond whats on the home page for the most part.
Wicket is my current front runner, hoping it really is a rounder wheel, but please let me know now if there is anything I should know, or if there might be a more appropriate choice for me. I'm also hoping whatever I do end up choosing has a future/won't be orphaned. JSF will probably live for obvious reasons, but the other 39 or so i'm not so sure about... hopefully quality will play a factor.
i think wicket is on the track to most of the things you're looking for. however, it's still very immature. many features have never even been used, let alone deployed... and we still have not shipped an RC for 1.0 yet (although we hope to do that this week). so i'd be very wary of using wicket on a serious for-profit, schedule-driven web application right now. but in a few weeks/months, that story may be quite a bit different.
jon
===
I'm looking for the O-O method of building webpages, rather than the C method (I don't need #include and corresponding macros and problems, because the system eliminates the need for it...)
--
Never go into an autoparts store and mention "reinventing the wheel" lest you be struck with a 5+ pound wheel catalog flung from halfway across the room...
-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
