enki-devel — Developers of the library.

Re: [Enki-devel] Enki und Ikne Ideen

[Patrick R. <bu...@an...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=20
Hallo zusammen,

> Hier die Ideen zu Enki:
>
> *Codestruktur* Ein weiteres Thema ist die Struktur von Enki. Ich
> finde es sollte so etwas wie packages geben, da man sicher nicht
> alle Elemente fuer jede Webseite benoetigt. Ich stelle mir hier ein
> Grundpackage mit den unabdingbaren Elementen vor, sowie
> weitergehende Packages mit Erweiterungen (z.b. Isomap). Diese
> koennen sicher auch Klassen des originalpackages um Funktionen
> ergaenzen.
>
Packages t=F6nt ansich sinnvoll, die Frage ist wie man's implementieren
will. Im Produktiven Betrieb sollte die Anzahl der zu ladenden Dateien
m=F6glichst klein sein, da jede zus=E4tzliche Datei, welche geladen werde=
n
muss ein recht grosser Overhead bedeutet. Wenn wir eine feine
Abstufung der Packages machen m=F6chten, denke ich sollten wir das so
machen, dass man sich seine Version "compiliert (mit ikne)" und dann
am Ende einfach diese Datei einsetzt, welche genau die gew=FCnschten
Dinge beinhaltet. Damit sind wir extrem flexibel, jedoch ohne
Performance zu verlieren. Der Nachteil dabei ist, dass es aufwendiger
ist um es einzusetzten, jedoch kann man das wahrscheinlich auch so
machen, dass man einfach 2 oder 3 "Standartpakete" (Minimal, Standart,
Alles) anbietet, welche direkt eingesetzt werden k=F6nnen.

> Wie wir schon gesehen haben, wird Enki zu gross, was das Volumen
> der Dateien angeht. Sicherlich erwarten wir nicht, dass ein thick
> client in einer Sekunde laed, aber mit groesserem Funktionsumfang
> wird Enki uns volumenmaessig ueber den Kopf wachsen. Ich halte es
> deshalb fuer unabdingbar, dass Ikne nicht nur den Code optimiert,
> sondern auch fuer eine deutliche Reduktion des Volumens durch
> Umbennenung sorgt.

Generell sehe ich das eigentlich weniger als ein Problem an. Die reine
Volumenmenge ist (da's eh nur Text ist) relativ gering (eine einzige
Grafik ist oft schon gr=F6sser als der komplette Enki Code). Es ist auch
ohne weiteres m=F6glich mod_gzip auf dem Server einzusetzten und damit
die Datenmenge noch massiv zu veringern.
Optimierungen vom Quelltext sind immer so eine Sache, man muss
aufpassen, dass man's nicht =FCbertreibt und am Ende in einer Situation
ist, wo man extrem viel Aufwand f=FCr einen sehr geringen Nutzen
reinsteckt. Der gr=F6sste Optimierungsnutzten sehe ich beim entfernen
der Kommentare. Whitespaces bringen auch noch etwas. Umbenennen und
=E4hnliches bringen zwar auch noch ein wenig etwas, ich sch=E4tze aber,
dass da der Nutzen in keinem Ausmass zum Ertrag steht. Auf jeden Fall
sollte man vorher mal einen Quelltext nehmen und schauen wieviel man
da rausholen kann.

> Dieses Thema ist nicht einfach, da es Vielerlei gibt, dass durch
> solch eine Umbennenung kaputt gehen kann. Hier ein paar Argumente
> und Vorschlaege mit Fuer und Wider:
>
> * Andere, nicht mitkompilierte Bestandteile der Seite werden nicht
> mehr auf Enkifunktionen und Variablen zugreifen koennen. In Enki
> sehe ich das Problem weniger: Hier wird fast jedes Projekt komplett
> in Enki geschrieben sein, und html elemente gibt es hier ohnehin
> nicht. Dennoch gibt es zwei Moeglichkeiten dieses Problem zu
> umgehen. Einmal kann man Ikne eine Liste mit zu schuetzenden Namen
> mitgeben. Dies waere dann codeunabhaengig, und vermutlich recht
> einfach zu erledigen; es waere ausserdem eine gute Moeglichkeit,
> die in ergulaerem JS enthaltenen Funktionen zu schuetzen.
> Alternativ, und auf lange Sicht vermutlich sinnvoller, waere ein
> keyword im code selber, den entsprechenden Definitionen
> vorangestellt. Vorstellbar waeren hier eines der in JS zwar
> reservierten aber nicht genutzten Woerter wie "public" oder
> "protected". Beide Methoden koennen gut zusammen genutzt werden.
>
Ich finde es unsch=F6n ein "gesch=FCtztes" Keyword zu missbrauchen. Falls
JS mal erweitert werden sollte, so dass diese Keyw=F6rter verwendet
werden, gibt's Probleme. Ich w=FCrde da eine L=F6sung durch Kennzeichnung
im Namen bevorzugen. (z.B. k=F6nnten Variablen die mit __ beginnen nicht
umbenannt werden)

>
> * Rueckverfolgung und Zuordnung von Namen ist in JS recht
> schwierig. Prototypenfelder koennen gleich in zwei verschiedenen
> Weisen definiert werden ( proname['field'] =3D ''; oder proname.field
> =3D ''; ). Das wird insbesondere dann zum Problem, wenn man Felder
> wie druch die in Enki genutzte 'method' funktion definiert.
> Theoretisch kann man einem Objekt zur Laufzeit einen neuen
> Prototypen zuweisen, typing ist also hochdynamisch. Insgesamt ist
> dies das Feld, das mir am meisten Sorgen macht, von dem ich
> allerdings trotzdem denke, dass es loesbar ist. Es sollten schon
> entsprechende Methoden im Compilerbau existieren, die ich aber
> nicht kenne.
>
Sobald's zu dynamisch wird, l=E4sst sich das ganze meistens nicht mehr
sinnvoll l=F6sen. Bei den dynamischen F=E4llen ist's auch so, dass man
relativ bald zus=E4tzlichen Code zur Laufzeit ben=F6tigt und da sehe ich
den Overhead gr=F6sser als den eigentlichen Nutzen.

> Weitere Dinge, die ich mir fuer Ikne wuensche:
>
> * Umsetzung moeglichst vieler Anregungen von
> http://www.crockford.com/javascript/recommend.html zu einer Art
> extended JS ( XJS/IkneJS )

Hm, ich finde es eigentlich weniger sch=F6n eine "neue" Sprache
einzuf=FChren. Ich denke was man machen kann ist die Dinge, welche zwar
mit JS gehen, aber nicht "sch=F6n" sind, beim durchlaufen lassen als
Notices (abstellbar) anzuzeigen. Jedoch keine zus=E4tzlichen Dinge zu
erlauben, welche in normalem JS nicht m=F6glich sind.

Gruss Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
=20
iD8DBQFDfQIj3y5tALuHRTgRAnLkAJ44KmE3v2P36LYH/1RHpYO744HdlgCeORAg
ARbEpNa0qNI5nxBV9kw1DGA=3D
=3DKgHX
-----END PGP SIGNATURE-----

[Enki-devel] Ikne Probleme

[Aragos <ar...@ar...>]

Hoi,

bei ikne habe ich bisher zwei Fehler entdeckt, der schwerere ist, dass 
"instanceof" ein Operator ist, und nicht einfach als keyword genutzt 
werden kann. Durch die jetzige Implementierung wird aus (a instanceof b) 
  -> (instamceof b), was natuerlich falsch ist. Aehnlich vermutlich bei 
"typeof", habs aber nicht ausprobiert.
Wuerde gerne wissen, was man da machen soll, will ja auch selber dran 
arbeiten, aber gerade habe ich keine Ahnung und will nichts kaputtmachen. :)

Anderes "Problem" ist, dass "function" keinen following whitespace 
benoetigt, wenn eine "(" folgt. Vermutlich hilft hier ein weitere 
Sonderregel analog zum functiondot ... Denkbar waere auch eine etwas 
globalere Loesung, da der Fall ja auch auf andere keywords zutrifft. 
Genauer seh ich mir das morgen an.

Aragos

[Enki-devel] Enki und Ikne Ideen

[Aragos <ar...@ar...>]

Hoi Develer :)

Die vergangenen Wochen habe ich darueber gebruetet, was das Projekt 
brauchen koennte, wo Prioritaeten liegen sollten und was wir ueberhaupt 
machen koennen. Viele Ideen reichen weit in die Zukunft, und werden 
sicher erst in langer Zeit umgesetzt.
Ich versuche meine Vorschlaege fuer Enki und Ikne getrennt zu halten, 
soweit das geht.

Hier die Ideen zu Enki:

*Fenstermanagement*
Da Enki ein richtiger thick client werden soll, halte ich ein gutes 
Fenstermanagement fuer unabdingbar. Angelehnt an die gaengigen 
Betriebssystemoberflaechen sollte es grosse Freiheit und Intuitivitaet 
bringen, ohne zu stark die Performance zu druecken.
Hierfuer sollten wir zuerst definieren welche Moeglichkeiten wir 
anbieten moechten. Theoretisch ist alles vom klassischen minimieren, 
maximieren ueber resizing und bewegen bis zu opacity denkbar. Aus 
Performancegruenden halte ich aber erst einmal nur minimieren, 
maximieren und moeglicherweise bewegen fuer sinnvoll. Alles andere 
sollte nur in Ausnahmefaellen genutzt werden oder erst wenn eine 
performante Loesung dafuer existiert.
Bei minimieren/maximieren muessen dann natuerlich auch Verhaltensweisen 
definiert werden, insbesondere der Ort und das Aussehen der minimierten 
Version. Diese Definition sollte aber so variabel gehalten werden, dass 
webseitenspezifische Loesungen implementiert werden koennen.
Als letzten Punkt sollte es eine Moeglichkeit geben, fuer Fenster ein 
seitenspezifisches look&feel zu definieren.

*Verhaltensweisen*
Auch die Verhaltensweise der einzelnen (Container-)Elemente in Enki 
sollte Betrachtung erfahren. Ich habe versucht, ein moeglichst 
intuitives und trotzdem frei gestaltbares Framework zu schaffen. 
Dennosch sind mir selber noch Probleme bekannt ( Rundungsfehler bei 
Groessenberechnung z.b. ) und ich bin sehr sicher, dass ich selber nicht 
alles sehe.

*Zeichnen von unsichtbaren Elementen verhindern*
Wie Butcher richtig bemerkt hat, waere es von grossem Vorteil, nur Dinge 
in Enki darzustellen, die auch wirklich fuer den User sichtbar sind. 
Einen entsprechenden Algorythmus einzubauen sollte moeglich sein, 
allerdings muessen einige Fragen geklaert werden, z.b. was getan wird 
wenn nur ein Teil der Webseite neu gezeichnet wird.

*Codestruktur*
Ein weiteres Thema ist die Struktur von Enki. Ich finde es sollte so 
etwas wie packages geben, da man sicher nicht alle Elemente fuer jede 
Webseite benoetigt. Ich stelle mir hier ein Grundpackage mit den 
unabdingbaren Elementen vor, sowie weitergehende Packages mit 
Erweiterungen (z.b. Isomap). Diese koennen sicher auch Klassen des 
originalpackages um Funktionen ergaenzen.

Meine persoenliche Enki to-do list:
* right to left und bottom to top sorting in containern
* border aus bildern (angelehnt an den neuen CSS standard 
http://www.w3.org/TR/css3-border/ )
* bordertitel - schwierigkeit hierbei ist insbesondere die Hintergrundfarbe
* Fenstermanagement
* Popup/Alert aufbauend auf dem Fenstermanagement
* Popup menues (recht kompliziert. Angestrebt ist es, fuer Elemente 
Kontextmenuzeilen anzugeben, die bei klick (insbeondere ueberlagerter 
Elemente) zusammengefuegt werden)
* Zeichnen von unsichtbaren Elementen verhindern
* "Loading" Anzeige beim Laden von Enki


Soweit zu Enki. Nun ein paar Worte zu Ikne:

Wie wir schon gesehen haben, wird Enki zu gross, was das Volumen der 
Dateien angeht. Sicherlich erwarten wir nicht, dass ein thick client in 
einer Sekunde laed, aber mit groesserem Funktionsumfang wird Enki uns 
volumenmaessig ueber den Kopf wachsen. Ich halte es deshalb fuer 
unabdingbar, dass Ikne nicht nur den Code optimiert, sondern auch fuer 
eine deutliche Reduktion des Volumens durch Umbennenung sorgt.
Dieses Thema ist nicht einfach, da es Vielerlei gibt, dass durch solch 
eine Umbennenung kaputt gehen kann.
Hier ein paar Argumente und Vorschlaege mit Fuer und Wider:

* Andere, nicht mitkompilierte Bestandteile der Seite werden nicht mehr 
auf Enkifunktionen und Variablen zugreifen koennen.
In Enki sehe ich das Problem weniger: Hier wird fast jedes Projekt 
komplett in Enki geschrieben sein, und html elemente gibt es hier 
ohnehin nicht. Dennoch gibt es zwei Moeglichkeiten dieses Problem zu 
umgehen. Einmal kann man Ikne eine Liste mit zu schuetzenden Namen 
mitgeben. Dies waere dann codeunabhaengig, und vermutlich recht einfach 
zu erledigen; es waere ausserdem eine gute Moeglichkeit, die in 
ergulaerem JS enthaltenen Funktionen zu schuetzen. Alternativ, und auf 
lange Sicht vermutlich sinnvoller, waere ein keyword im code selber, den 
entsprechenden Definitionen vorangestellt. Vorstellbar waeren hier eines 
der in JS zwar reservierten aber nicht genutzten Woerter wie "public" 
oder "protected". Beide Methoden koennen gut zusammen genutzt werden.

* Genau wie andere Elemente auf Enki zugreifen koennen sollten, so 
sollten auch Aufrufe aus Enki auf externe Elemente nicht beschaedigt 
werden. Deshalb sollte Ikne nur solche Variablen und Funktionen umbennen 
duerfen, die in Enki selbst definiert wurden (mit function oder var).

* Rueckverfolgung und Zuordnung von Namen ist in JS recht schwierig. 
Prototypenfelder koennen gleich in zwei verschiedenen Weisen definiert 
werden ( proname['field'] = ''; oder proname.field = ''; ). Das wird 
insbesondere dann zum Problem, wenn man Felder wie druch die in Enki 
genutzte 'method' funktion definiert. Theoretisch kann man einem Objekt 
zur Laufzeit einen neuen Prototypen zuweisen, typing ist also hochdynamisch.
Insgesamt ist dies das Feld, das mir am meisten Sorgen macht, von dem 
ich allerdings trotzdem denke, dass es loesbar ist. Es sollten schon 
entsprechende Methoden im Compilerbau existieren, die ich aber nicht kenne.

Sollte es moeglich sein, diese Ueberlegungen, bzw. ihr Ziel, umzusetzen, 
halte ich Ikne fuer einen aeusserst vielversprechendes Projekt.

Weitere Dinge, die ich mir fuer Ikne wuensche:

* Umsetzung moeglichst vieler Anregungen von 
http://www.crockford.com/javascript/recommend.html zu einer Art extended 
JS ( XJS/IkneJS )
* Mehrere Modi, beliebig kombinierbar, die folgendes machen:
** Dateien von XJS/IkneJS in regulaeres JS uebersetzen
** Dateien mergen
** Gewoehnliche Komprimierung ( whitespaces, kommentare )
** Codeoptimierung
** Erweiterte Komprimierung (wie oben beschrieben)

So. Eine lange eMail, ich hoffe sie enthaelt einiges an guten Ideen. 
Kritik ist besonders erwuenscht. :)

Aragos

[Enki-devel] Container

[Aragos <ar...@ar...>]

Hoi,

ich schreibe gerade den Rowcontainer neu, und versuche sämtliche 
möglichen Situationen mit einzubeziehen. Dabei kommen aber einige 
Fragestellungen zu der Art und Weise, wie sich die gui verhalten sollte auf.
Bei der Entwicklung des Containers muss ich auf folgendes achten:

* Hat die Containerkomponente eine vordefinierte Größe?
** Wenn nicht, wird die Größe durch die enthaltenen Komponenten bestimmt?
** Wenn ja, wird diese den Kindkomponenten aufgezwungen, z.B. wenn diese 
größer als der enthaltende Container sind?
** Wenn ja, wie wird die Aufteilung des Raumes im Container vorgenommen 
( Das ist normalerweise das Kriterium, das die Containerart bestimmt )

* Haben alle Kinder vordefinierte Größen?
** Wenn nein, kann ich neue Größen zuweisen, und woran orientieren diese 
sich? (Insbesondere wenn der Container selbst keine Größe hat)
** Wenn ja, werden sie respektiert?
** Wenn ja, und sie werden nicht respektiert, werden die min/max Angaben 
der Elemente respektiert? In welchem Ausmaß (nur innerhalb des 
Containers oder auch nach ausserhalb?)

* Was geschieht bei rekursiven dynamischen Größenzuweisungen? Bisher ist 
es so, dass jede Komponente ihre Kindkomponenten in die eigene Rechnung 
einbezieht, aber nicht etwaige Änderungen an diesen, abhängig von ihren 
eigenen Kindelementen.


Als Entscheidungshilfe benutze ich bisher zwei flags; eines das angibt 
welche Ausrichtung (vertikal oder horizontal) der Container hat, und 
eines das die Respektierung von Min/Max Angaben kontrolliert.

Allerdings sind damit noch längst nicht alle Fragen geklärt, und ein 
bisschen Hilfe wäre - wie immer - willkommen. :)

Aragos