RE: Solution design
- From: stcheng@xxxxxxxxxxxxxxxxxxxx (Steven Cheng[MSFT])
- Date: Wed, 31 Aug 2005 04:00:42 GMT
Hi Sorin,
Welcome to MSDN newsgroup.
Based on your description, I think it would be a bit hard to meet all the
requirements you mentioned. Here are some of my suggestions regarding on
the problems:
1. For this clientside file checking and uploading function, I think we
could not but use rich client components (eg, .net winform control, activex
control, java applet.....). Pure clientside script won't have the ability
to manipulate clientside file or do any web accessing operation.
2.For different target client platform( windows IE/non-IE, non-windows
non-IE), we may consider provide different UI for them. For windows IE
client, of course the best choice is using .NET UserControl. For other
ones, I think you may still consider applet. Also, from a quick search,
there seems has some existing 3rd party applet rich client file uploaders:
http://sourceforge.net/projects/jupload
You can refer to some to see whether they're working in your scenario.
Anyway, if your design is restricted to manipulating(checking size) the
file on the clientside, using those Rich client components are unavoidable.
Please feel free to post here if you have any other ideas or concerns.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
| Thread-Topic: Solution design
| thread-index: AcWtkSLp/5jhTg5jSH+EU68JUvkjMw==
| X-WBNR-Posting-Host: 80.96.79.16
| From: "=?Utf-8?B?U29yaW4gRG9saGE=?=" <sdolha@xxxxxxxxxxxxxxxx>
| Subject: Solution design
| Date: Tue, 30 Aug 2005 11:32:11 -0700
| Lines: 58
| Message-ID: <1C25102B-6AD3-49E5-9EE8-CDA274297452@xxxxxxxxxxxxx>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.general
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.general:49141
| X-Tomcat-NG: microsoft.public.dotnet.general
|
| Hello,
|
| We intend to create an ASP.NET-based Web application (hosted on Internet
| Information Services, or IIS) and one feature of the application needs to
| allow the end user to upload photos to the server.
|
| However, our customer requests that both of these two objectives to be
| supported by the design of the solution:
|
| 1. The photos should be encoded as JPG, and resized (if larger than a
| maximum adminisible width/height) on the client side, before the actual
| upload.
|
| 2. The upload (and the whole application) should work on multiple
browsers
| supported on multiple platforms, running with the default user security
| settings (explicit request includes, but are not limited to: Internet
| Explorer on Windows and Macintosh, Mozilla Firefox on Windows and other
OSes).
|
| The first request would trigger for creating: a .NET-based user control
| hosted in Internet Explorer, or a ActiveX component hosted also on the
web
| site, or a Java applet. Personally, if it weren't for the second request,
I'd
| choose the first choice (.NET-based user control as it is the most
flexible
| and uses the advantages of the .NET technologies even on client side).
|
| However, the second request would trigger for Java instead, as .NET (or
| COM/ActiveX technologies are not running on the requested
platforms/browsers).
|
| For testing purposes, we tried to create a Java applet that was trying to
| allow a user to select an image using a FileDialog window, and then
trying to
| open the image, convert it as required and then upload the resulting
bytes
| back to the server. This seemed to be OK, but unlike .NET, Java applets
do
| not allow implicitly to open a file stream on the client host even if it
was
| selected by a user n a FileDialog window (I know .NET default security
| permissions would allow that, because I already used it in another
| application). In this case, we tried to sign the applet using the steps
| presented by Sun on their Web site due to no avail: an exception
| (AccessControlException, with access denying on socket creation for
getting
| the image file from the local client host) was generated even if the jar
was
| signed (with a test certificate, tough - but even in this case, the
browser
| should have asked the end user whether or not she trusts the applet and
allow
| it to run if accepted - at least that's what Sun documentation sais...)
|
| Now, because we feel that a java applet is not an as good idea as we
first
| thought due to the default security permissions higher than actually
| necessary (i.e. reading a file should be allowed if the file was selected
by
| the user in a FileDialog...), we are back to the design table, and
looking
| for some advice from anyone else, if available: what do you think? What
is
| the best approach we could do to meet both of the customer requirements
and
| still create a nice solution (such as a .NET-only one)? :)
|
| PS: Maybe someone knows where to find a JPEG encoder written entirely in
| JScript running on the client with a HTML FileUpload control as the
source
| for the file, before actually uploading it, or is it something too
difficult
| to write entirely in JScript?
|
| --
| Sorin Dolha, DlhSoft
| MCAD, MCSD .NET
|
.
- References:
- Solution design
- From: Sorin Dolha
- Solution design
- Prev by Date: Re: Namespaces hierarchically in a tree control
- Next by Date: Re: difference between desktop application and intranet application
- Previous by thread: Solution design
- Next by thread: Namespaces hierarchically in a tree control
- Index(es):
Relevant Pages
|
