Ok, thats good, I don't want the user to be able to discover anything in their own session either, (or at least not anything they haven't seen already, or to "submit" against old data).
>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.
Done (but if the URLs are algorithmically transformed, you can get rid of the memory, in exchange for CPU).
>> Maintains type safety/compile-time-checking as much as possible; >> >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.
I'm not sure whats possible either, but I presume letting web pages be webpages/templates instead of code containers helps (although JSP isn't too bad in that they still produce compile-time errors, its just that compile time can get deferred), its all these tag libraries and pushing things off into run-time reflection... I looked at the resulting source from a JSF page, and about had a heart attack. Also, the willingness to create things on the fly, and silently convert daffodils into apple pies... (again, just not a mindset that works for me. Too easy to shoot yourself in the foot and not realize you've even done it until you faint from blood loss).
>> Allows me to easily reuse stuff (even multiple times on one page; for
>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.
So far, i've made me a "person" component (if i'm using the term correctly w/regards to Wicket). It has first/lastname, company, phone, email. And now, if I understand correctly, all I have to do is:
<span id="wicket-person1"/>
<span id="wicket-person2"/>
...
add("person1", person1 = new Person());
add("person2", person2 = new Person());
...
person1.getFirstname();
person2.getFirstname();
...
(and person.java contains things like "String firstName (with getter/setter) add("firstName", this, "firstName"), (boy did I have grief until I figured out that second (apparently ognl?) string had to be there (the -- I presume out-of-date -- example I was working from did this differently)).
to reuse it, and they'll keep their properties straight from each other, and I have a "Person.html" (and a Person.java) which is a form, which is substituted into those span tags...
(yes, i've downloaded the examples while i've been typing this and will start the grokking process with those...)
(Side note: the web editor i'm using, doesn't like <span/> it insists on <span></span> and i've noticed that adding a component, Wicket seems to insist on the <span/> variant. I assume Nvu is actually at fault here, but I can't afford dreamweaver 8( Nvu also insists on taking the </wicket:panel> tag and moving it directly after the <wicket:panel>, which I presume is definately a Nvu bug, and an annoying one). (alas, i'm really complaining about Nvu here, rather than wicket. I'll probably use Nvu to initially build messy things like tables with complicated formatting, then not let it touch it after that. I really loath hand-editing HTML, but then its not like I could use Nvu (or Dreamweaver!) to even build rudimentary JSF pages. At least Netbeans understands taglibs for code completion/syntax checking purposes, but I digress.)
>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 saw an example somewhere (possibly library?), and I was under the impression that I can just override checkAccess and do whatever I want (I can implement my own roles), although I presume you're alluding to providing built-in JAAS aware (or whatever) default implementations of checkAccess eventually?
>> (I like Wicket"s keeping the pages right next to the code they go
>yup.
I've since seem some postings elsewhere from people complaining about that decision, but I personally prefer Library Of Congress to Dewey Decimal.
>> 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.
Just in my prior iterations of this project, i've ran into some issues trying to get a user logged out, really. (including a case where something was perfectly happy to destroy my session, only to generate a new session with the same credentials as the previous session, without making the user log in again.)
>> still convert newlines to <br> or <p>).
>i think this might be MultilineLabel
I'll take a look at that. I've seen a few too many sites where the user (namely me) goes to the trouble of trying to minimally format my text by inserting newlines, only to have it turn into one giant run-on paragraph on the other end. Having a server-side "smart" escaper really helps. (or to beat this horse into a greasespot, something that turns plain-text into html, preserving newlines (turning them into <br> or <p>) but still converting < into $lt; and so forth...)
>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
Hm, well, I think i'll give it a go. While this is a real-world application, its not exactly mission-critical, Otherwise, I either stick with JSF, or learn Tapestry, or one of the other alternatives (and I really don't want to invest time learning something i'm ultimately not going to be using (assuming I ultimately will fall in love with Wicket when its ready for prime-time)).
If there is no calendar component yet, I presume I can roll my own as simple as a class file and an html template? (whereas building a "component" in JSF seems to be a major hollywood production. I suppose my Address example from earlier should have been implemented as a taglib/UIComponent to be properly reusable in the JSF sense, but that just seems too much like trying to use a 747 to go across town (which is still far enough that I didn't want to walk, but a jumbojet is overkill)).
-- 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 Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
