Looking For Direction
in [Java Help]
|
Prev: Sending SMS
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, start date 21st June, 2.ITIM-TAM Analyst in Austin, TX.
From: Arved Sandstrom on 10 Jun 2010 19:42 Joshua Cranmer wrote: > On 06/10/2010 06:42 PM, Arved Sandstrom wrote: >>> Almost everyone will not have Windows. And almost everyone does not have >>> Windows. > > I'm pretty sure most mobile phones lack Windows. > Well, OK, fair enough. But I was thinking of devices that would have screens large enough to be useful for the kind of application being discussed, and the OS's that would be running the apps that populate those displays. "Desktop" or server OS's, IOW...not smartphone or tablet OS's. AHS -- It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. -- Nathaniel Borenstein
From: JC on 10 Jun 2010 22:57 > > What about the Vector class is interesting? > It's not that I find it interesting. It just works well for my purposes. For example, I have a "ResultRec" object that basically holds all the data from one record in the lab_results table. But one result record can have one or more result codes. So in my ResultRec object I have a Vector of lab_result_codes. Keep in mind I am the only person that has ever done any development on this system. Most of what I've done is a result of my own ideas (i.e. not much real formal training beyond college). In addition to that, they always want stuff done now ... immediately. So I've done a lot of semi-ugly things in the code; stuff that is sometimes contrary to what I've been taught ... :) -JC
From: JC on 10 Jun 2010 23:04 > > He may not be a DBA, but if has been writing SQL statements for the > app then he would know some of Oracles ways of doing things. > > Arne > I dream in SQL ... :) Even though I'm not a DBA, from time to time I have to do DBA oriented things. Since the system is not highly sophisticated this is never been too much of a problem. I'd say the most important thing I do along these lines is monitor the size of the tablespaces, how fast they are growing. Maybe a few times in the beginning I had to resize them; but I pretty much have a handle on it now. By law we only have to keep ten years worth of data. So every night I have a routine that deletes anything older than ten years (actually I go ten years and six months just to be safe). We started doing this (deleting old data) about a year or so ago. It helps keep the size of the database more stable (except whenever we get new contracts that are big clients which has happened twice ... once with the state of Alabama and more recently with West Virginia). Anyway, what I worry about is with the deleting and adding of data on a consistent basis whether something funky will happen some day like file corruption, fragmentation, etc. Things which I really don't know how to fix of have any experience with. -JC
From: JC on 10 Jun 2010 23:11 "Wanja Gayk" <brixomatic(a)yahoo.com> wrote in message news:op.vd3xangmy5e8ok(a)laptopwanja... Am 09.06.2010, 23:19 Uhr, schrieb JC <jjcardella(a)hotmail.com>: >> Off the top of my head, I am thinking of a Unix based version of Oracle >> for the DBMS. >Why? I guess because I have more experience with Unix and feel more comfortable with it. I've done a lot of Unix shell scripting although that was some years ago. >> For the user interface I am thinking of something that is >> integrated with a web browser. And of course some sort of interface >> between the two. >Why would you want that? A proper Swing GUI gives you more freedom than >any browser based technology. If deployment is no problem, and with >Webstart it isn't, there is no point in using a web based GUI for a system >which is not intended to run on the web - and with webstart even that >would be no problem. Right now clients (physicians, clinics, hospitals) send test samples along with a "requisition" which includes demographics, patient history, insurance info, etc. We have a data entry clerk that enters this into the system. I was thinking somewhere down the line if we had a web-based interface the clients could fill in that info electronically instead of writing it on a form and sending it to the lab where someone has to enter it. I think it would save money but I reckon someone would lose their job. -JC
From: Alessio Stalla on 11 Jun 2010 05:18
On Jun 11, 12:00 am, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 10-06-2010 11:03, Alessio Stalla wrote: > > > > > On Jun 9, 11:19 pm, "JC"<jjcarde...(a)hotmail.com> wrote: > >> For the user interface I am thinking of something that is > >> integrated with a web browser. > > > In addition to what everyone else said, I'd like to concentrate on > > this point. Are you really sure you need a web-based interface (i.e., > > do you really need to expose your application to potentially anyone > > anywhere), or are you considering it just because it's today's trend > > to build web applications? > > > In my experience (2+ years in JSF + some minor projects with Struts) > > web applications often face an additional layer of complexity than > > client-server applications, and are generally limited in functionality > > (by the browser and by the stateless nature of the HTTP protocol). > > > I think JSF especially is a very bad choice. I used the ICEFaces > > implementation, which adds its own host of problems, but JSF in > > general is terribly complex, and has a fundamentally bad design. > > Imagine someone proposed to you, for a client-server application: > > "hey, let's do this cool thing, let's keep *all* the GUI state on the > > server and ask for it *each and every time* the user interacts with > > the GUI"... you would say that's crazy, wouldn't you? Yet it's > > precisely what JSF does > > That is what all non-AJAXified web apps does. No. Most web frameworks reconstruct the page for every request, and, if applications are designed with a bit of cleverness, they only keep in session the minimum amount of state necessary to reconstruct the view. They don't keep in memory all the labels, all the CSS classes, all the component ids, ... like JSF does. > You can do AJAX with JSF if you want to. You can, of course. I have only used ICEFaces which does a terrible job at it, but maybe other AJAX JSF implementations are saner. > > > (and ICEFaces exacerbates the problem by > > forcing everything to be AJAX, even stuff that could be client-side > > only, like help tooltips). > > AJAX is by definition running client side. No, AJAX by definition is asking stuff to the server asynchronously. Why showing a help tooltip, or opening or closing a date selection popup, should ask the server for data? > > Then, there's the complex and strict life > > cycle, > > Just learn it. I did learn it. I also endlessly fought against it when it proved to be too inflexible. How demented it is that to *empty* a form I have to generate an "immediate" event and cycle through the tree of components in the view to empty them *by hand*? And that I have to jump through hoops because "emptying" a component can mean different things for different components? > > the macroscopic mistakes in the class hierarchy, > > If we would ditch all API's where someone did not like something, > then there would not be many API's available. Replicating isDisabled on all components rather than declaring it once on UIComponent and inheriting it is an objective mistake. And it's not just isDisabled, other methods are like that. You have to resort to reflection to do even simple things uniformly for all components. State saving is also cumbersome and error-prone, but I can live with that. Creating components programmatically is unnecessarily hard. Parsing dates by default forcing GMT timezone is wrong. Etc. etc. Alessio |