Gerardo Tasistro

Ranch Hand
+ Follow
since Feb 08, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gerardo Tasistro

Sold my Mac, but used to be Linux-Mac-Windows
7 years ago

prashanth nagaraj wrote:Thanks for the above replies. But also wanted some links on the examples as asked in question1. Request you to share the same

regards
Prashanth



I've been using XFire (now CXF) for some time to develop Swing to Web webservices and Swing to Swing webservices. As it supports its own embeddable webserver.

http://xfire.codehaus.org/
http://cxf.apache.org/
7 years ago

Daniel Gen Li wrote:@ Gerardo

My theory is that it shouldn't. Because what's the difference between reading two files when they're spearate and when they're together? aside from the fact that they don't appear to be separate filesystem?



I don't know. What I do know is there is no free lunch. So something is taking up that difference. It might be inefficient code or just processes needed to handle it properly. Before venturing into a development like that vs using a proven tool I'd test to see how significant that difference is. Are you loading this once every so often, then the impact isn't so great and you could have your application running much sooner. If on the other hand accessing these files could be a serious bottle neck(many reads per minute) then yes you'd have to optimize.

Did you do a series of reads and then average the times? If so how many tests did you do to come up with those values?
7 years ago

Kaustubh G Sharma wrote:I think java is more original than C# and secondly it is an open source which makes is more popular and famous.



I understand that C# and .NET is open source if you're into Microsoft's "what is your's is mine and what is mine is mine" open source philosophy.

Do remember though that Java (Sun's Java) was not opened sourced until recently, but did have open source versions based on it. Just like C# has Mono.
7 years ago

Daniel Gen Li wrote: how would I know I've reached the end of the contents of one file and direct the rest of the input somewhere else?



More important than that. After you've implemented that logic what will the performance be? And what if it's near the 300 ms mark?
7 years ago

Daniel Gen Li wrote:Not a bad idea at all. I've done zipping before, but how exactly could I load the extracted content into memory and read them as files? Perhaps load them into a byte buffer? because I'm making a game and I don't want people to just change the images so I want to place them all into a big file that's hard to decipher. lol



Zip utils have a way to handle zip entries and get a stream from that. You could work from there on.
7 years ago
You can use the jxl Java Excel API. Create a writable workbook to an output stream. Then use that output stream to channel the bytes into a post you can send to the receiving URL.

This example shows how to post using Java

http://samindaw.wordpress.com/2008/11/24/how-to-post-or-upload-a-file-to-a-url-or-servelet-using-java/

In this code:



The file is accessed as a File, but you can get the FilePart to load from a stream by using


And putting a ByteArrayPartSource as the source.

The ByteArrayPartSource in turn gets the byte[] from the output stream you used to store the excel file (ByteArrayOutputStream maybe?)
7 years ago
How about zipping them? and opening that in memory, parse and dispose. Not sure if those files are really big, but that could be an option since Java handles zips very well.
7 years ago
I'm under the impression that a non numeric value will throw an exception which would kick you out of your method altogether. Should take that into consideration as well.
7 years ago

Bill Karwin wrote:

Gerardo Tasistro wrote:A column is added that identifies the type and thus allows the foreign key to reference only one table and not many as is the case of one table per class.



Yes, that's the common way to employ polymorphic associations: add another column for the "type" of entity you're referencing. For example:

The problem is that you can't declare a foreign key constraint to enforce referential integrity for polymorphic associations.



Example of MySQL database structure generated by Hibernate for a polymorphic representation of discounts in an application. There are various types of discounts that are represented in one table. Thus allowing many classes to reside on the same table and be referenced.

Personally I'm no fan of one table per class approach due to the reasons you mention. But using polymorphism on one table is very viable without breaking constraints.


Bill Karwin wrote:
But I can think of at least one antipattern that Hibernate is guilty of: Polymorphic Associations. This encourages developers to design tables where a foreign key can reference any of several parent tables. But to achieve this, you have to forgo using a foreign key constraint to enforce the references. That should be a red flag right there that Polymorphic Associations violates database design principles.



You can still use only one table to store all classes. A column is added that identifies the type and thus allows the foreign key to reference only one table and not many as is the case of one table per class.

Gregg Bolinger wrote:I believe it's user preference. I learn better by writing the code. And in fact, I hate tools like JFormDesigner. Not because there is anything wrong with the tool, but because of what it does. Other folks love those kinds of tools. The best approach is to try it both ways and figure out what works best for you. You guys will continue to go back and forth until you realize this. There is no right way for everyone.



True, although there is no "best way" there is usually a "deadline". I enjoy writing a lot of the backing code like table, list and combo data models, fire events etc. But figuring out if 125 pts width will allow the text "Click to accept order" to fit my button is well needless in my opinion. That task is best handled visually by a tool like JFormDesigner.
7 years ago

Jim Hoglund wrote:
Gerardo : I guess that's just Campbell's point; that a beginning programmer can't read Java.
Keep in mind that a beginner does not know initialization code from today's rainfall, or a panel
layout from a shoe-shine kit.



That's exactly my point. It's already a steep learning curve as it is. Let him use a nice drag and drop tool to do all the grunt work and then let him dig into the code once he understands the issues I find more important like events, updates and threads in a GUI. Not to mention friendly user design.

Not using a tool like that leads to a loss of time manually adjusting settings then previewing then adjusting then previewing. I find no merit in a trial an error GUI design methodology just because. I can understand Prefered Size from the manual, but I can't really visualize 250,40 or 220,60. Although I usually support the learning of the underlying technology in this case I don't. I find it the equivalent of teaching architecture by looking at the data structure of a CAD file. There is so much involved in the GUI that is visual and represented by parameters that not using a tool like that is counter productive. We're not developing a class hierarchy than can visualized in one's mind. This has to be previewed, touched, looked at, changed, previewed again etc. In general I believe GUI design is more an exercise in aesthetics and usability than code writing.
7 years ago

Campbell Ritchie wrote:I see what you mean, but what happens when something goes wrong with a layout and you can't understand the code?

I think this thread would sit better on our GUIs forum, so I shall move it.



JFormDesigner keeps the initialization code very well contained and easy to read. If you read into it (and you can by just going into the init() method) you'll only see a series of variable initializations and layout configurations. It's the type of thing that's nice to go "oh wow that's how you do it, ok now back to work". When you add an action listener or method to respond to a button click or whatever all that happens is that said method stub is written for you with a nice // TODO ... . Once again something that's nice to see once and that's it. Since it isn't intrusive you can delete the original JFormDesigner file and work on from your java file.

If something goes wrong with the layout there's no way you can't understand the code unless you can't read Java.
7 years ago

Campbell Ritchie wrote:

Gerardo Tasistro wrote: . . . I'd recommend you get an evaluation version of JFormDesigner for the GUI development and download FatJar to bundle and deploy your application as a JAR file. With those two it's as simple as it gets.

But if you don't write code by hand, you will never understand what is going on. Avoid such automated tools like the plague until you are much more experienced.



I've never found any value in writing that type of code. He'll have plenty of time to write code to handle the actual things the buttons will be doing. I believe frustration levels rise to quickly with GUIs if everything is written by hand.
7 years ago