Forenbeiträge von Peter Bucher Ingesamt 5.942 Beiträge
Salute
Wie schaffe ich es, das meine Click-Methoden vor dem Page_Load ausgeführt werden?
Gar nicht, der Lebenszyklus ist festgelegt.
Du musst einfach den Code, der von den Änderungen in deinen Click-Handlers betroffen ist, in Page_PreRender bzw. OnPreRender verschieben, das wird nach allen Buttons ausgeführt.
Gruss Peter
Salute stoepsel007
Wird schon funktionieren, nur wird der Wert wohl überschrieben:
Gruss Peter
Hallo #coder#
So ähnliche:
Gruss Peter
Salute Maddinel
Nutze dazu Sessions und die Events Session_Start / Session_End.
Darüber kannst du Benutzer auch eindeutig identifizierien.
Gruss Peter
Hallo LuckyStrike
Kannst du so machen, es gibt x Möglichkeiten.
Ich nutze eine erweiterte Version von einem Control:
So kannst du bspw. Datenquellen wie eine Sitemap ansteuern und auch Bäume verarbeiten.
Kommt darauf an, wie komplex du es brauchst.
Gruss Peter
Hallo zusammen
@Tarion & winSharp93
Service Locator oder Dependency Injection unterscheidet sich nicht durch Singleton oder nicht Singleton.
Die Unterscheidung liegt in der Anwendung, Service Locator explizit und Dependency Injection implizit.
@All
Golo hat das gut beschrieben:
Gruss Peter
Hallo Tom
Im Regelfall benötigst du auch pro Anwendung nur einen Container.
Erkläre mir doch bitte mal, wozu so etwas nötig ist?
Gruss Peter
Hallo Alex
Eigentlich müsste LightCore 1.0 schon in der Lage sein, nicht registrierte Typen selber zu erzeugen und Konstruktor Injection automatisch auszuführen.
Gruss Peter
Hallo Markus
Wie sieht deine Aufgabenstellung aus?
Die Stichworte hast du ja, wo liegt das Problem?
Auf Englisch wirst du um einiges mehr finden als auf Deutsch.
Was soll gut oder schlecht sein?
Gruss Peter
Hallo zusammen
Die Klasse "Control" hat eine Referenz auf die aktuelle Seite. Und diese hat eine Eigenschaft Namens "Header".
Dort könnt ihr dann ein Link-Tag einfügen.
Gruss Peter
Hallo edsplash
Du kannst folgendes im Konstruktor eines Mappings nutzen:
Not.LazyLoad();
So musst und darfst du gar nichts in diesem Mapping virtuell machen.
Alles oder nichts 😉.
Gruss Peter
Salute Maddinel
Keine optimale Lösung, aber du kannst serverseitig das Webbrowser Control (unsichtbar im Hintergrund) nutzen, um die Screenshoots zu machen.
Gruss Peter
Salute zusammen
Die Handler können auch beim laden der Seite zur Laufzeit (ohne Dekleration) an Elemente gebunden werden.
Gruss Peter
Hallo zusammen
Man sollte diese aber nicht unbedingt verwenden. Ich würde bei überladenen Methoden bleiben.
Ja, schaut dazu mal hier:
Gruss Peter
Salute Kani
Ich habe beide Beispiele angeguckt, ehrlich gesagt werde ich aber nicht wirklich schlau daraus.
Wenn ich den Sinn sehen würde, wäre es leichter.
Du hast internal-Deklerationen, eventuell ist es ja möglich, die Interfaces zusammenzufassen, also eins drüberzulegen.
Je nach dem kann eine Komponente dann auch als Strategy-Pattern im Interface deklariert sein.
Gruss Peter
Hallo serial
also die frage, kann man das pro control steuern?
Offensichtlich nicht. Du hast eine Menge Text ohne Anhaltspunkte, wie willst du da spezifisch auf ein Control reagieren?
Theoretisch könntest du die Bezeichner auslesen, also einen eigenen Parser schreiben, jedoch ist das unschön und aufwändig.
Du könntest dich in den Renderprozess einhängen, gibt aber auch viel Aufwand.
Was genau musst du den filtern, was du nicht vorher (Daten) machen kannst?
Gruss Peter
Salute Kanti
Benutze folgende Xml-Registration:
<?xml version="1.0" encoding="utf-8"?>
<LightCoreConfiguration xmlns="clr-namespace:LightCore.Configuration;assembly=LightCore.Configuration">
<LightCoreConfiguration.Registrations>
<Registration ContractType="IDataAccess.IDataAccess, IDataAccess" ImplementationType="QM.DA.MySQL.CMySql, MySQL"/>
</LightCoreConfiguration.Registrations>
</LightCoreConfiguration>
Du solltest an deiner Namensgebung arbeiten. "IDataAccess.IDataAccess" ist nicht besonders schön.
Die Typbezeichnungen wurden falsch angegeben, folgendes Schema ist zu benutzen ".NET Standard":
<Namespace>.<TypeName>, <Assembly>
also bspw.
System.IDisposable, mscorlib
Gruss Peter
Hallo snupi
Generische Typparameter müssen bereits zur Kompilezeit feststehen.
Gruss Peter
Salute empty.at
Eine Übersicht über die gängigen Editoren findest du hier:
Gruss Peter
Salute serial
Response.Filter ist dazu geeignet.
Ein Beispiel findest du hier:
Gruss Peter
Salute Kanti
Entweder hast du einen Schreibfehler im Xml oder - was wahrscheinlicher ist - fehlt die Datei im BIN-Verzeichnis.
Prüfe das bitte mal nach.
Gruss Peter
Hallo Kani
Das ist gar nicht umsetzbar per Xml.
Ehrlich gesagt sehe ich jetzt auch nicht ein, wofür das gut sein soll.
Gruss Peter
Salute Kani
Das wurde hier diskutiert:
Wenn du das richtig anwendest, also die Konstruktoren gleich hältst, bzw. die zusätzlichen Argumente, passt das.
Gruss Peter
Hoi Rene
Bin gespannt darauf zu erfahren, in welche Richtung Deine Überlegungen gehen und wie weit die aktuelle Entwicklung bereits ist. Könntest Du da mal einen kompilierbaren Zwischenstand im SVN einchecken?
Mein Zwischenstand mit Argumenten zur Laufzeit ist jetzt im SVN (Link unter: http://lightcore.peterbucher.ch/download.aspx) eingecheckt.
Schau es dir mal an, ich würde mich über Feedback freuen.
Grüsse aus Luzern, Peter
Salute der-schlingel
Ich habe mir ein eigenes Shortcut dafür angelegt:
Gruss Peter
Salute zusammen
Du kannst - in der nächsten Version noch verbessert - auch ohne Probleme Argumente übegeben.
Aber Factories lassen sich dadurch natürlich nicht komplett ersetzen.
Eine Lösung ohne direkten Cast wäre bspw.:
using System;
using System.IO;
using System.Text;
using LightCore;
namespace CustomTextWriterTest
{
class Program
{
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.Register<TextWriter, StringWriter>();
builder.Register<ICustomTextWriter, CustomTextWriter>();
var container = builder.Build();
var customTextWriterConsumer = container.Resolve<CustomWriterConsumer>();
var thirdPartyTextWriterConsumer = container.Resolve<ThirdPartyCustomWriterConsumer>();
Console.Read();
}
}
// Framework: e.g. StringWriter.
public interface ICustomTextWriter
{
TextWriter TextWriter { get; }
}
public class CustomTextWriter : TextWriter, ICustomTextWriter
{
public override Encoding Encoding
{
get
{
return Encoding.Default;
}
}
public TextWriter TextWriter
{
get
{
return this;
}
}
}
public class CustomWriterConsumer
{
public TextWriter TextWriter { get; set; }
public CustomWriterConsumer(TextWriter textWriter)
{
this.TextWriter = textWriter;
}
}
public class ThirdPartyCustomWriterConsumer
{
public TextWriter TextWriter { get; set; }
public ThirdPartyCustomWriterConsumer(ICustomTextWriter customTextWriter)
{
this.TextWriter = customTextWriter.TextWriter;
}
}
}
Gruss Peter
Salute OcchiX
Ist das nur eine einzelne Html-Seite?
Wenn ja, kann der Weg über das dynamische Laden (Beispiel von Martin) gut funktionieren.
Du musst einfach nur den Inhalt von <body> bis </body> nehmen, was du durch String-Parsing oder RegEx erledigen kannst.
Du kannst es auch per IFrame machen, wenn du noch Bild- / CSS-Referenzen drin hast, damit die nicht kaputt gehen.
Um das zu bewerkstelligen packst du die statischen Seite in einen geschützten Bereich, wo nur ASP.NET Zugriff hat, bspw. App_Data.
Dann brauchst du einen HttpHandler um die Daten per IFrame Aufruf laden kannst. Du gibst also die Adresse zu deinem Handler im IFrame an.
Authentifizierung kannst du dann direkt im HttpHandler prüfen, mit deinen schon zur Verfügung stehenden Möglichkeiten.
Da du ziemlich sicher den SessionState dazu brauchst, musst du das Interface IRequiresSessionState (Oder die readonly Variante) im Handler implementieren.
Siehe dazu auch:
Gruss Peter
Hallo winSharp93
Ich denke das ich deinen Gedankengängen folgen kann.
Wenn du mit einem IoC-Container und Laufzeitargumenten arbeitest, gibt es IMHO zwei Fälle:
Entweder fixierst du dich wirklich nur auf einen konkreten Typen und übergibts so die Argumente. Das ist natürlich schlecht und der Container bringt nicht viel mehr als eine vorhersehbare Factory.
Jede Implementation zu einem Kontrakt hat gleiche Konstruktorargumente, zumindest zum Teil.
D.h. es wird bspw. immer ein String "configurationPath" erwartet, danach, vorher oder dazwischen können noch andere registrierte Abhängigkeiten folgen, jedoch ist dieses Argument in jeder möglichen Implementation drin.
Auf diese Art der Nutzung bist du wieder total unabhängig.
Aber die Geschichte ist natürlich implizit und dein Vorschlag wäre halt, das explizit zu machen.
Ich weiss nicht ob das Sinn macht, wegen oben genannten Gründen.
Wenn dann als zusätzlich Option, aber das bläht alles wieder auf.
Wenn man also mit dem richtigen Gedanken dran geht, sind die Laufzeitargumente IMHO wirklich legitim.
Evt. hat Golo das mit dem Syntaktischen Template gemeint, eben die implizite Vorgabe im Konstruktor für alle Möglichen Implementationen.
Gruss Peter
Salute Kani
TextWriter ist abstrakt, also kannst du doch deinen auf diese abstrakte Klasse registrieren.
Oder du implementierst noch ein Interface in deiner eigenen Implementation und registrierst darauf, wenn du das andere sonstwo noch brauchst.
Ein DI-Container kann theoretisch alle Factories ablösen, aber manchmal macht es trotzdem Sinn noch Factories zu schreiben.
Per Delegate-Registration kannst du auch eine Factory aufrufen, die eine Instanz liefert.
Gruss Peter
Salute Kani
Ab der nächsten Version von LightCore werden benannte Registrierungen (WithName) nicht mehr unterstützt, siehe:
Du kannst dein Problem aber relativ einfach lösen.
Gegeben sei folgendes:
public interface ITextWriter {}
public interface ISpecialTextWriter {}
public interface ISpecialTextWriterDependency {}
Und wenn du den SpecialTextWriter auch als normaler TextWriter nutzen willst, machst du folgendes:
public interface ISpecialTextWriter : ITextWriter {}
Du registrierst dann so:
builder.Register<ITextWriter, DefaultTextWriter>();
builder.Register<ISpecialTextWriterDependency, SpecialTextWriterDependency>();
builder.Register<ISpecialTextWriter, SpecialTextWriter>();
Und auflösen:
container.Resolve<ITextWriter>();
container.Resolve<ISpecialTextWriter>();
So gibst du explizit an was du möchtest und brauchst dich nicht selber direkt um die Abhängigkeit kümmern.
Die Registrierungen kannst du auch so in der Xml-Konfiguration hinterlegen.
Gruss Peter
Hallo winSharp93
Ich würde jetzt einfach mal davon ausgehen, das der Benutzer des Interfaces weiss, wie die Implementation auszusehen hat.
Du hast schon Recht mit der Unabhängigkeit, allerdings hast du mit einem expliziten Ansatz ein Zwang zur Angaben von Parametern.
Wenn du bspw. auf einen anderne Container umsteigst, kannst du erst mal deine komplette Codebase ändern, wegen den ganzen Attributen.
Ich finde das zu viel Aufwand für einen künstlichen Kontrakt, bzw. ich denke das ist für andere zuviel Aufwand.
Gruss Peter
Hallo winSharp83
Leider ist in den alten Versionen der DI-Container noch Singleton als Standard definiert. In den neuen ist es meistens Transient, also das du standardmässig jedesmal eine neuen Instanz erhältst.
Ich finde das auch besser so.
Die Geschichte mit den Argumenten finde ich zu umständlich, zumal du im Container auch einen guten Algorithmus finden kannst, der die Parameter so zusammensetzt, wie es nötig ist.
In der neuen Version von LightCore ist das mit Argumenten und Laufzeitargumenten gelöst, wobei die Laufzeitargumente höher priorisiert sind.
Das funktioniert eigentlich wunderbar 😃
Gruss Peter
Hallo malignate
Leider immer unsigniert, das geht mir bisschen auf die Nerven, aber das ist ein anderes Thema...
Was meinst du jetzt damit, CSL? LightCore gibt es signiert.
Gruss Peter
Hallo Alex
Ich habe mal mit dem Reflektor in die LightCore.dll reingeschnüffelt, scheint so als ob der LC-Container dieses Interface nicht implementiert.
Das müsste der aber doch, damit man diese Flexibilität des Containeraustausches nutzen kann, oder habe ich da wieder was falsch verstanden?
LightCore stellt eine Implementierung des CSL-Interfaces bereit, jedoch in einer seperaten Assembly.
Gruss Peter
Hallo Rene
ich wollte mich nur nochmals erkundigen, ob man in der näheren Zukunft (irgendwann im April 2010) mit einem Release rechnen kann, wo das mit den Construktor-Parametern drin ist?
Ja, die nächste Version lässt nicht mehr lange auf sich warten,
in deinen Zeitrahmen passts sicher 😃.
Hast Du dir in diesem Zusammenhang mal überlegt, was mit Parametern geschieht, die (benannt) als Constructor-Parameter übergeben werden, für die es aber auch bereits "Dependency"-Parameter (also registrierte Typen) gibt, die LightCore in diesem Fall einfach injizieren könnte? Würde in solch einem Fall der übergebene Parameter verwendet, also höher priorisiert?
In diesem Fall wird der übergebene Parameter höher priorisiert.
Bin gespannt darauf zu erfahren, in welche Richtung Deine Überlegungen gehen und wie weit die aktuelle Entwicklung bereits ist. Könntest Du da mal einen kompilierbaren Zwischenstand im SVN einchecken?
Nimm einfach mal mit mir Kontakt auf. Am besten über das Kontaktformular auf meiner Webseite (http://peterbucher.ch/kontakt.aspx).
Gruss Peter
Hallo ZeroQool
Im "Team Explorer" gibt es die Ordner "Documents", etc.... Dort kannst du die Dokumente hinterlegen.
Gruss Peter
Salute Jack_AI
Du brauchst nur Argumente per GET oder POST zu übergeben und darauf im Handler zu reagieren.
Also sowas wie: Download.ashx?param1=value1
Gruss Peter
Hallo Curse4Life
Nein, meines Wissens nicht.
Du brauchst die fertig kompilierten Assemblies, vorher bist du immer noch auf der älteren Version.
Du könntest höchstens das Projekt plus eventuelle Abhängigkeiten einzeln builden, das sollte auch passen.
Siehe:
Gruss Peter
Salute Vertexwahn
Das nächste Mal auf http://www.peterbucher.ch/links.aspx unter "Strings formatieren mit C#".
Gruss Peter
Hallo zusammen
@Renè
Vielen Dank für deine motivierenden Kommentare 😃.
Die Version im SVN ist zwar neuer als das Release, aber die Arbeiten mit Konstruktorparametern zur Auflösungszeit sind bisher nur lokal bei mir vorhanden.
Ich werde es von der API ähnlich umsetzen, wie Golo das vorgeschlagen hat.
@Alex
Das geht schon, per Delegate. Also indirekt:
ContainerBuilder builder = new ContainerBuilder();
builder.Register(c => new object());
var container = builder.Build();
object instance = container.Resolve<object>();
Im Beispiel selber siehst du auch, das ich eine nicht abstrakte Klasse / nicht Interface registriere, also einen Typ auf sich selber registriere.
Das kannst du natürlich nur mit verschiedenen Typen machen, daher würde sich sowas ähnliches wie IConfigurationData anbieten, wobei die eine Implementation gemockt - für Testzwecke - da sein könnte und die andere für den normalen Ablauf.
Dabei müsste der Lifecycle auf "TransientLifecycle" stehen, was der Standard in LightCore ist. Damit wird jedesmal einfach auf die übergebene Instanz zugegriffen.
Gruss Peter
Salute freundblase
Du suchst wohl "internal".
Damit kannst du innerhalb deines Projektes alles verwenden, aber ausserhalb ist es nicht sichtbar.
Ob das nicht noch besser gelöst werden kann, ist ohne Details schwer zu sagen.
Gruss Peter
Hallo Uwe
So schmal wie möglich, so gross wie nötig.
Schlussendlich ist es Gefühlssache. Ich würde IsDisabled oder IsEnabled benutzen, nicht beides, ausser eines könnte oder müsste jetzt oder später anders implementiert werden.
Gruss Peter
Salute MarsStein
Ersteres, also die Databinding Expressions für etwas missbrauchen, wofür sie nicht gedacht sind.
Es gibt sowieso nur Probleme, da der Zeitraum der Ausführung meistens nicht wirklich passt.
Ansonsten einfach den Group-Beitrag lesen.
Gruss Peter
Hallo zusammen
Das sollte aber nicht benutzt werden, Erklärung findest sich bspw. hier:
Gruss Peter
Hallo zusammen
Also ich bin ja schon ein bisschen geschockt was ich in diesem Thread teilweise lesen muss.
Var wurde nur wegen den anonymen Typen eingeführt oder evt. noch für eine möglichkeit Abkürzung bei IEnumerable<T>-Typen. Sicher nicht um den Schreibaufwand zu minimieren oder eine dynamische Typisierung vorzutäuschen.
Eine unbedachte Nutzung birgt einige Risiken, siehe auch:
Dynamic auf der anderen Seite ist noch ein heikleres Thema. Ich bin auch nicht wirklich glücklich das es eingeführt wurde. Dies allerdings vorallem weil es so ein hohes Missbrauchspotential hat.
Dynamic wurde ausschliesslich für eine bessere Interoperabilität eingeführt. Also bspw. das hantieren mit COM-Komponenten, die mit normalem Code extrem umständlich wären. Oder halt die Zusammenarbeit mit dynamischen Sprachen / DLR, etc.
Gruss Peter
Salute darvin1982
Du hast ein IEnumerable<XElement>, also musst du das auch als solches behandeln.
Also die Liste durchgehen, oder eine Konvertierungsfunktion darüber laufen lassen => Func<IEnumerable<XElement>, string>.
Gruss Peter
Salute Champ88
Es wäre sehr hilfreich wenn du uns an dem Problem und dessen Lösung beteiligen würdest, danke.
Gruss Peter