Conversation with #richfaces_staff at Thu 21 Oct 2010 Konstantin@irc.freenode.net (irc)

(05:27:34 PM) ishaikovsky: http://community.jboss.org/wiki/FileUploadMigrationtoRichFaces4
(05:27:36 PM) ishaikovsky: wiki page
(05:28:20 PM) ***balunasj looking...
(05:29:07 PM) alexsmirnov: is flash mode actual today ? As I remember, it was workaround for some old browsers.
(05:29:34 PM) ishaikovsky: alexsmirnov, no actual
(05:29:37 PM) nbelaevski: alexsmirnov: no, that's an extension - initially HTML mode was implemented
(05:29:42 PM) ishaikovsky: some features not available with html
(05:29:51 PM) ishaikovsky: you can;t add multiple files
(05:29:58 PM) ishaikovsky: can;t filter browser list
(05:30:03 PM) nbelaevski: alexsmirnov: multi selection, client filtering by types, client progress
(05:30:08 PM) ishaikovsky: and some more points
(05:30:11 PM) ishaikovsky: need to look deeply
(05:30:23 PM) ishaikovsky: some features previosly done through server
(05:30:29 PM) ishaikovsky: could be moved to flash level ideally
(05:30:44 PM) ishaikovsky: so it could became even more rich'er
(05:30:45 PM) ishaikovsky: :)
(05:30:55 PM) balunasj: So if html is all that will be in M4 how will you handle some of the options in the list?
(05:31:06 PM) balunasj: i.e. multiple uploads, and filtering, etc...
(05:31:29 PM) ishaikovsky: balunasj, it will be still multiple
(05:31:36 PM) ishaikovsky: and has the same features
(05:31:47 PM) ishaikovsky: just flash mode resolves that in more gracefull way
(05:32:10 PM) nbelaevski: balunasj: flash mode allows to add several files by one click
(05:32:19 PM) balunasj: ishaikovsky: ok good, so not that unsupported, but just not as clean.
(05:32:21 PM) balunasj: ok
(05:32:22 PM) nbelaevski: balunasj: with HTML you have to click add several times
(05:32:32 PM) ishaikovsky: balunasj, the same features but sometimes just more clicks yes
(05:33:21 PM) balunasj: Will setting upload location be the same place?
(05:33:28 PM) balunasj: s/place/way?
(05:34:23 PM) ishaikovsky: balunasj, not sure wht you mean
(05:34:40 PM) ishaikovsky: you mean storing files to provide to the developer listener
(05:34:41 PM) ishaikovsky: ?
(05:34:52 PM) ishaikovsky: it's in memory storing or temp files at server
(05:34:58 PM) balunasj: in memory/disk file storing. Will the location of the files be set as context param?
(05:35:04 PM) ishaikovsky: and dev responsible for moving to some storage
(05:35:12 PM) ishaikovsky: balunasj, ah.. I think yes
(05:35:21 PM) balunasj: ok
(05:35:47 PM) balunasj: Will uploadListener be part of M4?
(05:36:13 PM) ishaikovsky: sure as it's the only way to process uploaded files
(05:36:26 PM) nbelaevski: ishaikovsky: there are two ways actually
(05:36:42 PM) nbelaevski: one via listener another via uploadData collection
(05:37:09 PM) ishaikovsky: nbelaevski, and that's what we discussed
(05:37:19 PM) ishaikovsky: balunasj, has proposal to leave just one point
(05:37:30 PM) ishaikovsky: to choose the way. to store in the model or to use listener
(05:37:46 PM) ishaikovsky: I do not think providing two points for processing is a good way
(05:38:07 PM) nbelaevski: we could use listener for the model - the difference is in the time when it's triggered
(05:38:24 PM) nbelaevski: i.e. for each file completed or when all are done
(05:38:26 PM) ishaikovsky: I revised analogous libraries. Them do not use models also but just pass the file to dev listener for processing
(05:38:51 PM) nbelaevski: we upload files one by one, so listener is better for us
(05:39:11 PM) balunasj: If it is in listener we have more fine grain control
(05:39:28 PM) nbelaevski: one by one because they can be added to upload queue when files were already submitted for uploading
(05:39:41 PM) nbelaevski: yes, more fine-grained control
(05:39:45 PM) balunasj: I would want to be able to mark or cancel uploads if one of the files fail for what ever reason.
(05:40:10 PM) ishaikovsky: agree and also prefer listener
(05:40:24 PM) ishaikovsky: So I think that we should remove uploadData - that's why placed to the remove section
(05:40:47 PM) balunasj: ok - just wanted to make sure the listener was part of initial plan :-)
(05:41:03 PM) nbelaevski: balunasj: can you please explain more what do you mean by "mark"?
(05:41:04 PM) ishaikovsky: yes :)
(05:41:50 PM) balunasj: nbelaevski: I mean mark with msg, or validation exception ( I know part of the discussion at the bottom of doc )
(05:42:06 PM) balunasj: Is the fine grain control at that level of functionality?
(05:42:14 PM) nbelaevski: balunasj: got it thanks
(05:42:25 PM) ishaikovsky: yes need to review the options for that and implement in some way
(05:42:37 PM) nbelaevski: balunasj: message from exception looks like a good choice
(05:42:39 PM) ishaikovsky: from listener I mean
(05:42:58 PM) balunasj: ok good
(05:43:10 PM) balunasj: So lets move on - we can discuss that more at the end.
(05:43:58 PM) balunasj: How is browser support for html mode
(05:43:59 PM) balunasj: ?
(05:44:06 PM) balunasj: Any known issues there?
(05:44:38 PM) ishaikovsky: balunasj, flash had issues at most.. so that's why postponed and html should works fine
(05:44:52 PM) ishaikovsky: we just had issues with canceling uploads - so it also postponed even in html mode
(05:45:05 PM) nbelaevski: balunasj: we'll need to feed source of IFRAME to jsf.ajax.response function
(05:45:19 PM) alexsmirnov: and that's why I asked about flash.
(05:45:19 PM) nbelaevski: that's to update messages etc.
(05:48:13 PM) nbelaevski: potential problem is that status code & headers are not available in that case
(05:48:23 PM) balunasj: alexsmirnov: : please explain more
(05:48:42 PM) balunasj: Konstantin1: Are you comfortable with all of this? What are your concerns, suggestions, comments?
(05:50:21 PM) alexsmirnov: balunasj: I asked about flash because it has a most of issues.
(05:50:22 PM) ishaikovsky: alexsmirnov, it was still used in some of project which I know. Because the issues is not critical for all environmetns and we plan to deal with ones which possible to solve additionally. So it will be still more rich choise than html
(05:53:01 PM) Konstantin1: balunasj: Konstantin1: Almost yes, but I have 2 weeks for implementation only and it is possible that I will not finish some parts of work.
(05:53:12 PM) balunasj: for initial component I think that html is fine.
(05:53:14 PM) alexsmirnov: My biggest concern about 3.3 version was proper server-side implementation. Fileupload service should be separated from Servlet API, to easy switch betveen 2.5/3.0 or portlets.
(05:53:52 PM) balunasj: alexsmirnov: Are there some pointer, or suggestions that you can give Konstantin1 for this?
(05:54:04 PM) balunasj: alexsmirnov: Or perhaps you would be a good one to peer review?
(05:54:46 PM) nbelaevski: alexsmirnov: there are some methods not available in ExternalContext object that are necessary for upload component
(05:55:35 PM) alexsmirnov: alexsmirnov: The only suggestion is separate responsibility between classes. For 3.3, single call deep inside private method enforced me to copy and modify whole class...
(05:56:46 PM) nbelaevski: alexsmirnov: we've talked abot this with Konstantin1... servlets 3.0 will parse multipart request for us
(05:57:18 PM) nbelaevski: so we need to move parsing into a separate entity
(05:59:01 PM) nbelaevski: alexsmirnov: what can we do now for successful portlets integration? do we need the same code as was used in 3.x?
(05:59:32 PM) nbelaevski: alexsmirnov: I mean custom request parsing to be able to restore session correctly
(05:59:58 PM) nbelaevski: alexsmirnov: or is it just too early to tak about this at the moment?
(06:00:19 PM) balunasj: nbelaevski: I think it is good to make sure we don't break portlets from the start
(06:01:15 PM) alexsmirnov: I think it's to early. Just didvide servlet-specific part and content processor.
(06:01:36 PM) nbelaevski: balunasj: yes, but what's inside JSF2 portlets?
(06:01:50 PM) balunasj: nbelaevski: ?
(06:02:10 PM) nbelaevski: balunasj: my concern is that we don't know much about the internal structure of PB used for JSF2
(06:02:11 PM) balunasj: nbelaevski: don't know, but good to get alexsmirnov thoughts on it - I'm just saying I agree with you asking
(06:02:54 PM) nbelaevski: balunasj: I agree we shouldn't break - what I suggest is removal of the portlet-specific somewhat "hacky" code
(06:03:11 PM) nbelaevski: balunasj: so we fully rely on alexsmirnov there
(06:03:56 PM) nbelaevski: Konstantin1: please consider Alex's suggestions during coding
(06:04:30 PM) alexsmirnov: Nothing special, but portlets use different interfaces for Request/Response/Context, that do not inherit Servlet stuff, so all calls to specific method should be wrapped like ExternalContext.
(06:04:52 PM) balunasj: agree
(06:05:14 PM) balunasj: prabhaat: Are you ok being late for QE meeting?
(06:05:17 PM) alexsmirnov: That will be true for 2.5/3.0 - different wrappers that calls different methods.
(06:05:37 PM) balunasj: nbelaevski: alexsmirnov : lets move on - so we can get through - alexsmirnov & Konstantin1 please discuss as needed
(06:06:11 PM) prabhaat: balunasj, i am fine
(06:07:39 PM) balunasj: one Item I was wondering about was localization and custom button labels, etc...
(06:08:04 PM) balunasj: I know markup replacements are post M4, but at a minimum I think we need basic support
(06:10:00 PM) balunasj: how much will the initial impl support?
(06:10:33 PM) nbelaevski: Konstantin1: ^
(06:11:53 PM) Konstantin1: I will implement custom button labels through attributes.
(06:12:18 PM) balunasj: Konstantin1: ok that should be enough for initial impl