Martin Atkins (mart) wrote in lj_dev,
Martin Atkins
mart
lj_dev

Realtime Preview S2 editor

For some time now I've been working on a new S2 editor with a realtime preview based around client-side S2, but I didn't make a big deal out of it until now because I wanted to make a nice prototype. Now that it's done, you can view the proof of concept editor, which allows you to customise a style from my simple demo S2 application.

A hypothetical implementation on LJ would have the server generate the data structure to use for the preview so that the user can see the style as it applies to their journal right now, just as it would render normally. The form in the top frame would also be generated on the server — rather than on the client as it is in the demo — thus allowing code to be shared with the existing non-fancy editor which must stick around for accessibility reasons.

There are a few issues still to be addressed:

  • The colour picker doesn't work quite right. Since I'm loading it directly from LiveJournal.com I've not changed it, but it could be fixed by allowing the caller to specify a hook which is run when the user clicks OK, thus allowing the preview to be updated immediately. (It's also broken in IE, but I've not attempted to figure out why yet.)
  • Without the ability to filter HTML at the client side, untrusted layers can do what they like. I'm not sure if it's possible to completely “sanitise” the object heirarchy by removing all of the cookie collections from it, but I think that approach is less scary than trying to implement the HTML cleaner on the client.
  • Constructional properties (those which affect the data passed to the S2 style in the first place) can't be previewed in realtime, since the server handles those before it produces the data structure to use for rendering. They can be initially handled by allowing the data generator to accept a S2 styleid parameter, but changes to the props won't be reflected in the preview without special touches. I figure that we can just handle some of the more common ones with little hacks, like retrieving the maximum number of entries and truncating the entry array client-side. Other than that, a property attribute can be added which specifies that a property is constructional and then the UI can indicate that it will not be shown in the preview. There aren't many constructional properties on LJ anyway. (there are lots on Fotobilder, so deployment there would be harder.)
  • It doesn't allow the user to choose whether or not to override specific properties. That's easy enough to add, though.
  • Need to think about what do do with closed-source layers. My first thought is just to disable it for those, but users shouldn't have to suffer just because people don't want to share their layouts. I guess, though, that it could be considered an incentive against closed-source layouts.

I think the realtime preview is pretty neat, though, so it's worth doing even if it can't cover all cases. Any ideas for working around the problems listed above would be appreciated.

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 18 comments