Zasoby (assety) od producenta i ich dalsze życie

Tak pomyślałem, ze koncepcja "asset" jest mało modna w javie, bardziej we frontendzie, ale właśnie o to mi chodzi
Producent pudełkowego softwaru Javowskiego daje ... wstępne arkusze CSS, wstępne skrypty w Groovym, JSONy z konfiguracją etc...

na wdrożeniu u użytkownika może będą używane bez zmian, a może zostaną przeedytowane i zapisane w bazie, dziś lub za dwa lata.
Życie po edycji jest dość jasne: baza i jest ok.

Ciekawie jest przed edycją.
Powiedzmy ze paczkujemy to w JAR resources, standardowo
Ich codzienna eksploatacja może być na dwa sposoby

1 sposób
a) najpierw sprawdzamy w bazie danych, czy mamy. Jak mamy, znaczy że była edycja i edytowany zasłania ten z dystrybucji producenta
b) jak nie ma - bierzemy resource
Zaleta (dla mnie) o ile w nowszej wersji producent dał coś nowszego, za darmo jest aktualizowane

2 sposób
a) przy instalacji przerzucamy wszytskie do bazy
b) a codziennej eksploatacji sięgamy tylko do bazy
Pewnie szybsze (zgaduję)
Wada: w przypadku gdy producent w nowej wersji zaktualizował, Houston mamy problem

na zmianę w skali lat czasem robimy tak, czasem tak ... wszystko ma zady i walety

Który wzorzec używacie, a może oprócz dwóch które dostrzegam, są inne ścieżki ?

Wydaje mi się że ciężko by było zrobić jakieś assety do javy lub do konfiguracji, co byś w nich konkretnie umieszczał? To nie frontend żeby zrobić zestaw ikonek bo każda aplikacja potrzebuje piktogramów do wiadomości. logowania, wylogowania, powiadomień itp.

nie wiem do końca o co chodzi, ale jeśli chodzi o takie assety (choć bardziej mi pasuje bundle) to są takie w zależności od producenta apki. Nie wiem jak bardzo jest to powszechna praktyka, spotkałem się z tym w ubezpieczeniach - GuideWire i EIS. I np. tacy producenci mają porobione bundle w zależności od tego czego taka ubezpieczalnia potrzebuje np. tylko obsługa call center, albo tylko polisy itp.
Albo można mieć wszystko oczywiście za odpowiednią opłatą licencji.
Wszystko jest w 1 paczce, jeden wielki monolit z frontendem. No i taką apkę trzeba jeszcze dostosować do potrzeb biznesowych klienta, bo pomimo, że procesy są podobne, to nie są identyczne, a w obrotach dokumentami to każda instytucja ma swoje procedury itd. A tak to, jest wszystko, żeby taką pakę uruchomić na serwerze.

EDIT: chyba już wiem o co Ci chodzi, powyższe potraktuj jako dygresję

ogólnie to co napisałeś, jest bardzo słabym pomysłem, nikt nie trzyma assetów w DB, od tego jest repo. Inna sprawa, jakoś nie potrafię sobie wyobrazić, że odpalony JAR zaciąga nowe assety z repo i je podmienia "live" na prodzie np. w banku. Można robić takie hece, ale to i tak wiąże się z pipelinem i budowaniem/deployem apki za każdym razem. Dlatego są releasy, inaczej wszyscy by się pozabijali.

@trojanus:

Trzyma, naprawdę tak się robi. Zapewniam.

Nie robi się w dwóch grupach:

• korpo dla korpo, software w jednej instancji -> 100% masz rację, repo, releasy, nastosobowy dział IT ...
• (pół) darmowe programy "Mała firma" jak statystyczny 4programmer pisze swoje faktury 1/mc - z braku takiego czegoś

Całą reszta średniego biznesu tak robi. Co więcej, jak program sprzedawany na średni biznes nie ma takich zmiennych "assetów" (już zostańmy przy tym słowie), to życie wymusza takie patologie, jak raporty/wydruki (wtedy wydruk daje 0 bajtów taska drukarki) które robią rzeczy aktywne (updaty danych), bo raporty są ostatnią redutą, że można "coś" zmodyfikować".
Albo życie wypycha naprawdę ważną aktywność z centralnego systemu do Excelli / żółtych karteczek / zeszytów

Generalnie to co opisujesz to coś w stylu CMS, ewentualnie CMS++ (czyli może ecommerce).
Nietypowe w javie, dlatego ludzie skonfudowani.

Widziałem różne rozwiązania, ale chyba najlepsze takie, że klient nie powinien nadpisywać (pod tą samą etykietą/ścieżką) assetów bazowych.
A jeśli już to robi to na własną odpowiedzialność i to jego problem.
Normalnie po prostu dodaje nowe assety i korzysta z dodanych.

Btw. skrypty groovy "w bazie" to brzmi jak jakiś koszmar - nawet takie rzeczy widziałem i to był "totalny kał".

jarekr000000 napisał(a):

Generalnie to co opisujesz to coś w stylu CMS, ewentualnie CMS++ (czyli może ecommerce).
Nietypowe w javie, dlatego ludzie skonfudowani.

Masowe w programach na średni biznes - fakt, coraz rzadziej sporządzanych w Javie / JVM. Raczej C (historycznie) /C++/ Delhi (rzadko skryptowane, częściej pan Zbyszek 55+ wyklika na kolanie nową wersje, psując coś innego) /C#

Widziałem różne rozwiązania, ale chyba najlepsze takie, że klient nie powinien nadpisywać (pod tą samą etykietą/ścieżką) assetów bazowych.
A jeśli już to robi to na własną odpowiedzialność i to jego problem.
Normalnie po prostu dodaje nowe assety i korzysta z dodanych.

Oczywiście że odpowiedzialność przechodzi po-przy dokonaniu modyfikacji - nikt tego nie neguje
Nowe po nową ścieżką to wyższy level - punkty wystawione przez API muszą mieć dostępny pole stringowe, gdzie nową etykietę można podać

Btw. skrypty groovy "w bazie" to brzmi jak jakiś koszmar - nawet takie rzeczy widziałem i to był "totalny kał".

Z tym totalnym kałem przesadzasz.

a faktycznie jest taki OpenCMS, zupełnie o tym zapomniałem, widocznie mój mózg wyparł to wspomnienie po traumie jaką była praca z tym raczyskiem
nie pamiętam ile tygodni z tym pracowałem, pamiętam za to uczucie radości jak mi się skończyła umowa próbna

Nie wiem czy niemodne, raczej ograniczona liczba zastosowań w Java.
Jest jeszcze 3 sposób, dajmy na to na "skórkę" aplikacji. Wrzucamy w resources wszystkie potrzebne "defaultowe" ikonki i podczas instalacji tworzymy plik z properties odwołujący się do tych zasobów. Użytkownikowi dajemy możliwość edytowania wartości properties i zmiany z wartości typu bundled://save_icon.png na file:///icons/my_icon.png

jarekr000000 napisał(a):

Widziałem różne rozwiązania, ale chyba najlepsze takie, że klient nie powinien nadpisywać (pod tą samą etykietą/ścieżką) assetów bazowych...
...
Normalnie po prostu dodaje nowe assety i korzysta z dodanych.

piotrpo napisał(a):

Użytkownikowi dajemy możliwość edytowania wartości properties i zmiany z wartości typu bundled://save_icon.png na file:///icons/my_icon.png

Dobra ... coś we mnie dojrzewa. Jeden poziom "indirekcji" nie jest szokiem, a daje sporo jasności (i możliwość przywrócenia, choćby na chwilę na próbę - "bundled")

można podać np. jakiś application.properties, który będzie wrzucany do classpatha i tam już mu nawrzucamy co jest w takim asset bundle. Ew. przez zmienne środowiskowe do uruchamianego procesu Java (np. gdzieś w setenv w Tomcat, albo innaczej propertasem -Dapp.props="..."") i obsłużyć to w apce - w sensie kolejność czytania tego pliku properties (który ważniejszy) - chyba, że jest jakaś określona kolejność w przypadku danego serwera. Wtedy można mieć defaulty spaczkowane, a customy dla danego klienta przygotowane osobno. Pozostaje jeszcze kwestia tego, co dzieje się przy aktualizacjach, gdzie dochodzą nowe configi od producenta - wtedy merge configa defaultowego + customa u klienta (z priorytetem na to drugie).