| |
|
|
Sebastian König | allô zusammen,
einer spontanen concept folgend habe je avant un paire Tagen avec qui travail à einem neuen projet begonnen: un Parser, qui qui Struktur eines (X)Profan-Projekts (d.h. eingebundene Include-, En-tête-, et Unit-Fichiers, enthaltene Prozeduren usw.) dans einer banque de données speichert. cet banque de données soll ensuite dans un Dossier geschrieben volonté - et oui c'est ca à cette Stelle liegt qui Grund pour mon Posting ici:
je serait pour cela Format cette Fichiers gern une einheitlichen Standard créer. et là je cette naturellement pas seul bestimmen voudrais (aussi si cet Praxis dans qui IT-Branche pas unüblich ist ), serait je cela Format gern ici diskutieren (quelques konkrete Vorstellungen habe je déjà, mais en supplément später plus).
Erstmal mon Hauptfrage: quoi haltet son grundsätzlich de dem projet, une solchen Standard trop créer?
et speziell à iF: XPSE écrit oui pour Unités oui déjà quelques Infos dans .def-Fichiers. Wärst Du bereit, ici zusätzlich cela neue Format trop soutien?
Geplant ist cela projet, le moi vorläufig XPDB genannt habe (pour XProfan Program Database - comme mir eigentlich pas mal, pourrait sich mais, si quelqu'un et avec ca besseres envahir sollte, encore changement, um pas unnötig zur inflation qui 4-Buchstaben-XP-Namen beizutragen ) vornehmlich comme Software Development Kit, alors comme la base pour weitere Projekte. So soll es sur jeden le cas une DLL donner, qui aussi dans XProfan bequem nutzbar ist, et chez intérêt peux je aussi gern statische Bibliotheken zur Nutzung avec C/C++- ou bien Assembler-Codes zur Disposition se mettre. aussi un rudimentärer GUI-Browser pour qui Strukturen soll partie des Pakets volonté. mais là ici wirklich pas qui Schwerpunkt de meiner page aus liegen soll, wäre un plus beau Browser avec vielen Features un erster Vorschlag pour un projet, cela quelqu'un dans XProfan écrivons pourrait...
So, cela suffisant erstmal - je suis mich sur Meinungen et Anregungen trop dem Thema!
MfG
Sebastian |
|
|
| |
|
|
|
| aussi si pour XProfan unüblich - so wäre XML wohl cela Passenste. je erinnere mich (pour et dans) XProfan aussi déjà une XML-Parser geschrieben trop avons - seulement à qui Performance vermag je mich pas trop erinnern.
Vlt. wäre un simples TXT ala:
| | root _file_typ_item _file_typ_item_additionalInfos |
einfacher trop handhaben.
XPDB klingt bien, et naturellement peux je mir présenter cela XPSE un XPDBF utilise, mais aussi XIDE pour den Projektexplorer. |
|
|
| |
|
|
|
Sebastian König | Salut,
garnicht so simple, sich de einem Linux-System aus avec Iceweasel einzuloggen... mon FastLogin-Link funktionierte irgendwie pas, sodass je mir seulement un nouveau Mot de passe besorgen musste...
iF
aussi si pour XProfan unüblich - so wäre XML wohl cela Passenste. je erinnere mich (pour et dans) XProfan aussi déjà une XML-Parser geschrieben trop avons - seulement à qui Performance vermag je mich pas trop erinnern.
XML était dans qui acte aussi mon erster idée et qui aktuelle XPDB-Arbeitsversion erzeugt qui Ausgabe déjà dans diesem Format (je voulais seulement dans mon ersten Posting trop dem Thema encore pas trop ins Detail aller et erstmal allgemeine Meinungen trop dem Thema einholen...). si je après zuhause suis, werde je la fois une Beispiel-Ausgabe, comment je vous mir jusqu'à maintenant vorstelle, posten. qui Geschwindigkeit des Parsers sollte ne...aucune Problem son, denke je. Aussi wird une Funktion zum Einlesen qui Fichiers aussi partie des Projekts son, sodass es garnicht absolument nötig son wird, une eigenen Parser trop écrivons (mais naturellement possible, là cela Format oui offengelegt et bien dokumentiert volonté soll).
iF
XPDB klingt bien, et naturellement peux je mir présenter cela XPSE un XPDBF utilise, mais aussi XIDE pour den Projektexplorer. oui, mir comme qui nom aussi! si aussi qui XIDE cela Format nutzen serait, wäre cela naturellement super!
MfG
Sebastian |
|
|
| |
|
|
|
H.Brill | oui, XML wäre aussi pour mich convenable, là cet Format aussi très bekannt ist. justement pour diejenigen (aussi je), qui avec mehreren Programmiersprachen travailler, bietet sich cela à. |
|
|
| Benutze XPROFAN X3 + FREEPROFAN Wir sind die XProfaner. Sie werden von uns assimiliert. Widerstand ist zwecklos! Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.
Was die Borg können, können wir schon lange. | 11.09.2007 ▲ |
|
|
|
|
Sebastian König | So, ici Alors, comment versprochen plus Informationen:
comment déjà erwähnt, ist qui Speicherung im XML-Format qui de mir favourisierte et bereits implementierte variante. un avec qui aktuellen XPDB-Version erzeugtes Beispiel habe je unten angehängt (réellement volonté aussi déjà Informationen trop Prozeduren gespeichert, mais cela habe je zur besseren Übersichtlichkeit ici la fois weggelassen...)
Wahrscheinlich ist qui Code so déjà très simple trop comprendre, mais quand même un paire Anmerkungen:- chaque gespeicherte Element est un object - cela ergab sich entier direct aus meiner internen Klassen-Hierarchie.
- Um quoi oui c'est ca es sich handelt, steht im Attribut type, so gilt zum Beispiel 1=Include-Dossier, 2=Header usw.
- quoi dans nom steht ist im Grunde beliebig, sollte sich mais dans qui règle automatisch aus dem analysierten Code ergeben
- cela Attribut id sollte dedans chacun Dossier sans équivoque son.
près de qui Voraussetzung, dass es sich um gültiges et wohlgeformtes XML agir muss, serait je zusätzlich folgende Bedingungen à den Aufbau proposer:- qui Attribute type, id et nom sommes Pflichtangaben pour chaque objet, qui Angabe parent im Grunde aussi, seulement pas pour qui Hauptdatei des analysierten Codes
- Objekte, sur qui sich irgendwo bezogen wird (zum Beispiel im parent-Attribut), doit dans qui Dossier VOR qui Referenzierung stehen. (avec cela wird vermieden, dass on den Code per Multi-Pass-procéder parsen ou bien Referenzen später ermitteln muss. dans qui règle sollte l'état chez qui sequentiellen Analyse eines Projekts automatisch erfüllt son, mais zur Not pourrait on es aussi sans grand Aufwand beim Sauver qui XML-Dossier sicherstellen.)
- qui ID-Zählung muss dedans chacun Dossier chez 1 commencer. (cela erleichtert ggf. cela Zusammenfügen de Datenbanken.)
Zusätzlich le (devoir-)Attributen, qui direct im < object > -journée stehen, peut dépendant vom Typ aussi weitere Informationen gespeichert werden; je nenne cet ensuite Werte. un Beispiel wäre level pour Include-Fichiers, cela qui Verschachtelungstiefe angibt. aussi ici pourrait on dépendant vom Typ Pflichtangaben verlangen.
Generell finde je, dass so wenige Angaben comment possible zur devoir erklärt volonté devrait, à Verwendungsmöglichkeiten qui banque de données-Fichiers très allgemein rester. si on zum Beispiel simple seulement qui de einer Unit exportierten Prozeduren décrire voudrais, ist cela Attribut line sûrement pas allzu sinnvoll...
Ok, soviel erstmal trop meinen bisherigen Gedanken... gibt es en supplément soweit Meinungen, Anregungen ou bien Einsprüche?
MfG
Sebastian avec XPDB erzeugter Beispiel-Code: KompilierenMarqueSéparation |
|
|
| |
|
|
|
| Feste Pfadangaben dans einem XPDBF? Es fehlt aussi un paramètre URL, somit pourrait on projektabhängige Fichiers décrire quelle bistrot garnicht sur Platte sommes - bzw. Comprend et Unités décrire quelle vom Importer arrêt seulement geladen würden... (J'ai eu pour XIDE eh angeplant) |
|
|
| |
|
|
|
| Nachtrag: je serait aussi juste pour dem En-tête pas avec den Objekten commencer, ici fehlt une weitere Kapselung. |
|
|
| |
|
|
|
Michael Wodrich | Sieht bien aus et ist verständlich.
pas so comment qui Delphi et VB Projektdateien, wohin on pas la fois MIT Handbuch durchsteigt.
XML-NotePad freut sich aussi sur cela Format.
belle Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 11.09.2007 ▲ |
|
|
|
|
Frank Abbing | peux du s'il te plaît la fois genauer expliquer, wofür cet Fichiers am Ende sinnvoll sommes? |
|
|
| |
|
|
|
Sebastian König | qui bisherige Zustimmung zum XML-Format freut mich erstmal!
iF
Feste Pfadangaben dans einem XPDBF? Es fehlt aussi un paramètre URL, somit pourrait on projektabhängige Fichiers décrire quelle bistrot garnicht sur Platte sommes - bzw. Comprend et Unités décrire quelle vom Importer arrêt seulement geladen würden... (J'ai eu pour XIDE eh angeplant)
Avec l' den Pfadangaben habe je erstmal vorläufig so gemacht... ist wahrscheinlich wirklich pas toujours sinnvoll. je pourrait mir bien présenter, ici par une Angabe im En-tête (absolute,relative,none) plusieurs Opportunités zuzulassen.
aussi une optionnel URL-Angabe im En-tête ist une gute concept.
iF
Nachtrag: je serait aussi juste pour dem En-tête pas avec den Objekten commencer, ici fehlt une weitere Kapselung.
Stimmt - werde je einbauen.
EDIT: quoi stimmt car ici avec den Zitaten pas? |
|
|
| |
|
|
|
| qui URL bezog sich plutôt sur un Dateiobjekt.
avec den Quotes ist alles IO, Du hattest seulement derrière einem quote-part (et avant dem Gleichzeichen) un Freizeichen avec incorporé, et [quote-part = blub] gibt es pas quoi iFBB im Bezug aufs quote-part zum débrancher zwang.
@Frank: je pourrait Dir une solche XML donner - tu ouvres cet dans XIDE - XIDE läd et ordnet alle Fichiers des Projektes à qui richtige Stelle. Solch une Dossier beschreibt z.B. Aufenthaltsorte de Projektzugehörigen Fichiers et Einstellungen. cela doit wir XIDE zwar encore beibringen, mais je denke vom ASM-Core her gibts là rien nouveau hinzuzufügen - soll heissen - alles sur Plgs possible.
je hatte oui so ou bien so avant oui c'est ca cet Fonctionnalité dans qui XIDE hineinzukatapultieren - Stichworte projet-Assistent/Explorer - vlt. nimmt Sebastian uns dabei quelque chose travail ab. (vorausgesetzt son Parser zuckt pas chez XPSE-Codes et versteht cet aussi que normale XCodes.) |
|
|
| |
|
|
|
Sebastian König | Frank Abbing
peux du s'il te plaît la fois genauer expliquer, wofür cet Fichiers am Ende sinnvoll sommes?
Zum Beispiel zur Beschreibung de Unit-Inhalten. Zugegeben, ici gibt es déjà cela bereits erwähnte .def-Format vom XPSE, mais un flexibles, allgemein unterstütztes Format halte je irgendwie pour une gute concept.
mon ursprünglicher plan était, simple une Browser pour qui Struktur de XProfan-Projekten trop écrivons - comme je puis kam, dass on qui ermittelten Informationen aussi Sauver peut sollte (um pas toujours den ganzen Code parsen trop doit), verlagerte Je l' Schwerpunkt des Projekts sur cela Dateiformat. Irgendwie me plaisait qui concept... qui ist naturellement pas récente! un un peu wurde je aussi de den Browse-Informationen, qui mon Visual C++ generiert, inspiriert.
cela bringt mich juste zum prochain Punkt, den aussi iF déjà angesprochen hat: XIDE pourrait cela Format nutzen, um Informationen trop Projekten trop Sauver. Beim Öffnen eines Projekts pourrait ensuite très vite qui Struktur lire volonté, sans dass qui ganze Code einmal gelesen volonté muss. chez Changements muss ensuite seulement qui banque de données im grenier aktualisiert volonté et beim Schließen des Projekts wird alles wieder dans qui Dossier geschrieben. Voraussetzung pour cet Anwendung ist naturellement, dass un solcher projet-Browser partie qui IDE son soll... (Informationen en supplément gibt es oui bisher à peine)
aussi Zusatzprogramme comment zum Beispiel Debugger könnten peut-être de einer solchen projet-banque de données profitieren... |
|
|
| |
|
|