Antworten auf Ihre Fragen • Datenbank-Pflege • 4D Coaching • OpenDDDD • Termine • 4D Expert V11/V12-Service • Konzepte • Alternativen • Meine Apps
GebrauchtesMac + iPhone: zu verkaufen
Geo-Themen + ProjekteGoogleMap-Integration • GeoDDDD • Database Publishing • Database Photography
9. Mai 2009
These days in the NUG:
HTML is just one reason to create program-text inside the 4D method-editor. That's a lot of work, hard to debug and nearly unmaintainable.
If it were HTML alone, I'd work around that sort of
combining 4D language with other languages
To use the terminal with the help of LAUNCH EXTERNAL PROCESS looks like this:
With V11 we get SQL also, which is pure text and a nightmare if hardcoded into a method: no syntax-coloring, no syntax-completion, no error-highlight. There is a single plus: a command can stretch across several lines.
How to overcome these deficiencies?
Dreaming of rich text in 4D
The current method-editor of 4D isn't bad at all. On my whislist are only a couple of items like:
Nowadays we are using other than 4Ds language in the method-editor, too. That has been for a long time AppleScript and HTML and since V11 there is SQL-code. Myself I've used a couple of other textformats for exportpurposes, especially such describing maps, like GEM, CGDef, kml, or MIF for FrameMaker and other tagged text especially for Quark Xpress or Adobe InDesign.
In the early days there was a tool, that converted AppleScript to 4D code using the clipboard as transporter. Very handy, classic Mac only and I forgot its name.
It makes no sense to write that kind of text into the methode-editor of 4D, neither the first incarnation up to V6 nor the current one since V2003. So I developed a couple of strategies:
A function for every kind of textobject of a language
As the first example: $result := MG_DrawRect (ID;Xmin;Ymin;Xmax;Ymax). The result looked like this:
A second one: $result := HTML_header (3;"This ist headercontent"). The result looked like this:
That works, but I got as many methods as there where different textobjects. For every method I had to remember a set of different parameters. Adding attributes to HTML-statemente like class, title, id, align, width, … forget it; inconvenient.
One method for all textobjects for one language
These days, I use one large method instead of a dozen or two single-purpose ones. They all follow one scheme for their parameters: $1 is the message what to do, $2 is the object where and $3 a longint for the record ID. That works pretty well instead of form-methods, object-methods, process-starters and process-methods. One place for everything, sort of moduls without their annoyances.
This approach is less well suited for HTML or SQL.
A couple of years ago, actually with version 6, David Adams published a couple of books about 4D and HTML. One of his recommendations was, to use stored text instead of writing HTML inside of 4Ds method-editor. Right he was. 4D supports that kind of thinking since v2004, when PROCESS HTML TAGS could be called anywhere and for any text tagged with 4D HTML tags.
That's what we should do: store textcode in textfields. The textfields are capable, the 4D-native editor is not.
How abouts 4D Write?
I've evalutated 4D Write as HTML-frontend. 4D Writes own HTML-export is not satisfying.
Then I looked into and spent quite a amount of time to use 4D Write as a rich text-editor. But that's not satisfying either. One big hinderance is 4D Write's modell of styles. How 4D Write uses styles is better understood as macros, that execute a styledescription to selected text. After that it doesn't know about styles anymore. That concept of stylesheet is probably one reason for its poor HTML-export-capabilities. So 4D Write is to no avail.
This all leads to the dream of a rich text-editor inside 4D. Something along the lines of:
Textmate belongs here too, but I don't own a license. By the way Smultron even lists Active4D!
Nobody asks 4D to invent the wheel again, so why not