> IMHO, linking FileUploadField-s (which we need to browse for the correct > input file in the browser) with the specific (FileUpload, File) > implementation of the results of the multi-part HTTP POST streams (created > when the form is submitted) is too strong (and limiting) for a "generic" > [and the only available!] contract for multi-part HTTP POST streams in a > generic-purpose web framework like wicket. So, I'd suggest either leaving > things the way they are (FileUploadField-s will return null for FileUpload > when File upload is not used) or eliminating those FileUpload-related > methods (let the user get this info from (IMultipartWebRequest)request > instead), or creating an extra layer of objects (StreamUploadField-s, which > would be a super-class for FileUploadField-s without FileUpload-related > contract obligations). In the latter case, you'd give users those needed > generic components that "look and feel" (and smell :) ) like files on the > client side, but are free for interpretation on the server side. Still, > today's FileUploadField-s would be there as subclasses (in all their > full-contract "glory") for backward compatibility...
In general this sounds good to me. It would be a great help to us if someone (you) could provide us with a patch to make this concrete. Without a patch, I'm afraid this would be on the bottom of our current priority list (though we can do the change in Form anyway). Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
