Wozu sind Attribute gut ?

[Furtbichler]

Na, vielleicht meinte der Insider2004 nur, das man erst das Handwerkszeug lernen sollte, bevor man mit dem Ausschmücken anfängt. Hier isses aber nun einmal so, das Attribute nur ein weiteres Werkzeug zur Modellierung der Lösung sind. Klar sollte man damit nicht anfangen, wenn man die ersten 'Hello World'-Programme schreibt, aber wenn Attribute überflüssig sind, dann sind es Klassen auch.

Allerdings...

Zitat von Insider2004:

Eingekauft von .net, java und sonstigen Meta-Sprachen.

Was sind Meta-Sprachen?

Zitat:

Wenn ihr richtige Software Engineers werden wollt, dann ignoriert Attribute einfach.

Das ist die schmerzhafteste Aussage des Jahres.

[Uwe Raabe]

Zitat von Furtbichler:

Zitat:

Wenn ihr richtige Software Engineers werden wollt, dann ignoriert Attribute einfach.

Das ist die schmerzhafteste Aussage des Jahres.

Delphi-Quellcode:

TDelphiPraxis.OnComment(Comment: TComment);
begin
  if Comment.Sender = 'Insider2004' then 
    Comment.Text := '';
end;

[Furtbichler]

Si.

[Phoenix]

Please, don't feed the Troll.

[squetk]

Zitat:

ich weiß, daß ich es garantiert nichts so machen würde.

Zitat:

dies in jeder Kundendatenbank von Hand nachgetragen werden musste.

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

[Elvis]

Zitat von squetk:

Zitat:

ich weiß, daß ich es garantiert nichts so machen würde.

Zitat:

dies in jeder Kundendatenbank von Hand nachgetragen werden musste.

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

Hmm...
Ich finde für solche Infos sind Resources immer noch ideal, weil parallel zur DB versionierbar. Man kann mit 2 Versionen der Software auf der gleichen DB arbeiten ohne, dass man Side effects für dogmatischen Käse riskiert. Schlimm genug wenn man in den Situationen Side effects für tatsächlich sinnvolle Dinge bekommt.
Und sorry, aber Command Labels etc. in einer DB zu halten ist Käse.
Wenn man die von einem Release zum anderen wirklich umbenennen will, dann werden halt die ResX angepasst.

[Phoenix]

Zitat von Elvis:

Ich finde für solche Infos sind Resources immer noch ideal, weil parallel zur DB versionierbar. Man kann mit 2 Versionen der Software auf der gleichen DB arbeiten ohne, dass man Side effects für dogmatischen Käse riskiert.

Grundsätzlich korrekt. Außer natürlich, der Kunde will translations für sich angepasst haben.

Wir haben die Translations tatsächlich auch in der Datenbank. Und wir haben pro Version Updatescripte, die geänderte Translations anpassen, sofern sie noch den Originalwert haben.

Ist zwar was mühsam, aber funktioniert.

[Uwe Raabe]

Zitat von squetk:

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

Wenn es sich bei diesen "Textinformationen" z.B. um die Liste der verfügbaren Maschinen beim Kunden handelt, stimme ich dir zu. Wenn es aber um die passende Übersetzung des Labels "Stückzahl" geht, hat das nur in Ausnahmefällen was in der (Kunden-)Datenbank verloren (nur meine Meinung). Ach ja, ein ORM nutzt wohl auch nicht jeder - von einem guten ganz abgesehen. Das sollte aber jetzt nicht in einen Glaubenskrieg ausarten.

Es könnte sich als etwas schwierig erweisen, die Screenshots für die Dokumentation zu machen, wenn der Kunde quasi die gesamten Beschriftungen eines Forms verändern kann. Womöglich ergeben sich dabei ganz andere Bedeutungen und das Programm tut nicht mehr das, was man erwarten würde.

Ich stelle damit nicht grundsätzlich die Speicherung von Übersetzungen in einer Datenbank in Frage, wenn das verwendete Übersetzungs-Framework dies so realisiert.

Aber ich glaube wir schweifen ab.

[Der schöne Günther]

Zitat von Uwe Raabe:

Es könnte sich als etwas schwierig erweisen, die Screenshots für die Dokumentation zu machen, wenn der Kunde quasi die gesamten Beschriftungen eines Forms verändern kann. Womöglich ergeben sich dabei ganz andere Bedeutungen und das Programm tut nicht mehr das, was man erwarten würde.

Vor dem Problem stehe ich auch bald, danke schonmal für den Warnhinweis , spontan hätte ich das Problem nicht gesehen (dafür schon jetzt jede Menge andere ).