Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buchungsklasse bei Splitbuchung übernehmen #535

Merged
merged 2 commits into from
Dec 17, 2024
Merged

Buchungsklasse bei Splitbuchung übernehmen #535

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6060fd8
Buchungsklasse bei Splitbuchung übernehmen
Dec 17, 2024
eff8e48
Buchungsklasse auch bei Steuer setzen + Fix getBuchungsklasse
Dec 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/de/jost_net/JVerein/gui/action/SplitbuchungNeuAction.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,7 @@ public void handleAction(Object context)
buch.setUmsatzid(master.getUmsatzid());
buch.setZweck(master.getZweck());
buch.setBuchungsartId(master.getBuchungsartId());
buch.setBuchungsklasseId(master.getBuchungsklasseId());
buch.setSpeicherung(false);
buch.setSplitTyp(SplitbuchungTyp.SPLIT);
buch.setBetrag(SplitbuchungsContainer.getSumme(SplitbuchungTyp.HAUPT).doubleValue() - SplitbuchungsContainer.getSumme(SplitbuchungTyp.SPLIT).doubleValue());
Expand Down
1 change: 1 addition & 0 deletions src/de/jost_net/JVerein/gui/control/BuchungsControl.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -988,6 +988,7 @@ private void handleStore() throws ApplicationException
}

b_steuer.setBuchungsartId(Long.valueOf(b_art.getSteuerBuchungsart().getID()));
b_steuer.setBuchungsklasseId(b_art.getBuchungsklasseId());
b_steuer.setBetrag(steuer.doubleValue());
b_steuer.setZweck(b.getZweck() + zweck_postfix);
b_steuer.setSplitId(b.getSplitId());
Expand Down
13 changes: 8 additions & 5 deletions src/de/jost_net/JVerein/server/BuchungsartImpl.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,10 +89,6 @@ protected void updateCheck() throws ApplicationException
@Override
protected Class<?> getForeignObject(String arg0)
{
if ("buchungsklasse".equals(arg0))
{
return Buchungsklasse.class;
}
return null;
}

Expand Down Expand Up @@ -160,7 +156,14 @@ public void setStatus(int status) throws RemoteException
@Override
public Buchungsklasse getBuchungsklasse() throws RemoteException
{
return (Buchungsklasse) getAttribute("buchungsklasse");
Long l = (Long) super.getAttribute("buchungsklasse");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich fände es super, wenn wir anfangen würden, Konstanten für die Strings zu verwenden.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Könnt ihr mir erklären was das in dieser Art von File für einen Vorteil bringen soll. Das ist doch hier einfach nur doppelte Arbeit und doppelt fehleranfällig.
Ich sehe da nicht wirklich einen Vorteil.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was meinst du mit "doppelte Arbeit" und "doppelt fehleranfällig"?
Die Konstante deklarieren und dann zweimal verwenden? Einmal hier und einmal in der Zeile, die mit 003d6be eingefügt wurde? Außerdem werden Feldnamen ja auch noch in anderen Java-Dateien (z. B. db updates) verwendet.
Konstanten haben den Vorteil, dass der Compiler deren Verwendung checkt. Wenn man einen Tippfehler macht, meckert er sofort. Das kann er bei Strings nicht erkennen. Außerdem lassen sich Strings nicht refactoren im Sinne von umbenennen, Konstanten schon. Falls man doch mal die Deklaration, also den String ändern will/muss, macht man das genau an einer Stelle. Das ist dann weniger fehleranfällig, als mehrere Strings zu ändern und ggf. einen zu übersehen, auch wenn es insgesamt ganz wenige Strings sind.
Zu guter Letzt kann man noch die Verwendung von Konstanten ganz einfach feststellen: Rechtsklick -> References. Das geht auch nicht mit Strings.
Das Refactoring von Strings funktioniert insofern ganz gut, als das man Rechtsklick -> Refactor -> Extract Constant... wählen kann.

In meinen Projekten verwende ich durchgehend Konstanten statt Strings, mit Ausnahme von englischen Fehlermeldungen, die exalt so ins log geschrieben werden sollen. Das reduziere ich jedoch auch weitestgehend, da sie nicht lokalisierbar/übersetzbar sind.

Bitte verstehe mich nicht falsch. Es ist nur ein Vorschlag, der meiner Ansicht nach die Code Qualität und das spätere Arbeiten verbessert.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, habe es verstanden. Das macht wohl dann Sinn.
Dann reicht es aber nicht nur die zwei Zeilen zu ändern. Dann muss ich auch alle Stellen finden wo der String verwendet wird damit das mit dem umbenennen usw. auch wirklich funktioniert.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactor -> Extract Constant...

Ist dein Freund. 😄 Es wäre schon mal ein Anfang, wenn man es in der einen Datei macht. Dann kann man projektweit suchen, wo es ggf. noch als String verwendet wird.

if (l == null)
{
return null; // Keine Buchungsklasse zugeordnet
}

Cache cache = Cache.get(Buchungsklasse.class, true);
return (Buchungsklasse) cache.get(l);
tolot27 marked this conversation as resolved.
Show resolved Hide resolved
}

@Override
Expand Down
Loading