Thanks for your response Sorin,
Yes, using different rich client UI component for different target client
platform would be the most appropriate apporach currently. Also, I really
agree with you that MS should include .NET Framework by default, however,
since .NET is still a young guy, it need more time to make it stronger and
sophisticated. Anyway, I'm sure this is a trend.
Also, thank you again for choosing Microsoft and .NET :-)
Good luck!
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: AcWuVj0xIHyW9PC zTweAKkFIwmfvCQ ==
| X-WBNR-Posting-Host: 80.96.79.16
| From: "=?Utf-8?B?U29yaW4gRG9 saGE=?=" <sd****@communi ty.nospam>
| References: <1C************ *************** *******@microso ft.com>
<2o************ **@TK2MSFTNGXA0 1.phx.gbl>
| Subject: RE: Solution design
| Date: Wed, 31 Aug 2005 11:03:06 -0700
| Lines: 172
| Message-ID: <5E************ *************** *******@microso ft.com>
| 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.publi c.dotnet.genera l
| NNTP-Posting-Host: TK2MSFTNGXA03.p hx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.p hx.gbl!TK2MSFTN GXA03.phx.gbl
| Xref: TK2MSFTNGXA01.p hx.gbl microsoft.publi c.dotnet.genera l:49223
| X-Tomcat-NG: microsoft.publi c.dotnet.genera l
|
| Hello, and thank you for your valuable feedback.
|
| We got some other advice proposing to have two different UIs for
| Windows/IE-based and other platforms/other browsers: for Windows/IE we
could
| create a .NET WinForms control (since WinXP SP2 won't run ActiveX without
| user acceptance, and btw our developers are .NET developers anyway, so
| ActiveX would not be our best choice, and also Win XP SP2 doesn't have
any
| Java Virtual Machine by default), and for other platforms/other browsers
we
| would create a Java applet.
|
| I think that even if we would need to duplicate the functionality in a
..NET
| control and in a Java applet (which is not nice in a 21st century world
but
| hey, that's it when we have proprietary compteting tehnologies that are
not
| using the same standards...), that's the best approach to take to be able
to
| still use .NET wherever possible (i.e. on Windows machines), and not
break
| the second requirement for other platforms.
|
| However, running a .NET Windows Forms-based control on Windows XP (hosted
in
| IE) still requires that the user to install .NET Framework... A
suggestion to
| Microsoft (that I'm sure was done millions of times by other .NET
developers)
| would be to include .NET Framework by default, either in the latest SP or
as
| a mandatory download from Windows Update...
|
| --
| Sorin Dolha, DlhSoft
| MCAD, MCSD .NET
|
|
| "Steven Cheng[MSFT]" wrote:
|
| > 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(ch ecking 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+EU68J UvkjMw==
| > | X-WBNR-Posting-Host: 80.96.79.16
| > | From: "=?Utf-8?B?U29yaW4gRG9 saGE=?=" <sd****@communi ty.nospam>
| > | Subject: Solution design
| > | Date: Tue, 30 Aug 2005 11:32:11 -0700
| > | Lines: 58
| > | Message-ID: <1C************ *************** *******@microso ft.com>
| > | 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.publi c.dotnet.genera l
| > | NNTP-Posting-Host: TK2MSFTNGXA03.p hx.gbl 10.40.2.250
| > | Path: TK2MSFTNGXA01.p hx.gbl!TK2MSFTN GXA03.phx.gbl
| > | Xref: TK2MSFTNGXA01.p hx.gbl microsoft.publi c.dotnet.genera l:49141
| > | X-Tomcat-NG: microsoft.publi c.dotnet.genera l
| > |
| > | 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
| > | (AccessControlE xception, 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
| > |
| >
| >
|
