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?).
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.)
===
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).
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)).
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?)
(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).
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...)
Lets me forceably terminate/invalidate/logout the session in a portable way.
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).
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...)
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>).
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'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
