Just like Dreamweaver it would be nice if you could also open other file formats apart from html. I have pages that have php includes and need a .php extension but these do not open in Komposer.
Logged In: YES
Also, plain text as a default for everything else. PHP/Smarty, for instance, uses plain text config files.
Logged In: YES
I agree completely... I have recommended NVU to multiple people in the past, all turning it down because it doesn't handle .php files...
Logged In: NO
I agree this would be very helpful. I know many people who would be able to use this feature (who don't want to spend the $$ on Dreamweaver).
I don't care if they show PHP by WYSIWYG. Just make it so we can open the source at least.
Logged In: YES
try html-kit. V 292 previews PHP includes. The new one will get it soon. Notepad ++ is a text editor with PHP markup
Some Thinking Being
¿¡KompoZer Destroys PHP Documents and The Like?! ¿¡What Is This, Men?!
I tried KompoZer a bit and am perplexed: simply, KompoZer destroys PHP documents and the like (!!!)...
¿¡What is this, men?! ¿You developed a WYSIWYG editor meant to handle just pure and static hyper-text documents? But: ¿¡and what about the real world?!... ¡Men, you perfectly know that, in the real world, the rule isn't pure and static hyper-text documents! You know that, to the contrary, the rule is server-side processed ones, not rarely with mix of languages in the embedded server-side scripts and, even, containing extended "markup vocabulary" related to the specific execution environment, among others "ill-formations".
I would rather love to have a fully powered open-source editor, Mozilla-based, and portable on Windows ( no-install ). But such an editor doesn't exist yet... However, there's one, called KompoZer, that, in the near future, depending on the development community's good sense, may become it. Meanwhile, everyone that needs a fully powered WYSIWYG editor, one really meant to the real world, is confined to DreamWeaver ( in fact, in my case, I'll just continue to use PitPad 3.2 )...
Bellow, I give my most sincere contribution to the project, in the form of a systematic list of requests. The application is still in the alpha phase, and it seems to me very promising. I guess you'll have a lot of "fun" implementing support to server-side processing instructions, since it appears that this will require a bit of deep hacking in Gecko's parsing routines.
# Preserve invalid markup -- This option, obviously, must includes things like: Server-Side Processing Instructions ( that is: markup for specific server softwares as well as that of server-side scripts ); Diverse other sorts of ill-formations in the document tree ( unterminated Elements, Element-like markup strange to the current DTD, MS IE's Conditional Comments,... ); And so on.
Source Code - Editing & Generation - Options
# Automatically wrap source code at column "n" ( [y|n] ).
# Configuration of tags' formatting ( like DreamWeaver's Tags Library ).
Tabs - "Split"
# Feature -- Instantly display, in the preview area, selected sections.
# Option -- Show complete source code.
Tabs - "Source"
# Feature -- Currently, when the "Source" Tab is activated, the "Document" Tab disappears, and, therefore, it's not possible alternate to other documents opened. This shouldn't be so.
# Option -- Syntax highlight.
# Option -- Auto-indent source code ( already taking into account the configurations of tags' formatting, listed above ) for ease of reading only -- that is: the actual file's text isn't affected ( applies also to the "Split" Tab ).
# DOM Explorer - GUI -- horizontal scrollbar in the Document Tree and the Properties Inspector.
DOM Explorer, Status Bar and Document Window - Integration
# Copy-Cut-Paste Operations -- Currently, it's not fully possible execute copy-cut-paste operations in the document through the DOM Explorer and the Status Bar. Surely, it's possible select a node and execute the proper command at the "Edit" menu, but this isn't a true solution -- it must be possible use the keyboard shortcuts ( "Ctrl [C|X|V]" ). Copy and cut support should be mandatory ( the contrary is weirdly counter-intuitive ). With respect to paste, there are no apparent difficulties: the thing reduces itself to a dialog window asking the position for the material being inserted -- before, after, within or "replace selection" ( once a node is selected, it, with its contents, becomes the current selection of the preview area, hence the need for a dialog window in paste operations ).
# Drag Operations -- Currently, it's not possible to change an Element's position in the document tree through the DOM Explorer and the Status Bar. Such a feature, however, would be extremely useful.