AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Rätselhaftes Konstrukt in Unit Dialogs

Ein Thema von idefix2 · begonnen am 29. Jan 2012 · letzter Beitrag vom 31. Jan 2012
Antwort Antwort
Seite 2 von 3     12 3   
daywalker9

Registriert seit: 1. Jan 2010
Ort: Leer
594 Beiträge
 
Delphi XE3 Professional
 
#11

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 08:53
Zum beispiel sowas:

Delphi-Quellcode:
type
  ListAttribute = class(TCustomAttribute)
  private
    FTagName: String;
    FClass: TClass;
  public
    constructor Create(const ATagName: String; AClassType: TClass);
   end;


type
  TMyClass = class
    [ ListAttribute('SubPositions', TPositionInformation) ]
    property SubPositions : TObjectList<TPositionInformation> read FSubPositions write FSubPositions;
    [ ListAttribute('DatabaseVersions', TDatabaseVersion) ]
    property DatabaseVersions : TObjectList<TDatabaseVersion> read FDatabaseVersions write FDatabaseVersions;
    [ ListAttribute('ProductionUnits', TProductionUnit) ]
    property ProductionUnits : TObjectList<TProductionUnit> read FProductionUnits write FProductionUnits;
    [ ListAttribute('Segments', TPositionSegment) ]
    property Segments : TObjectList<TPositionSegment> read fSegments write FSegments;
   end;
Passend dafür gibts einen Serializer der auf der neuen RTTI aufbaut und wenn ich eine Liste habe, weiß ich durch das Attribute, wie der Knoten in der XML heißt und welche Klasse ich dafür erzeugen muss.
Lars
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
Ort: Offingen
3.159 Beiträge
 
Delphi XE Professional
 
#12

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 09:04
Beispiel für die Nutzung bei uns:
Per Attribut wird festgelegt welche XML-Knoten oder Datenbankeinträge zu den Feldern der Klasse gehören. Danach kann man die einfach an eine Funktion übergeben, die dann die Daten liest oder schreibt. Benutzen tun wir das z.B. bei Einstellungsklassen. Auf diese Weise müssen die Einstellungsklassen nichts über die Datenstrukturen wissen, in denen die Daten liegen.
Mache ich genauso - als hätten wir voneinander abgeschrieben "Great minds think alike!"
Ich verklage euch -- ihr habt mein Patent 0815 verletzt

@Luckie: Wie scheinbar auch andere, handhabe ich das Mapping von Datenbank-Tabellen auf Objekte via Attribute. Beispiel:
Delphi-Quellcode:
// Tablle Blub:
// Spalte1
// Spalte2
// Spalte3

TModel = class abstract
public
  // Diese Methode analysiert die Klasse und lädt aus der zugewiesenen
  // Tabelle den nötigen Datensatz
  procedure Load(const PrimaryKey: Integer); virtual;
end;

// Dazu gehörige Klasse
[TTableAttribute('Blub')] // Zuweisung einer Tabelle
TBlubModel = class(TModel)
private
  [TTableColumnAttribute('Spalte1')]
  FValue1: String;
  [TTableColumnAttribute('Spalte1')]
  FValue2: Integer;
  [TTableColumnAttribute('Spalte1')]
  FXyz: Variant;
end;
So könnte das ganze aussehen. Du brauchst somit quasi nur eine Load-Methode schreiben, die via (der neuen) RTTI die abgeleitete Klasse TBlub analysiert und dann via PrimaryKey entsprechend lädt. Ist halt eine stark simplifizierte Version, aber ich denke, dass es schon aussagekräftig genug ist, bzw. das will ich mal hoffen

-- Edit: Alternativ könnte man auch einen "Loader" verwenden -- bin in Sache Patterns bzgl sowas leider nicht all zu fit. Hier mal mein Gedankengang:
Delphi-Quellcode:
// Es liegt hier selbige Tabelle, wie oben beschrieben, zugrunde!

// Basis-Model-Klasse
TModel = class abstract
end;

TModelClass = class of TModel;

// Konkretes Model
TBlubModel = class(TModel)
private
  [TTableColumnAttribute('Spalte1')]
  FValue1: String;
  [TTableColumnAttribute('Spalte1')]
  FValue2: Integer;
  [TTableColumnAttribute('Spalte1')]
  FXyz: Variant;
end;

// Loader
TBaseModelFactory = class
private
  procedure AnalyseModel(Model: TModelClass);
public
  function LoadByPk(Model: TModelClass; PrimaryKey: Integer): TModel;
  function LoadByAttributes(Model: TModelClass; Attributes: TArray<TModelAttribute>): TArray<Model>;
  function LoadbyWhereClause(Model: TModelClass; WhereClause: String): TArray<TModel>;
end;

// Nutzung:
var
  Model : TBlubModel;
  Models : TArray<TBlubModel>;
begin
  // Laden, über die Angabe des PK. Durch Angabe der klasse TBlubModel ist klar,
  // auf welche Tabelle zugegriffen werden muss.
  Model := TBaseModelFactory.LoadByPk(TBlubModel, 10);

  // Laden via "Filter", d.h. über Angabe von Attributen, die dann entsprechend
  // zu einer Where-Clause zusammengebaut werden.
  // WICHTIG: Die Attribute sind hier nicht in korrekter Delphi-Syntax angegeben
  // sondern entsprechend Pseudocode.
  Models := TBaseModelFactory.LoadbyAttributes(TBlubModel, ['Spalte1' = 10, 'Spalte2' = 'DP']);

  // ... und dann noch via selbst modelliertem Where-Clause.
  Models := TBaseModelFactory.LoadByWhereClause(TBlubModel, 'Spalte1 > 15 AND Spalte2 LIKE "%dp%"');
Für etwaige Fehler wird nicht gehaftet habe gerade alles nur schnell aus dem Kopf runtergeschrieben, ohne es zu testen.
Armin
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)

Geändert von s.h.a.r.k (30. Jan 2012 um 09:14 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
24.466 Beiträge
 
Delphi XE Professional
 
#13

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 09:13
IIRC macht Microsoft das ähnlich, wenn man z.B. in VS ein Dataset zu einer bestehenden Tabelle erstellen lässt.
Detlef
Wenn Dein Programm nicht macht, was es soll, nenn es einfach "Version 1.0"

Delphi programming is cool
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
27.746 Beiträge
 
Delphi XE3 Professional
 
#14

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 09:19
Delphi-Quellcode:
type
  TMyClass = class
    [ ListAttribute('SubPositions', TPositionInformation) ]
    property SubPositions : TObjectList<TPositionInformation> read FSubPositions write FSubPositions;
    [ ListAttribute('DatabaseVersions', TDatabaseVersion) ]
    property DatabaseVersions : TObjectList<TDatabaseVersion> read FDatabaseVersions write FDatabaseVersions;
    [ ListAttribute('ProductionUnits', TProductionUnit) ]
    property ProductionUnits : TObjectList<TProductionUnit> read FProductionUnits write FProductionUnits;
    [ ListAttribute('Segments', TPositionSegment) ]
    property Segments : TObjectList<TPositionSegment> read fSegments write FSegments;
   end;
Wobei man hier uch wieder von doppelten Informationen reden könnte.
TagName entpsricht ja dem Property-Namen, so daß man diesen Namen doch auch direkt verwenden könnte?
OK, an die Klasse in dem Generic ranzukommen ist nicht so einfach, aber Möglich wäre es bestimmt auch.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: München
11.260 Beiträge
 
Delphi 2010 Architect
 
#15

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 09:19
Diese Attribute sind insbesondere spannend, wenn man sich aus der DB-Struktur komplette Quellcodes erzeugen lässt. Dann fügt man die Attribute hinzu, um später dynamisch auf allen erzeugten Klassen zugreifen zu können, ohne dass man diese alle untereinander verlinken muss.

Delphi-Quellcode:
type
  /// <summary>
  /// Definitionen für das DB-Schema [inject]
  /// </summary>
  [DefineSchema('inject', '{12543F95-68E1-4F42-BA5D-479AFBBA12E1}')]
  TSchemaInject = class(TSchemaDefinition)
  public
    type
      /// <summary>
      /// Definitionen für die DB-SProc [inject].[Base_Login_Write]
      /// </summary>
      [DefineStoredProc(TSchemaInject, 'Base_Login_Write')]
      TSProcBase_Login_Write = class(TStoredProcDefinition)
      public
        ...
Später kann man im Code diese Klassen alle wieder auffinden und nutzen:
Delphi-Quellcode:
  Ctx := TRttiContext.Create;
  try
    for Typ in Ctx.GetTypes do
    begin
      if Typ.TypeKind <> tkClass then
        Continue;

      // load schemata
      if not Typ.AsInstance.MetaclassType.InheritsFrom(TSchemaDefinition) then
        Continue;

      for Attr in Typ.GetAttributes do
      begin
        if not (Attr is DefineSchemaAttribute) then
          Continue;
        FKnownSchemata.Add(TSchemaDefinitionClass(Typ.AsInstance.MetaclassType));
        Break;
      end;
    end;
  finally
    Ctx.Free;
  end;
Aus meiner Sicht eine der besten Neuerungen in der Delphi-Language seit langer Zeit (zusammen mit den Generics)

......
Daniel W.
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
27.746 Beiträge
 
Delphi XE3 Professional
 
#16

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 09:35
Aus meiner Sicht eine der besten Neuerungen in der Delphi-Language seit langer Zeit (zusammen mit den Generics)
Das For-in nicht zu vergessen.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
daywalker9

Registriert seit: 1. Jan 2010
Ort: Leer
594 Beiträge
 
Delphi XE3 Professional
 
#17

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 13:41
Delphi-Quellcode:
type
  TMyClass = class
    [ ListAttribute('SubPositions', TPositionInformation) ]
    property SubPositions : TObjectList<TPositionInformation> read FSubPositions write FSubPositions;
    [ ListAttribute('DatabaseVersions', TDatabaseVersion) ]
    property DatabaseVersions : TObjectList<TDatabaseVersion> read FDatabaseVersions write FDatabaseVersions;
    [ ListAttribute('ProductionUnits', TProductionUnit) ]
    property ProductionUnits : TObjectList<TProductionUnit> read FProductionUnits write FProductionUnits;
    [ ListAttribute('Segments', TPositionSegment) ]
    property Segments : TObjectList<TPositionSegment> read fSegments write FSegments;
   end;
Wobei man hier uch wieder von doppelten Informationen reden könnte.
TagName entpsricht ja dem Property-Namen, so daß man diesen Namen doch auch direkt verwenden könnte?
OK, an die Klasse in dem Generic ranzukommen ist nicht so einfach, aber Möglich wäre es bestimmt auch.
Das supported Delphi aktuell ja leider nicht
Lars
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
1.835 Beiträge
 
Delphi 2009 Professional
 
#18

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 30. Jan 2012, 15:36

Aus meiner Sicht eine der besten Neuerungen in der Delphi-Language seit langer Zeit (zusammen mit den Generics)
Schade nur, dass Attributdefinitionen nicht einschränken können, auf welche Codeteile das Attribut angewendet werden darf. Man kann ein Attribut daher fast überall dort hinsetzen, wo man auch einen Kommentar setzen könnte

Oder ist das bei XE2 eventuell ergänzt worden, dass so etwas wie @Scope ElementType.FIELD auch in Delphi geht:

Meta-Annotationen, Sichtbarkeit, annotierbare Programmelemente
Michael Justin
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
27.746 Beiträge
 
Delphi XE3 Professional
 
#19

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 31. Jan 2012, 09:06
Überall?

Ich kenn viele Stellen, wo ich Kommentare machen kann, aber keine Attribute.


Das geht immer nur vor irgendwelchen Deklarationen, wozu es eine RTTI gibt und scheinbar auch bei Variablen und Prozeduren.
Auch wenn ich jetzt nicht wüßte, wie man an deren RTTI rankommt, bzw. daß sie überhaupt eine haben. Aber da die neue RTTI rießig ist und dort jeder mögliche Scheiß drinsteht, könnte ich auch glauben, daß sich dazu auch 'ne RTTI finden ließe.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (31. Jan 2012 um 09:09 Uhr)
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
1.835 Beiträge
 
Delphi 2009 Professional
 
#20

AW: Rätselhaftes Konstrukt in Unit Dialogs

  Alt 31. Jan 2012, 09:40
Überall?

Ich kenn viele Stellen, wo ich Kommentare machen kann, aber keine Attribute.


Das geht immer nur vor irgendwelchen Deklarationen, wozu es eine RTTI gibt und scheinbar auch bei Variablen und Prozeduren.
Auch wenn ich jetzt nicht wüßte, wie man an deren RTTI rankommt, bzw. daß sie überhaupt eine haben. Aber da die neue RTTI rießig ist und dort jeder mögliche Scheiß drinsteht, könnte ich auch glauben, daß sich dazu auch 'ne RTTI finden ließe.
Ja, so war das auch gemeint - an sehr vielen Stellen können Attribute platziert werden (es ist leider nicht genau dokumentiert, man kann es aber durch Trial & Error herausfinden).

Hier ist eine Stackoverflow Frage und eine Aufstellung möglicher Einsatzorte:

Which language elements can be annotated using attributes language feature of Delphi?

Genannt werden:

Enums
Function type
Procedure type
Event type (closure, procedure of object)
Aliased type
Record type
Class type
Record type that's internal to a class
Record field
Record method
Class instance field
Class class field (class var)
Class method
Global variable
Global function
Local variable



Doch RTTI ist ja schon einen Schritt zu spät. Was ich meinte bezieht sich auf den Zeitpunkt des Compilierens, bevor RTTI erzeugt wird. Man kann in Delphi nicht angeben, dass ein selbst definiertes Attribut ausschliesslich an bestimmten Quelltextelementen wie Properties erlaubt ist - so dass Anwender des Attributes beim Versuch, es z.B. vor einer Klassendefinition oder einem Parameter zu verwenden, einen Compilerfehler erhält.

Der Zweck ist offensichtlich, falsche Verwendung eines Attributes zu verhindern. In Delphi kann man erst zur Laufzeit, per RTTI, erkennen ob ein Attribut auch da steht, wo es bestimmungsgemäß hingehört.
Michael Justin

Geändert von mjustin (31. Jan 2012 um 09:55 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2014 by Daniel R. Wolf