🚀 go-pugleaf

W dniu 2012-12-19 23:50, Jadalbert napisał(a):
> w pierwszym wierszu są same Stringi
> w kolejnych wierszach i poszczególnych (stałych) kolumnach są Stringi, a w innych kolumnach double. Coś jak to:
> nazwa; x; y; z; typ;
> kula; 23.0; 34.1; 45.3; 1
> walec; 12.7; 23.3; 45.3; 2

> I teraz pytanie. Do czego to ładować skoro raz mam String, a raz double? Do jakiego obiektu, kontenera, listy, map?

Przetwarzać liniami i wtedy po wczytaniu linię dzielić na całostki StringTokenizerem
(http://docs.oracle.com/javase/7/docs/api/java/util/StringTokenizer.html) lub przetwarzać
po kolei i wtedy dzielić na całostki StreamTokenizerem
(http://docs.oracle.com/javase/7/docs/api/java/io/StreamTokenizer.html) albo Scannerem
(http://docs.oracle.com/javase/7/docs/api/java/util/Scanner.html).

Napisać klasę, coś jak:

class Bryła {
   private String nazwa;
   private double x,y,z;
   private int typ; // albo jakiś enum
   //...
}

i dane z linii pliku ładować do obiektów tej klasy. A kolekcja obiektów tej klasy taka,
jaka wynika z dalszych celów zabawy z tymi bryłami.

-- 
TrzyLinie

W dniu 2012-12-20 07:36, TrzyLinie pisze:
> W dniu 2012-12-19 23:50, Jadalbert napisał(a):
>> w pierwszym wierszu są same Stringi
>> w kolejnych wierszach i poszczególnych (stałych)
>> kolumnach są Stringi, a w innych kolumnach
>> double. Coś jak to:
>> nazwa; x; y; z; typ;
>> kula; 23.0; 34.1; 45.3; 1
>> walec; 12.7; 23.3; 45.3; 2
>
>> I teraz pytanie. Do czego to ładować skoro raz
>> mam String, a raz double? Do jakiego obiektu,
>> kontenera, listy, map?
>
> Przetwarzać liniami i wtedy po wczytaniu linię
> dzielić na całostki StringTokenizerem
> (http://docs.oracle.com/javase/7/docs/api/java/util/StringTokenizer.html)
> lub przetwarzać
> po kolei i wtedy dzielić na całostki
> StreamTokenizerem
> (http://docs.oracle.com/javase/7/docs/api/java/io/StreamTokenizer.html)
> albo Scannerem
> (http://docs.oracle.com/javase/7/docs/api/java/util/Scanner.html).
>
>
> Napisać klasę, coś jak:
>
> class Bryła {
>    private String nazwa;
>    private double x,y,z;
>    private int typ; // albo jakiś enum
>    //...
> }
>
> i dane z linii pliku ładować do obiektów tej
> klasy. A kolekcja obiektów tej klasy taka,
> jaka wynika z dalszych celów zabawy z tymi bryłami.
>
Dzięki za odpowiedź.
Co do odczytu z samego pliku linii i podziału za 
pomocą np. StringTokenizer to mam już zrobione i z 
tym nie ma problemu.
Natomiast co do klasy to właśnie chciałem tego 
uniknąć bo tych danych jest ok 40 (większy problem 
obliczeniowy niż liczenie brył - dałem tylko 
przykład). Stąd, mimo klasy, trzeba będzie żmudnie 
podstawiać x=10, y=12... n=123

Myślałem nad "tablicą" zawierającą informacje 
parami (dodatkowo takie coś by miało sens z 
jeszcze innych powodów - łatwe wyszukiwanie danych 
po nazwie):
t[0] = x=10
t[1] = y=12
...
t[n] = n=123

Oczywiście przykład abstrakcyjny.
Niemniej nie da się zadeklarować wprost typu 
danych takiej "tablicy" bo są to, raz pary String 
= String, a raz String = double.
Ale jak nic mi sensownego nie wpadnie do głowy to 
ww klasa jest jedynym wyjściem.

Jadalbert <maxorin@poczta.onet.pl> napisał(a)
> W dniu 2012-12-20 07:36, TrzyLinie pisze:
>> W dniu 2012-12-19 23:50, Jadalbert napisał(a):
>>> w pierwszym wierszu są same Stringi
>>> w kolejnych wierszach i poszczególnych (stałych)
>>> kolumnach są Stringi, a w innych kolumnach
>>> double. Coś jak to:
>>> nazwa; x; y; z; typ;
>>> kula; 23.0; 34.1; 45.3; 1
>>> walec; 12.7; 23.3; 45.3; 2
>>
>>> I teraz pytanie. Do czego to ładować skoro raz
>>> mam String, a raz double? Do jakiego obiektu,
>>> kontenera, listy, map?
>>
>> Przetwarzać liniami i wtedy po wczytaniu linię
>> dzielić na całostki StringTokenizerem
>> (http://docs.oracle.com/javase/7/docs/api/java/util/StringTokenizer.html)
>> lub przetwarzać
>> po kolei i wtedy dzielić na całostki
>> StreamTokenizerem
>> (http://docs.oracle.com/javase/7/docs/api/java/io/StreamTokenizer.html)
>> albo Scannerem
>> (http://docs.oracle.com/javase/7/docs/api/java/util/Scanner.html).
>>
>>
>> Napisać klasę, coś jak:
>>
>> class Bryła {
>>    private String nazwa;
>>    private double x,y,z;
>>    private int typ; // albo jakiś enum
>>    //...
>> }
>>
>> i dane z linii pliku ładować do obiektów tej
>> klasy. A kolekcja obiektów tej klasy taka,
>> jaka wynika z dalszych celów zabawy z tymi bryłami.
>>
> Dzięki za odpowiedź.
> Co do odczytu z samego pliku linii i podziału za 
> pomocą np. StringTokenizer to mam już zrobione i z 
> tym nie ma problemu.
> Natomiast co do klasy to właśnie chciałem tego 
> uniknąć bo tych danych jest ok 40 (większy problem 
> obliczeniowy niż liczenie brył - dałem tylko 
> przykład). Stąd, mimo klasy, trzeba będzie żmudnie 
> podstawiać x=10, y=12... n=123
>
>

No to ładuj do Map<String, Object>

Nic dobrego z tego nie wyniknie:), ale może akurat w Twoim przypadku
przejdzie.

-- 
Tomek

W dniu 2012-12-20 17:27, Tomek Kańka pisze:
> Jadalbert <maxorin@poczta.onet.pl> napisał(a)
..........
>>>
>>> Przetwarzać liniami i wtedy po wczytaniu linię
>>> dzielić na całostki StringTokenizerem
>>> (http://docs.oracle.com/javase/7/docs/api/java/util/StringTokenizer.html)
>>> lub przetwarzać
>>> po kolei i wtedy dzielić na całostki
>>> StreamTokenizerem
>>> (http://docs.oracle.com/javase/7/docs/api/java/io/StreamTokenizer.html)
>>> albo Scannerem
>>> (http://docs.oracle.com/javase/7/docs/api/java/util/Scanner.html).
>>>
>>>
>>> Napisać klasę, coś jak:
>>>
>>> class Bryła {
>>>     private String nazwa;
>>>     private double x,y,z;
>>>     private int typ; // albo jakiś enum
>>>     //...
>>> }
>>>
>>> i dane z linii pliku ładować do obiektów tej
>>> klasy. A kolekcja obiektów tej klasy taka,
>>> jaka wynika z dalszych celów zabawy z tymi bryłami.
>>>
>> Dzięki za odpowiedź.
>> Co do odczytu z samego pliku linii i podziału za
>> pomocą np. StringTokenizer to mam już zrobione i z
>> tym nie ma problemu.
>> Natomiast co do klasy to właśnie chciałem tego
>> uniknąć bo tych danych jest ok 40 (większy problem
>> obliczeniowy niż liczenie brył - dałem tylko
>> przykład). Stąd, mimo klasy, trzeba będzie żmudnie
>> podstawiać x=10, y=12... n=123
>>
>>
>
> No to ładuj do Map<String, Object>
>
> Nic dobrego z tego nie wyniknie:), ale może akurat w Twoim przypadku
> przejdzie.
>
Ok. Ale piszesz tak, bo map uważasz za zły pomysł 
w ogóle (oczywiście w tym wypadku)? Wg ciebie 
rozwiązanie z klasa jw jest odpowiednie? Pytam 
serio, bo ja mam małe doświadczenie w javie i nie 
wiem czy w ogóle się męczyć z wymyślaniem Bóg wie 
czego.

Jadalbert <maxorin@poczta.onet.pl> napisał(a)
>>
>> No to ładuj do Map<String, Object>
>>
>> Nic dobrego z tego nie wyniknie:), ale może akurat w Twoim przypadku
>> przejdzie.
>>
> Ok. Ale piszesz tak, bo map uważasz za zły pomysł 
> w ogóle (oczywiście w tym wypadku)? Wg ciebie 
> rozwiązanie z klasa jw jest odpowiednie? Pytam 
> serio, bo ja mam małe doświadczenie w javie i nie 
> wiem czy w ogóle się męczyć z wymyślaniem Bóg wie 
> czego.
>

Piszę tak, bo to zupełnie nie "obiektowe" podejście, do tego nie
type-safe, itd. Za to wyjątkowo elastyczne. Jeśli Twoim celem po
wczytaniu danych będzie wypisane tego w postaci 
nazwa=wartość 
możesz tak zrobić, ale jeśli chcesz potem np.

((int)map.get('ile')) * ((Double) map.get('wartosc'))) * ...

to sam widzisz, że nie powinieneś iść tą drogą.

-- 
Tomek

W dniu 2012-12-20 23:24, Tomek Kańka napisał(a):
> Jadalbert <maxorin@poczta.onet.pl> napisał(a)
>>>
>>> No to ładuj do Map<String, Object>
>>>
>>> Nic dobrego z tego nie wyniknie:), ale może akurat w Twoim przypadku
>>> przejdzie.
>>>
>> Ok. Ale piszesz tak, bo map uważasz za zły pomysł
>> w ogóle (oczywiście w tym wypadku)? Wg ciebie
>> rozwiązanie z klasa jw jest odpowiednie? Pytam
>> serio, bo ja mam małe doświadczenie w javie i nie
>> wiem czy w ogóle się męczyć z wymyślaniem Bóg wie
>> czego.
>>
>
> Piszę tak, bo to zupełnie nie "obiektowe" podejście, do tego nie
> type-safe, itd. Za to wyjątkowo elastyczne. Jeśli Twoim celem po
> wczytaniu danych będzie wypisane tego w postaci
> nazwa=wartość
> możesz tak zrobić, ale jeśli chcesz potem np.
>
> ((int)map.get('ile')) * ((Double) map.get('wartosc'))) * ...
>
> to sam widzisz, że nie powinieneś iść tą drogą.

Zaproponuj, proszę, rozwiązanie, które będzie i obiektowe, i type-safe,
i pozwoli stwierdzić, że zaproponowaną drogą powinno się iść (nie musi
być "wyjątkowo elastyczne"). Chciałbym oprócz listy wad pierwszej
propozycji zobaczyć propozycję lepszą wg tych kryteriów. Ale może za
dużo chcę... ;)

-- 
TrzyLinie

Witam,
Kiedyś używałem do procesowania plików csv biblioteki java opencsv. Tam jest możliwość konwersji pojedyńczej lini w pliku do reprezentacji obiektowej java bean -a. 
http://opencsv.sourceforge.net/#javabean-integration
Pozd.

W dniu 2012-12-30 18:52, czeslaw.szczotka pisze:
> Witam,
> Kiedyś używałem do procesowania plików csv biblioteki java opencsv. Tam jest możliwość konwersji pojedyńczej lini w pliku do reprezentacji obiektowej java bean -a.
> http://opencsv.sourceforge.net/#javabean-integration
> Pozd.
>
Dzięki za radę. Obadam ten sposób. Na razie 
poradziłem sobie ładując wszystko po kolei do pól 
klasy z uwzględnieniem typu zmiennych zarówno w 
linii (pierwsza nagłówkowa String) i dla kolejnych 
linii w kolumnach (String, double, int). Jeśli się 
zachowuje reżim kolejności w csv i klasie, jest 
ok. Niestety nie jest to eleganckie rozwiązanie.

W dniu 2013-01-03 07:46, Jadalbert napisał(a):
> Na razie poradziłem sobie ładując wszystko po kolei do pól klasy z uwzględnieniem typu zmiennych zarówno w linii (pierwsza nagłówkowa
> String) i dla kolejnych linii w kolumnach (String, double, int). Jeśli się zachowuje reżim kolejności w csv i klasie, jest ok. Niestety nie jest to eleganckie rozwiązanie.

Jejku, czego ja nie wiem, że uważam sposób z klasą za jak najbardziej elegancki?!? Co
masz do zarzucenia temu sposobowi?!?

I dlaczego uważasz, że trzeba zachowywać "reżim kolejności w csv i klasie"? Albo co masz
na myśli mówiąc o zachowywaniu "kolejności"? Kolejność czego?

-- 
TrzyLinie

W dniu 2013-01-03 11:15, TrzyLinie pisze:
> W dniu 2013-01-03 07:46, Jadalbert napisał(a):
>> Na razie poradziłem sobie ładując wszystko po
>> kolei do pól klasy z uwzględnieniem typu
>> zmiennych zarówno w linii (pierwsza nagłówkowa
>> String) i dla kolejnych linii w kolumnach
>> (String, double, int). Jeśli się zachowuje reżim
>> kolejności w csv i klasie, jest ok. Niestety nie
>> jest to eleganckie rozwiązanie.
>
> Jejku, czego ja nie wiem, że uważam sposób z klasą
> za jak najbardziej elegancki?!? Co
> masz do zarzucenia temu sposobowi?!?
No może za ostro się wypowiedziałem. Klasa jest 
ok. Nie eleganckość polega wg mnie tym (ale to 
problem mojego kodu, na razie), że trzeba żmudnie 
wpisywać dane do pól, a jest ich sporo. Ze względu 
na to, że te dane maja różne typy w obrębie 
wiersza konieczny jest reżim. Czyli jak mam w 
pliku i wierszu drugim:
walec, 100.0, 20.0, 1
to w klasie muszę czytać:
nazwa = walec (bo to String)
wysokosc = 100.00 (bo to double)
srednica = 20.0 (bo to double)
typ_bryly = 1 (bo to int)
itd.
Powyższe to jedynie przykład. Naprawdę jest tych 
danych więcej. Do tego są one tworzone w excelu i 
zapisywane jako cvs, więc i użytkownik w excelu 
się może pomylić i pisać "Stringa" w komórce 
"double". Oczywiście wiem, że i to można ogarnąć i 
to w końcu ogarnę. Ale umyśliłem sobie klasę typu
Cokolwiek {
nazwa String;
wartość cokolwiek;
}
Pomarzyć można.

>
> I dlaczego uważasz, że trzeba zachowywać "reżim
> kolejności w csv i klasie"? Albo co masz
> na myśli mówiąc o zachowywaniu "kolejności"?
> Kolejność czego?
>

W dniu 2013-01-03 12:18, Jadalbert napisał(a):
> W dniu 2013-01-03 11:15, TrzyLinie pisze:
>> W dniu 2013-01-03 07:46, Jadalbert napisał(a):
>>> Na razie poradziłem sobie ładując wszystko po
>>> kolei do pól klasy z uwzględnieniem typu
>>> zmiennych zarówno w linii (pierwsza nagłówkowa
>>> String) i dla kolejnych linii w kolumnach
>>> (String, double, int). Jeśli się zachowuje reżim
>>> kolejności w csv i klasie, jest ok. Niestety nie
>>> jest to eleganckie rozwiązanie.
>>
>> Jejku, czego ja nie wiem, że uważam sposób z klasą
>> za jak najbardziej elegancki?!? Co
>> masz do zarzucenia temu sposobowi?!?
> No może za ostro się wypowiedziałem. Klasa jest ok. Nie eleganckość polega wg mnie tym (ale to problem mojego kodu, na razie), że trzeba żmudnie wpisywać dane do pól, a
> jest ich sporo. Ze względu na to, że te dane maja różne typy w obrębie wiersza konieczny jest reżim. Czyli jak mam w pliku i wierszu drugim:
> walec, 100.0, 20.0, 1
> to w klasie muszę czytać:
> nazwa = walec (bo to String)
> wysokosc = 100.00 (bo to double)
> srednica = 20.0 (bo to double)
> typ_bryly = 1 (bo to int)
> itd.
> Powyższe to jedynie przykład. Naprawdę jest tych danych więcej. Do tego są one tworzone w excelu i zapisywane jako cvs, więc i użytkownik w excelu się może pomylić i pisać
> "Stringa" w komórce "double". Oczywiście wiem, że i to można ogarnąć i to w końcu ogarnę. Ale umyśliłem sobie klasę typu
> Cokolwiek {
> nazwa String;
> wartość cokolwiek;
> }

Już rozumiem co Ci się nie podoba, choć dalej nie rozumiem dlaczego ;) CSV to przecież
zwykły tekst, więc zawsze trzeba to po przeczytaniu sparsować do odpowiedniego typu...
Jeśli CSV to czytanie wg "reżimu" - może spróbować wycisnąć z Excela inny format niż CSV?
Np. http://jexcelapi.sourceforge.net/ wprost do odczytu XLS? :)

-- 
TrzyLinie