Just my thoughts on it: > - some IT departments do not allow JavaScript (Active Scripting) for > security reasons
Generally, the it security departments I have worked with (mostly banks and investment firms) allow javascript. What they don't allow are activex and sometimes applets (though I think that is misguided :)). > - my applications should work with the most common browsers (e. g. I > use > Firebird > with JavaScript turned off) and there are big differences between > several > browsers so > it's not THE browser model I use firebird as well but do not turn off javascript. I have seen no compelling case that javascript is a security risk (other than in outlook, but that is not a javascript issue it is a jscript/outlook security model issue). The standard javascript (ecmascript) is supported by mozilla, firebird, ie, konquerer, safari, and many others. It is not too bad to write cross platform javascript (though it can be painful at times :)). I have done it many times for both external and internal applications. You just have to be sure of your audience and make sure that the particular functions you are using are available and work appropriately on those browsers. In terms of not THE model, I respectfully disagree. HTML was never intended as an application view. It was intended and is still designed as a document markup format. Form submission is the only thing that has added any dynamic behavior to html and that is minimal. Javascript evolved to add presentation logic. Combined with the DOM standard and CSS it creates a compelling user interface toolkit (though, again the model can be very ugly). Confining yourself to html is like telling a thick client programmer he can't handle any ui events except for buttons of a specific type and that he can only do one action with that event. It is not possible to create a compelling user interface that way for anything except the simplest of applications (like a forum). Complex applications require more interaction with the user. Of course, this is just my opinion, but I think most UI guys (human factors and such) would agree. I understand that there are some platforms that are limited. However, if you don't actually have to support one of those platforms (like the qnx embedded browser or palm browsers) then I would highly recommend that you consider be a little more liberal in your use of the technologies that are available on your client. > - I don't want to mix user interfaces with application logic View logic and application logic are two different things. The logic as to how to wait for a long running task is clearly specific to the view as it would be very different in a swing application or on a cell phone. Don't underestimate the importance of the V in MVC. I don't advocate business logic in the user interface, but don't underestimate the importance of presentation logic to the success of an application. LES -----Original Message----- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Displaying a progress page Well the two are completely unrelated. J2EE has no user interface guidelines, it is not specific to browsers (it does define servlets which deal with http though, but that's as 'browsery' as it gets). So the question of how well javascript and j2ee mix is akin to asking how well buildings and leather chairs mix. You can use javascript if you want, it depends entirely on your target client. Is it an internal project where you can guarantee that everyone will be using IE? Do you care about supporting the 8% of people in the world who don't use IE? How about the three people who use Opera (hehe)? If you do care about all those people, then you're better off farming off the work to the server, and put in as few smarts as possible in your (d)html pages. On Thursday, June 26, 2003, at 03:13 PM, Lars Fischer wrote: >> Lars, just out of curiosity, what is driving the requirement for not >> supporting the complete browser model (no javascript)? > > These are some of the reasons: > > - some IT departments do not allow JavaScript (Active Scripting) for > security reasons > - my applications should work with the most common browsers (e. g. I > use > Firebird > with JavaScript turned off) and there are big differences between > several > browsers so > it's not THE browser model > - I don't want to mix user interfaces with application logic > > What do the others think about using JavaScript in J2EE applications ? > Is it 'allowed' ? > > Cheers > Lars > > >> >> -----Original Message----- >> From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 25, 2003 9:33 PM >> To: [EMAIL PROTECTED] >> Subject: Re: [OS-webwork] Displaying a progress page >> >> Les, >> >> You could do it using DHTML, but I'm fairly sure that's not how >> Expedia >> do >> it. It's a LOT more error prone to do that way :) >> >> FWIW we're investigating creating a generic 'long running task' system >> for >> JIRA - used for tasks like reindexing and importing/exporting data >> which >> take a long time. I think using a WW action this should be relatively >> easy >> to do. >> >> Mike >> >> On 26/6/03 10:13 AM, "[EMAIL PROTECTED]" >> ([EMAIL PROTECTED]) >> penned the words: >> >>> I haven't actually done this yet (but am planning to) -- however, >> can't >>> you take care of this behavior with dhtml?? It seems like you could >>> call a javascript function on submit that pulled a layer (actully >>> css-pos) to the top. That layer would say "in progress" with a >>> pretty >>> animated gif or have some neat little javascript progress bar. The >>> javascript would then submit the form. When it's done, the browser >>> updates. This seems like it will work and is likely better than the >>> server side solutions. Is there something I'm missing?? BTW, I >>> think >>> this is how expedia used to do it. >>> >>> LES >>> >>> -----Original Message----- >>> From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, June 25, 2003 7:01 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: [OS-webwork] Displaying a progress page >>> >>> Uhm, well why not just make your task runnable and run it in a new >>> thread? >>> :) Or you could use a util.Timer. >>> >>> Another (nicest IMHO) alternative is to make it a scheduled task and >> use >>> something like Quartz to kick it off. >>> >>> M >>> >>> On 26/6/03 6:05 AM, "Jason Carreira" ([EMAIL PROTECTED]) >> penned >>> the >>> words: >>> >>>> Well, for us we queue a JMS message. I'm not sure of another way to >>>> start an asynch process in the J2EE spec.... >>>> >>>>> -----Original Message----- >>>>> From: Lars Fischer [mailto:[EMAIL PROTECTED] >>>>> Sent: Wednesday, June 25, 2003 3:42 PM >>>>> To: [EMAIL PROTECTED] >>>>> Subject: RE: [OS-webwork] Displaying a progress page >>>>> >>>>> >>>>> Jason, >>>>> >>>>> thanks for the reply ! >>>>> >>>>> Any hint how you start the asynchronous process ? >>>>> >>>>> Lars >>>>> >>>>>> If you can start it up as an asynchronous process, you can use the >>>>>> trick of having a progress page which checks some state, such as a >>>>>> database or something in the session, and shows the progress bar >>>>>> or >>>>>> just a "processing..." and have it refresh itself using a >>>>> meta-refresh >>>>>> if things aren't done... If the process is done you can >>>>> forward to a >>>>>> final status page. >>>>>> >>>>>> We've used this technique pretty successfully. >>>>>> >>>>>> Jason >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>>>>> Sent: Wednesday, June 25, 2003 8:31 AM >>>>>>> To: [EMAIL PROTECTED] >>>>>>> Subject: [OS-webwork] Displaying a progress page >>>>>>> >>>>>>> >>>>>>> Does anyone have a good idea how to display a temporary >>>>>>> progress page in WW 1.x ? >>>>>>> >>>>>>> I have a form where users can define paremeters for an import >>>>>>> of data into the local database. After submitting the page >>>>>>> the import method is started. This process may take a while >>>>>>> so I want to show a general progress page saying that >>>>>>> the import is running. After finishing the import I want to >>>>>>> return to the original page where users can start an import. >>>>>>> >>>>>>> Does anyone know how to do this ? The problem seems to be >>>>>>> that WW is displaying the result-view AFTER the whole action >>>>>>> has finished. >>>>>>> >>>>>>> Thanks in advance >>>>>>> >>>>>>> Lars >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------- >>>>>>> This SF.Net email is sponsored by: INetU >>>>>>> Attention Web Developers & Consultants: Become An INetU >>>>>>> Hosting Partner. Refer Dedicated Servers. We Manage Them. You >>>>>>> Get 10% Monthly Commission! INetU Dedicated Managed Hosting >>>>>>> http://www.inetu.net/partner/index.php >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Opensymphony-webwork mailing list >>>>>>> [EMAIL PROTECTED] >>>>>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> This SF.Net email is sponsored by: INetU >>>>>> Attention Web Developers & Consultants: Become An INetU Hosting >>>>>> Partner. Refer Dedicated Servers. We Manage Them. You Get >>>>> 10% Monthly >>>>>> Commission! INetU Dedicated Managed Hosting >>>>>> http://www.inetu.net/partner/index.php >>>>>> _______________________________________________ >>>>>> Opensymphony-webwork mailing list >>>>>> [EMAIL PROTECTED] >>>>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> This SF.Net email is sponsored by: INetU >>>>> Attention Web Developers & Consultants: Become An INetU >>>>> Hosting Partner. Refer Dedicated Servers. We Manage Them. You >>>>> Get 10% Monthly Commission! INetU Dedicated Managed Hosting >>>>> http://www.inetu.net/partner/index.php >>>>> >>>>> _______________________________________________ >>>>> Opensymphony-webwork mailing list >>>>> [EMAIL PROTECTED] >>>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: INetU >>>> Attention Web Developers & Consultants: Become An INetU Hosting >>> Partner. >>>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >>> Commission! >>>> INetU Dedicated Managed Hosting >> http://www.inetu.net/partner/index.php >>>> _______________________________________________ >>>> Opensymphony-webwork mailing list >>>> [EMAIL PROTECTED] >>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: INetU >>> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >>> INetU Dedicated Managed Hosting >>> http://www.inetu.net/partner/index.php >>> _______________________________________________ >>> Opensymphony-webwork mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: INetU >>> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >>> INetU Dedicated Managed Hosting >>> http://www.inetu.net/partner/index.php >>> _______________________________________________ >>> Opensymphony-webwork mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: INetU >> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >> _______________________________________________ >> Opensymphony-webwork mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: INetU >> Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >> _______________________________________________ >> Opensymphony-webwork mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting > Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly > Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
