#56 - WYSIWYG themeing
-
By Chris Graham
- Added
- 7 views
| Identifier | #56 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | WYSIWYG themeing |
| Status | Closed (no changes needed) |
| Handling member | Chris Graham |
| Addon | core_themeing |
| Description | Allow themes to be edited in Kompozer or Dreamweaver, to make themeing reasonable for regular people.
There are many classic problems that make this impossible: - Templates are HTML fragments - ...with no data - ...and not likely XHTML compliant due to embedded Tempcode - If we did edit a rendered screen instead, there would be huge confusion between panel-structure/templates/content - ...and all kinds of errors would happen, like one instance of a template being edited in a different way, impossible to resolve So instead we could export something in the middle: not raw templates, and not rendered screens, but specially controlled 'screen previews'. These can be implemented by implementing a wide collection of these screen previews to get full template coverage, rendering the templates through a custom Tempcode engine that does some magic to make it Dreamweaver-safe. Lorem-Ipsum text would be used to make the screens nice and neutral. The 'magic' done would consist of a lot of embedded XHTML comments that give hints to Composr when it comes to reimporting the screen. Now that we could have a screen library we can also utilise this to do previews for individual templates, and for methodically testing a theme on different browsers or just for general prettyness or other forms of 'compliance' (added bonuses). The rough workflows would be... 1) Browse screen previews for inline preview, export, or re-import 2) Export any screen previews relating to the current real-screen, via links on the template tree, and re-import 3) Preview the current template via it's screen preview Importing would not be direct, it would go through a confirmation process that would show the changes needing to be made. |
| Steps to reproduce | |
| Additional information | The "magic"
----------- For simple string parameters, we just leave the Tempcode drop point alone in most cases. If a parameter is inside a tag definition, we encode it as a new attribute. For parameters that are encoded in Tempcode, we use HTML comments to mark the start and end OR if it what is being embedded parses cleanly as HTML (i.e. tags line up) we wrap a div around it that is encoded for the same effect. Tempcode directives turn into encoded contextually suitable tags (e.g. tbody, div, span), or HTML comments if nothing contextual can exist (e.g. inside a tbody only tr's can be used, but tr's can't wrap tr's) All works via a combined XHTML/Tempcode parser We write a tool to scan for impossible drop points (e.g. dropping a template inside a tag definition or tag attribute; or a directive that doesn't match with the DOM tree) - and warn about them. This should also be incorporated into the exporter, showing as an error ("Cannot export this") The exporter should export a zip of images etc Image references must be resolved to local image references to files in the zip; ditto CSS references CSS files would have to be smart enough to export nicely too, interpreting local image references We then need to be able to reincorporate it all In the UI it should show the changes the user has made, rather than an immediate import; a safety net To export, the template tree should provide named export links on each node (e.g. "Export download box to WYSIWYG edit"), which will export the template preview for that spot, and then invite the user to reimport it Things that need doing ---------------------- Make all preview functions For 4.4 there have been lots of template changes, and also support for some new (unused) parameters. Our template preview code will need to work with all this. When you preview a template in admin_themes it should show what other templates were used in the preview and allow you to open them in new template editor tabs Generally the template editor will become more like a good desktop text editor, able to open/close/save different files in different tabs. The general themeing feel will be of a much more efficient/intuitive/reliable/self-explanatory/safe/comfortable system. Merge the CSS and template editors: no need for separate code, and it will cause problems Link each templates screen into template tree, so you can choose to edit all templates on screen instead of an individual template Put list of screens on template editor screen, which opens up template editor with all templates on that screen For list of screens also provide a very simple inline preview feature, and provide previews for Comcode pages also (these should open up in Comcode editor though) Put export button in Template editor Put screen preview button in Template editor Make template editor not navigate away each time you save Export action must make tar Give advice to only edit one exported tar at a time, to avoid conflicts Make import button in Template editor, that imports and loads up tabs for all templates in it with the changes made Make the actual importer needed; imports from tar Lots and lots of testing Unit tests to ensure all works / coding standards Maybe make a unit test that XHTML-validates all the screens |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
function init__template_export()
{
define('TPE_BORING',0);
define('TPE_INSIDE_TAG_DEFINITION',1);
define('TPE_INSIDE_TAG_ATTRIBUTE',2);
define('TPE_INSIDE_TAG_CSS',3);
define('TPE_INSIDE_TEMPCODE_TAG_DEFINITION',4);
define('TPE_INSIDE_CSS',5);
}
// NB: $parameters is an array of strings, no compiled Tempcode allowed
function do_exportable_template($template_name,$raw_tempcode,$parameters,$context=NULL)
{
if (!is_null($context)) $context=TPE_BORING;
$stream='';
_inject_into_context($context,$stream,'[TEMPLATE-START:'.$template_name.']');
$brace_depth=NULL;
$len=strlen($raw_tempcode);
for ($i=0;$i<$len;$i++)
{
$next=$raw_tempcode[$i];
$after=($i!=$len-1)?$raw_tempcode[$i+1]:'';
switch ($next)
{
case '\\': // Escaping
if ((!$escaping) && (($after=='\\') || ($after=='{') || ($after=='}')))
{
$stream.=$after;
{
$stream.=$next;
}
break;
case '<':
TODO
case '>':
TODO
case '{':
if ((strtoupper($after)==$after) && (!is_numeric($after))) // Check it's really going to be treated as Tempcode
{
$balance=0;
$to_inject='';
while ($i<$len)
{
$next=$raw_tempcode[$i];
$to_inject.=$next;
if ($next=='{') $balance++;
elseif ($next=='}') $balance--;
$i++;
if ($balance==0) break;
}
$with=NULL;
$matches=array();
if (preg_match('#^\{(\w+)[^\{\}]*\}$#',$to_inject,$matches)!=0)
{
$with=$paramters[$matches[1]];
}
_inject_into_context($context,$stream,$to_inject,$with);
break;
}
default:
$stream.=$next;
break;
}
}
_inject_into_context($context,$stream,'[TEMPLATE-END:'.$template_name.']');
return $stream;
}
function _inject_into_context($context,&$stream,$to_inject,$with=NULL)
{
if (!is_null($with)) $stream.=$to_inject.$with;
switch ($context)
{
case 'TPE_BORING':
$stream.=$to_inject;
break;
case 'TPE_INSIDE_TAG_DEFINITION':
TODO
break;
case 'TPE_INSIDE_TAG_ATTRIBUTE':
$matches=array();
preg_match('#(\w+)="([^"]*)$#',$stream,$matches);
$attribute=$matches[1];
$prior=$matches[2];
$tag_start=strrpos($stream,'<');
$stream=substr($stream,0,$tag_start).'[TEMPCODE-PLACEHOLDER:tags-attribute:'.$attribute.':after:'._bracket_escape($prior).'::'._bracket_escape($to_inject).']'.substr($stream,$tag_start);
break;
case 'TPE_INSIDE_TAG_CSS':
case 'TPE_INSIDE_CSS':
$stream.='/*[TEMPCODE-PLACEHOLDER:un_css_comment::'._bracket_escape($to_inject).']*/';
if (!is_null($with)) $stream.=$with;
break;
case 'TPE_INSIDE_TEMPCODE_TAG_DEFINITION':
TODO
break;
}
TODO
}
function _bracket_escape($text)
{
return str_replace(array('[',']'),array('\[','\]'),$text);
}