Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > tools for programming applets

Reply
Thread Tools

tools for programming applets

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-24-2011
In message <3c7d8f50-df8e-4198-
http://www.velocityreviews.com/forums/(E-Mail Removed)>, horos22 wrote:

>In message <irc9es$58p$(E-Mail Removed)>, Lawrence D'Oliveiro wrote:
>
>> In message
>> <(E-Mail Removed)>,
>> horos22 wrote:
>>
>>> You've GOT to be kidding me.

>>
>> Microsoft?? No, YOU’RE the one kidding me.

>
> 95% of the people running your code are running microsoft browsers and
> microsoft java implementations. Do you *not* test your applet against
> all of these, especially for gui presentation?


I don’t bother with applets, so your question is moot.

> Rsync is useless if you aren't running your development client on the
> same os as the server ...


But why deliberately use a platform that makes development more difficult?
Wouldn’t you rather save yourself some work?

And what happened to the much-trumpeted Java claim of “write once, run
everywhere”?

> ... or if you are using licensed code anywhere.


All the code I use is “licensed”. Only most of it happens to be Free
Software, which means the licence allows free copying.
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-24-2011
In message <irdrer$dd1$(E-Mail Removed)>, Joshua Cranmer wrote:

> That you completely cut off all context of where I explained this.


*Sigh* I get this crap all the time from the clueless newbies. Let me
explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give some
context for what I said, nothing more.

Rest assured if I reply to you I did read what you said, whether I quoted it
or not. If I was ignoring what you said, I wouldn’t even bother replying to
you.
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      05-24-2011
On 11-05-24 05:15 AM, Lawrence D'Oliveiro wrote:
> In message <irdrer$dd1$(E-Mail Removed)>, Joshua Cranmer wrote:
>
>> That you completely cut off all context of where I explained this.

>
> *Sigh* I get this crap all the time from the clueless newbies. Let me
> explain to you something about USENET: my postings are to record what I
> said, not what you said. If I quote any part of you said, it is to give some
> context for what I said, nothing more.

[ SNIP ]

That's the point of quoting, yes, to provide context for what you're
saying. Joshua is saying that you didn't quote enough to provide
context. You surely did not.

In case you didn't know this about English (this is not a Usenet thing),
the point of quoting as we use it here is typically to call attention to
another person's position so you can agree or disagree with it, and
follow up on what they said. Brevity is good, but you're supposed to
keep enough quoted material to actually express the intent.

Here's another way of looking at it: assume that readers only have the
one post to examine. The sense of what you quote should independently
accurately reflect what the original author is saying. "How about
Swing?" fails miserably on that count.

AHS
 
Reply With Quote
 
Silvio
Guest
Posts: n/a
 
      05-24-2011
On 05/20/2011 11:43 PM, horos22 wrote:
> All,
>
> I was looking to do some quick java development of applets. Here's my
> situation:
>
> 1. I have a static server (ie: that I cannot touch) which serves my
> client data (and applets).
> 2. a bare-bones client programming setup (vim and java compiler)
>
> What I was hoping to do, therefore, is hijack the applets that are
> coming from the server, and replace them with my own, compiled ones,
> and hook the browser in such a way that when the applet is asked for,
> my applet fires instead (hopefully in debugging mode) using the data from the server as input.
>
> Surely this is a common enough situation that there are standard
> firefox plugins to do this..
>
> Or is it? In any case any, help on this would be most appreciated.
>
> Thanks much,
>
> Ed


Sounds like a strange request but whatever.

Why don't you run a local proxy (apache comes to mind but even
Tomcat/Jetty would do) for the site with some special rules to serve the
applet from where you have it and to replace the sites DNS with its
actual IP. Then map the DNS to localhost in /etc/hosts or
/Windows/System32/drivers/etc/hosts. Has worked fine with almost any
site for me in the past.

Silvio
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-24-2011
On 05/24/2011 04:15 AM, Lawrence D'Oliveiro wrote:
> In message<irdrer$dd1$(E-Mail Removed)>, Joshua Cranmer wrote:
>
>> That you completely cut off all context of where I explained this.

>
> *Sigh* I get this crap all the time from the clueless newbies. Let me


Wow. You really have lost it this time, Lawrence. Please show more courtesy.

> explain to you something about USENET: my postings are to record what I
> said, not what you said. If I quote any part of you said, it is to give some
> context for what I said, nothing more.
>
> Rest assured if I reply to you I did read what you said, whether I quoted it
> or not. If I was ignoring what you said, I wouldn’t even bother replying to
> you.


Arrogant much, Lawrence?

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Alessio Stalla
Guest
Posts: n/a
 
      05-24-2011
On 23 Mag, 18:17, Lew <(E-Mail Removed)> wrote:
> On 05/23/2011 11:38 AM, horos22 wrote:
>
>
>
>
>
>
>
>
>
> > On May 22, 6:15 am, markspace<-@.> *wrote:
> >> On 5/22/2011 5:53 AM, Lew wrote:

>
> >>> I just cannot buy that this is the real reason.

>
> >> I think it is. *There are a couple of tools that let you replace CSSon
> >> an HTML page. *The page design folks use them to mock up new pages or
> >> fix errors before propagating back to the server.

>
> >> He's just assuming that applets are like HTML. *It's a rookie maneuver,
> >> nothing more.

>
> > Mark,

>
> > I think you get my drift, but I'd raise you one further. Albeit
> > insecure, there *should* be a way to replace applets like you would
> > replace CSS. It would make things a helluva lot simpler in
> > development. This shouldn't be turned on by default, but it should be
> > there.

>
> > BTW there are tons of things that sense for development purposes, that
> > make no sense for production deployment. Why this is any different is
> > beyond me.

>
> No, there shouldn't. *How would an applet call back to the correct hostif you
> have it mounted from localhost? *Applets are only allowed to get resources
> from their own server.
>
> Your fundamental error in thought is that applets are not at all like CSS..
> CSS is a brower-interpreted, client-side phenomenon. *Applets are a JVM-run,
> server-side phenomenon that just happen to run out of a browser. *Big difference.
>
> Now stop whining about your pathetic thoughts of how things "should" be and
> deal with reality as it actually is, or find a profession that doesn't require
> rational reasoning. *Or write your own technology to compete with applets.
> Just stop whining over and over and over and over and over and over abouthow
> you think in your infinite wisdom and genius that things should be different
> than they actually are. *You'll never get the job done that way.
>
> It's pathetic.


Guys, sorry, but you're completely nuts. Once more I understand why
Java has got the reputation of being bloated. We should remember that
Java is not necessarily targeted only at big corporations and multi-
million projects! The OP asked how to do a certain thing. Telling him
how a Fortune 500 company should do it is not going to help him.
Besides, I don't think even a Fortune 500 company should clone the
whole production server just to test one *applet*!

To answer directly to the OP question: there are a few ways you can
test your own modified applet against your production server.
1) you can run the applet as a standalone application: either coding
(e.g. a JFrame to contain it) or using something like Oracle's
AppletViewer. This is feasible only if the applet does not interact
with the surrounding page.
2) signed applets can bypass security restrictions. So you can run
your (signed) applet on a page loaded from localhost and still connect
to the remote server. Or, if you *really* need the applet to run on
the production page itself, you can probably use something like
Greasemonkey to patch (your client-local version of) the page to
include the applet. Needless to say, the latter option could be a
violation of the site's terms of use, and it's unnecessarily
cumbersome, so avoid it unless it's the only option left.

To everyone else: applets *are* client-side. Really, I can't imagine
why you think otherwise. Yes, they are downloaded from a server; so
what? Most software nowadays is downloaded from somewhere the first
time. But they run on the client, and only talk to the server via
remoting, RPC, SOAP or whatever else. Or do you really believe that
e.g. Flash is server-side?

Sorry for being a little aggressive, but I can't really understand why
there are ~50 posts sponsoring the big costly solution and ~0
suggesting the practical one.

Cheers,
Alessio
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-24-2011
Alessio Stalla wrote:
> Guys, sorry, but you're completely nuts. Once more I understand why
> Java has got the reputation of being bloated. We should remember that
> Java is not necessarily targeted only at big corporations and multi-
> million projects! The OP asked how to do a certain thing. Telling him
> how a Fortune 500 company should do it is not going to help him.
> Besides, I don't think even a Fortune 500 company should clone the
> whole production server just to test one *applet*!


Huh? "Fortune 500 company"? Where's your head, dude? It takes twenty
minutes and about 50c worth of disk space to clone the server. I do it all
the time at home in my practice work. That's one individual person, not even
a company, let alone a Fortune 500 company. Get real.

> To answer directly to the OP question: there are a few ways you can
> test your own modified applet against your production server.
> 1) you can run the applet as a standalone application: either coding
> (e.g. a JFrame to contain it) or using something like Oracle's
> AppletViewer. This is feasible only if the applet does not interact
> with the surrounding page.


Suggested upthread, but only partially useful as not all applet behaviors can
be tested this way.

> 2) signed applets can bypass security restrictions. So you can run


On the localhost, yes. It doesn't change the restrictions on which server they
can communicate with.

The tutorial explains this:

"An applet can communicate with server applications that run on the same host
as the applet."
<http://download.oracle.com/javase/tutorial/deployment/applet/server.html>

"Signed applets operate outside the security sandbox and have extensive
capabilities to access the client."
<http://download.oracle.com/javase/tutorial/deployment/applet/security.html>

> your (signed) applet on a page loaded from localhost and still connect
> to the remote server. Or, if you *really* need the applet to run on
> the production page itself, you can probably use something like
> Greasemonkey to patch (your client-local version of) the page to
> include the applet. Needless to say, the latter option could be a
> violation of the site's terms of use, and it's unnecessarily
> cumbersome, so avoid it unless it's the only option left.


The applet still has to communicate with the server from which is was loaded,
and no other.

> To everyone else: applets *are* client-side. Really, I can't imagine
> why you think otherwise. Yes, they are downloaded from a server; so


They are a special component that talks to a special application server, not a
client of the web server, as explained upthread.

> what? Most software nowadays is downloaded from somewhere the first
> time. But they run on the client, and only talk to the server via
> remoting, RPC, SOAP or whatever else. Or do you really believe that
> e.g. Flash is server-side?
>
> Sorry for being a little aggressive, but I can't really understand why
> there are ~50 posts sponsoring the big costly solution and ~0
> suggesting the practical one.


Because the solution is neither big, nor costly, and is, in fact, much LESS
expensive than testing on the production box. Risk has a cost, duh. Talk
about how inexpensive development and testing on the production server are
when you've brought it to its knees and the client is out of business for a
day while you try to undo the damage done by your insane irresponsibility.

Why do you guys latch on to this "big, expensive" rhetoric as if there were
any merit to it whatsoever? It's been pointed out before that that is false
reasoning. What is this, repeat the Big Lie (without evidence or supporting
logic) long enough and this intelligent group of software engineers are
somehow suddenly going to believe it?

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      05-24-2011
Mon, 23 May 2011 14:17:43 +1200, /Lawrence D'Oliveiro/:
> In message <ircbic$g3e$(E-Mail Removed)>, Joshua Cranmer wrote:
>
>> Now, let me end by pointing out that Java has been able to do all of
>> these things for over a decade.

>
> And yet nobody was ever able to do them. Where is the Java equivalent of
> jQuery, for example?


Which languages have a jQuery equivalent?

jQuery is rather fat library for the things it does. It does a lot
of things wrong, does not teach developers of learning the standard
DOM, in turn teaches developers not doing things right, and finally
adds quite a bit amount of crap going over the network which
developers and users end up not really using.

If you go to comp.lang.javascript you'll get quite negative opinion
on the usefulness of the jQuery library from the experts.

--
Stanimir
 
Reply With Quote
 
Alessio Stalla
Guest
Posts: n/a
 
      05-24-2011
On 24 Mag, 14:38, Lew <(E-Mail Removed)> wrote:
> Alessio Stalla wrote:
> > Guys, sorry, but you're completely nuts. Once more I understand why
> > Java has got the reputation of being bloated. We should remember that
> > Java is not necessarily targeted only at big corporations and multi-
> > million projects! The OP asked how to do a certain thing. Telling him
> > how a Fortune 500 company should do it is not going to help him.
> > Besides, I don't think even a Fortune 500 company should clone the
> > whole production server just to test one *applet*!

>
> Huh? *"Fortune 500 company"? *Where's your head, dude? *It takes twenty
> minutes and about 50c worth of disk space to clone the server. *I do itall
> the time at home in my practice work. *That's one individual person, not even
> a company, let alone a Fortune 500 company. *Get real.


Well, of course I was exaggerating, but still, how long it takes
depends on the server, doesn't it? What if in the OP's case the server
is backed by a 1TB database? Even copying just the bits he needs for
the test requires identifying those bits, and writing SQL scripts to
selectively copy them. In general, it requires detailed knowledge
about the server, and - I repeat - that's overkill just to test one
applet.

> > To answer directly to the OP question: there are a few ways you can
> > test your own modified applet against your production server.
> > 1) you can run the applet as a standalone application: either coding
> > (e.g. a JFrame to contain it) or using something like Oracle's
> > AppletViewer. This is feasible only if the applet does not interact
> > with the surrounding page.

>
> Suggested upthread, but only partially useful as not all applet behaviorscan
> be tested this way.


True. The OP will decide if the behaviors he can test this way are
those that interest him or not.

> > 2) signed applets can bypass security restrictions. So you can run

>
> On the localhost, yes. It doesn't change the restrictions on which serverthey
> can communicate with.
>
> The tutorial explains this:
>
> "An applet can communicate with server applications that run on the same host
> as the applet."
> <http://download.oracle.com/javase/tutorial/deployment/applet/server.html>
>
> "Signed applets operate outside the security sandbox and have extensive
> capabilities to access the client."
> <http://download.oracle.com/javase/tutorial/deployment/applet/security...>


Not true. You can explicitly grant AllPermissions to your applet,
thereby effectively disabling security altogether. Granted, it's a
stupid thing to do most of the time, but not in the OP's case. See,
e.g., <http://stackoverflow.com/questions/6...igned-applets-
connect-with-a-different-host-from-which-they-originate>.

> > your (signed) applet on a page loaded from localhost and still connect
> > to the remote server. Or, if you *really* need the applet to run on
> > the production page itself, you can probably use something like
> > Greasemonkey to patch (your client-local version of) the page to
> > include the applet. Needless to say, the latter option could be a
> > violation of the site's terms of use, and it's unnecessarily
> > cumbersome, so avoid it unless it's the only option left.

>
> The applet still has to communicate with the server from which is was loaded,
> and no other.
>
> > To everyone else: applets *are* client-side. Really, I can't imagine
> > why you think otherwise. Yes, they are downloaded from a server; so

>
> They are a special component that talks to a special application server, not a
> client of the web server, as explained upthread.


A special component *that runs on the client* and that *can* talk to a
special application server, but also to a HTTP server, or to no server
at all. How is this different from Flash? Or even JavaScript, except
the latter does not require a plugin?

>
> > what? Most software nowadays is downloaded from somewhere the first
> > time. But they run on the client, and only talk to the server via
> > remoting, RPC, SOAP or whatever else. Or do you really believe that
> > e.g. Flash is server-side?

>
> > Sorry for being a little aggressive, but I can't really understand why
> > there are ~50 posts sponsoring the big costly solution and ~0
> > suggesting the practical one.

>
> Because the solution is neither big, nor costly, and is, in fact, much LESS
> expensive than testing on the production box.


How can you possibly know!? The OP said nothing about the production
box! It might as well be a cluster of ten high-end machines, as far as
we know!

>*Risk has a cost, duh. *Talk
> about how inexpensive development and testing on the production server are
> when you've brought it to its knees and the client is out of business fora
> day while you try to undo the damage done by your insane irresponsibility..


You're grossly exaggerating. I don't get why you insist on doing it.

> Why do you guys latch on to this "big, expensive" rhetoric as if there were
> any merit to it whatsoever? *It's been pointed out before that that is false
> reasoning. *What is this, repeat the Big Lie (without evidence or supporting
> logic) long enough and this intelligent group of software engineers are
> somehow suddenly going to believe it?


From my POV, these lines apply more to you and markspace than to the
OP and me.

Peace,
Alessio
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-25-2011
In message
<(E-Mail Removed)>, Alessio
Stalla wrote:

> What if in the OP's case the server is backed by a 1TB database?


1TB drives can be had for pocket change these days.

What was the problem, again?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: tools for programming applets horos22 Java 2 05-23-2011 11:01 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui C++ 0 04-27-2009 12:51 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui Python 0 04-27-2009 12:46 PM
Article : Security Tools Part -- 2 (.Net FrameWork Tools Series) Namratha Shah \(Nasha\) ASP .Net 0 11-23-2004 04:01 PM



Advertisments