By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,481 Members | 3,078 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,481 IT Pros & Developers. It's quick & easy.

Solution design

P: n/a
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
Aug 30 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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=?=" <sd****@community.nospam>
| Subject: Solution design
| Date: Tue, 30 Aug 2005 11:32:11 -0700
| Lines: 58
| Message-ID: <1C**********************************@microsoft.co m>
| 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
|

Aug 31 '05 #2

P: n/a
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(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=?=" <sd****@community.nospam>
| Subject: Solution design
| Date: Tue, 30 Aug 2005 11:32:11 -0700
| Lines: 58
| Message-ID: <1C**********************************@microsoft.co m>
| 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
|

Aug 31 '05 #3

P: n/a
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: AcWuVj0xIHyW9PCzTweAKkFIwmfvCQ==
| X-WBNR-Posting-Host: 80.96.79.16
| From: "=?Utf-8?B?U29yaW4gRG9saGE=?=" <sd****@community.nospam>
| References: <1C**********************************@microsoft.co m>
<2o**************@TK2MSFTNGXA01.phx.gbl>
| Subject: RE: Solution design
| Date: Wed, 31 Aug 2005 11:03:06 -0700
| Lines: 172
| Message-ID: <5E**********************************@microsoft.co m>
| 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:49223
| X-Tomcat-NG: microsoft.public.dotnet.general
|
| 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(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=?=" <sd****@community.nospam>
| > | Subject: Solution design
| > | Date: Tue, 30 Aug 2005 11:32:11 -0700
| > | Lines: 58
| > | Message-ID: <1C**********************************@microsoft.co m>
| > | 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
| > |
| >
| >
|

Sep 1 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.