🚀 go-pugleaf

W dniu 2013-09-14 15:32, Borneq pisze:
> Pobierać listę plików dla danego katalogu można używając
> File[] filesAndDirs = dir.listFiles(); gdzie dir jest klasy File
> lub
> File[] filesAndDirs = fileSystemView.getFiles(currentDirectory, false);
> gdzie currentDirectory jest typu File
> To drugie rozwiązanie jest lepsze, bo zmieniając
> currentDirectory = fileSystemView.getParentDirectory(currentDirectory);
> nie ma problemu gdy idziemy wyżej niz był nasz pierwszy katalog, a w
> pierwszym rozwiązaniu bywały problemy.

Problemy? File.getParentFile() zawsze działa.


> Tymczasem gdy chcę się poruszać w archiwum a metoda listująca daje mi
> listę ścieżek, tworzę swoją klasę np. nazywając ją TreeFile, wypełniam
> ją ścieżkami, sortuję itd.
> A teraz pobieranie listy plików i katalogów
> filesAndDirs = treeFile.getFiles(currentDirectory)
> Jak to najlepiej rozwiązać? czy filesAndDirs ma być typu File[] ? ale
> wówczas currentDirectory oznaczający katalog w archiwum też ma być typu
> File.Ale wówczas chyba jest źle bo File oznaczają rzeczywiste pliki. Czy
> też wprowadzić elementy typu TreeFileItem implementujące Comparable? ale
> wówczas będą potrzebne zupełnie rózne metody do chodzenia po
> rzeczywistych katalogach a inne po archiwum.


Trochę nie tak.

Po pierwsze, nie próbuj tworzyć wspólnego interfejsu z File i czymś do 
archiwów. Raczej zrób owijki do obu, ze wspólnym interfejsem, i tego 
interfejsu używaj dalej w kodzie.

Tzn prawdopodobnie masz już gotową bibliotekę do archiwów, z obiektowym 
dostępem do plików wewnątrz. Nie ma sensu pisać tego samemu.

Więc stwórz interfejs (np MyFile), ze wszystkimi metodami które musisz 
mieć w aplikacji. I tylko takimi które muszą być, nie sil się na pisanie 
metod których i tak nie użyjesz. Zawsze możesz potem dodać nowe metody.

W następnym kroku piszesz dwie owijki, implementujące MyFile. Jedna 
będzie przekazywać i tłumacvzyć wywołania interfejsu MyFile do 
java.io.File, a druga do obektu pracujęcego archiwum.

I teraz dodanie obsługi nowego typu archiwum sprowadza się do dodanie 
nowej klasy owijki inplementującej MyFile.

-- 
Arivald

Użytkownik "Arivald" <NOSPAMarivald@interia.pl> napisał w wiadomości 
news:l12gel$9lv$1@news.dialog.net.pl...
> I teraz dodanie obsługi nowego typu archiwum sprowadza się do dodanie 
> nowej klasy owijki inplementującej MyFile.

Na SourceForge jest projekt 7-Zip-JBinding który daje interfejs Javy dla 
masy formatów obsługiwanych przez 7-zip. Nie obsługuje .ace, więc teraz 
zrobiłem owijkę biblioteki UnAceV2.dll. Dziala w ten sposób, że wołam metodę 
natywną do listowania i jako parametr zaimplementowany interfejs, informacje 
zbierane są w tej implementacji interfejsu.Chcę teraz zrobić demo do UnACE 
które zamiast dawać listę ścieżek printfem, wejdzie do katalogu.. 

Użytkownik "Arivald" <NOSPAMarivald@interia.pl> napisał w wiadomości 
news:l12gel$9lv$1@news.dialog.net.pl...
> Problemy? File.getParentFile() zawsze działa.

Ja używałem tworzenie nowego obiektu z parametrem "..", choć warto użyć 
FileSystemView bo daje ikonki plików.

> Więc stwórz interfejs (np MyFile), ze wszystkimi metodami które musisz 
> mieć w aplikacji. I tylko takimi które muszą być, nie sil się na pisanie 
> metod których i tak nie użyjesz. Zawsze możesz potem dodać nowe metody.

Potrzebne metody to : zmiana katalogu,m wejście głębiej i wyżej "..", oraz 
metoda dająca listę plików i katalogów dla danej pozycji. Mogę mieć więc 
interfejs i dwie implementacje, jednak co z elementami zwracanymi przez 
metodę listowania bieżącej pozycji? Raz to będą File[] raz moje itemy. Czy 
jako parametr pozycji oraz zwracane wartości też podawać interfejsy?
np. interfejs ITree oraz jego implementacje :RealTree i ArchiveTree

Pozdrawiam 

Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał w wiadomości 
news:l13jje$j6j$1@node2.news.atman.pl...
> np. interfejs ITree oraz jego implementacje :RealTree i ArchiveTree
RealTree oraz AceTree i SevenZipTree 

W dniu 2013-09-15 08:20, Borneq pisze:
> Użytkownik "Arivald" <NOSPAMarivald@interia.pl> napisał w wiadomości
> news:l12gel$9lv$1@news.dialog.net.pl...
>> Problemy? File.getParentFile() zawsze działa.
>
> Ja używałem tworzenie nowego obiektu z parametrem "..", choć warto użyć
> FileSystemView bo daje ikonki plików.
>

Zainteresuj się Apache Commons IO, moduł FilenameUtils posiada metody do 
normalizacji ścieżek do plików. Zamieni Ci żcieżki z ".." na rzeczywiste.


>> Więc stwórz interfejs (np MyFile), ze wszystkimi metodami które musisz
>> mieć w aplikacji. I tylko takimi które muszą być, nie sil się na
>> pisanie metod których i tak nie użyjesz. Zawsze możesz potem dodać
>> nowe metody.
>
> Potrzebne metody to : zmiana katalogu,m wejście głębiej i wyżej "..",
> oraz metoda dająca listę plików i katalogów dla danej pozycji. Mogę mieć
> więc interfejs i dwie implementacje, jednak co z elementami zwracanymi
> przez metodę listowania bieżącej pozycji? Raz to będą File[] raz moje
> itemy. Czy jako parametr pozycji oraz zwracane wartości też podawać
> interfejsy?
> np. interfejs ITree oraz jego implementacje :RealTree i ArchiveTree

Nie File[], zawsze zwracasz ITree[]. A czy to ITree będzie RealTree czy 
ArchiveTree to nie ma znaczenia, to zależy od implementacji.


interface ITree {
     public ITree getPatent();
     public ITree[] listFiles();

     public ITree cd(String folderName);
     ....
}



Jak zaprogramujesz to dobrze, to np. ArchiveTree będące w głównym 
katalogu będzie zwracać obiekt RealTree w wywołaniu getParent(), a 
RealTree po wejściu do archiwum będzie zwracać obiekty ArchiveTree.


BTW w Javie nie ma konwencji że interfejs zaczyna się od "I". Chodzi o 
to, że w przeciwieństwie do Delphi, w Javie interfejs praktycznie niczym 
nie różnie się od klasy, tyle że nie zawiera implementacji metod.
Dodatkowo są klasy abstrakcyjne, czyli takie które mogą zawierać 
jednocześnie metody zaimplementowane i puste.

-- 
Arivald

Użytkownik "Arivald" <NOSPAMarivald@interia.pl> napisał w wiadomości 
news:l13qjn$rjn$1@news.dialog.net.pl...
> Nie File[], zawsze zwracasz ITree[]. A czy to ITree będzie RealTree czy 
> ArchiveTree to nie ma znaczenia, to zależy od implementacji.

Zrozumiałem, główną klasą będzie opis danego pliku a nie całe archiwum
++++++++++++++++
package com.borneq.io;

import javax.swing.Icon;

public interface Item {
 Icon getIcon();
 String getName();
 boolean isDirectory();
 long length();
 String lastModified();
 String getCanonicalPath();
}
natomiast do Archve może odwoływać się przez ownera

> Zainteresuj się Apache Commons IO, moduł FilenameUtils posiada metody do 
> normalizacji ścieżek do plików. Zamieni Ci żcieżki z ".." na rzeczywiste.

 Jest w standardzie Javy?

Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał w wiadomości 
news:l13tgv$skg$1@node2.news.atman.pl...
>> Zainteresuj się Apache Commons IO, moduł FilenameUtils posiada metody do 
>> normalizacji ścieżek do plików. Zamieni Ci żcieżki z ".." na rzeczywiste.
>
> Jest w standardzie Javy?

To takie Boost C++ dla Javy 

On Sun, 15 Sep 2013 10:17:08 +0200, Arivald 
<NOSPAMarivald@interia.pl> wrote:
> BTW w Javie nie ma konwencji że interfejs zaczyna się od "I". 
Chodzi o 
> to, że w przeciwieństwie do Delphi, w Javie interfejs praktycznie 
niczym 
> nie różnie się od klasy, tyle że nie zawiera implementacji metod.

No i tym, ze nie możesz dziedziczyc po więcej niż jednej klasie, ale 
możesz po dowolnie wielu interfejsach.

RW

W dniu 2013-09-15 11:09, Borneq napisał(a):
> Użytkownik "Arivald" <NOSPAMarivald@interia.pl> napisał w wiadomości news:l13qjn$rjn$1@news.dialog.net.pl...
>> Zainteresuj się Apache Commons IO, moduł FilenameUtils posiada metody do normalizacji ścieżek do plików. Zamieni Ci żcieżki z ".." na rzeczywiste.
>
> Jest w standardzie Javy?

Od wersji 1.7 jest java.nio.file.Files i pokrewne klasy.

-- 
TrzyLinie

Użytkownik "TrzyLinie" <trzyUSUNlinie@o2DEL.pl> napisał w wiadomości 
news:l16c92$img$1@dont-email.me...
>> Jest w standardzie Javy?
>
> Od wersji 1.7 jest java.nio.file.Files i pokrewne klasy.

Na razie uzylem Apache, ale zainteresuję się java.nio.file.Files