> this is so tantalising. The biggest thing I am missing from WO
> Builder is the way you can see, in a semi-2d way, which components
> are contained in which, what the conditionals are, what the strings
> are, and so on. Your new previewer is heading in that direction. In
> my excitement, here are the things I'd like to see next:
First off, let me be clear that this is not a WO Builder by ANY
stretch of the imagination. It will not satisfy you at all :). It's
purely a playground at the moment. With that out of the way .....
> - some sort of box around the block elements, and the ability to
> click on them to select them (yes, just like WO builder) so you can
> scroll to the end of that one and see what's next
I've tried out a bunch of various visualizations ... When I talk
trash about WO Builder, one of the major things I talk about is that
it doesn't do CSS. This is actually sort of true of this new preview
(I say "sort of", because mine is hardcoded at the moment to do my
own CSS -- I'm working on some tricks to do static analysis of
components to figure out which CSS files should be used .. this is a
very weird problem). In old WOB land, drawing borders is not a big
of a deal, because without CSS, page flow is much more linear. The
problem with a more modern page is that CSS does all sorts of
complicated layout, and you can't just draw boxes around things
anymore. I had a version that drew boxes and it's completely useless
because divs collapse from floated contents, stuff moves all around
-- it's just insane. Take a modern CSS page and add border: 1px
solid blue; to all of your elements and you'll essentially see what I
mean. The other particularly nasty problem is tables ... The most
common use of tables is to put a WORepetition around them. But you
can't just draw a box around that WORepetition, because there is no
element you can put in a table that surrounds a <tr> tag (browsers
push these things below or above the table if you try to inject bogus
tags around <tr>'s). This preview is rendering with WebKit (on OS
X), so we're still constrained by the definition of HTML. I have no
idea how to fix this one at the moment ... For containment right now,
I do rollover background color changes with alpha channel, so when
you rollover a container, it turns light blue, and when you rollover
a subcontainer of that container, it turns a slightly darker blue
(because of the compounding alpha).
Some of my thoughts at the moment are to do something like rather
than display [if]..[/if] blocks like I do now in the preview around
your elements, instead I will show a list of conditionals in a panel
that you can trigger on and off and see exactly what the page looks
like in those particular conditions. Likewise, I'm thinking for
repetitions that I might let you set the count via this same method,
so rather than try to draw a repetition abstractly, you can instead
just adjust the repetition count to see what your page looks like
when count == 0, or count == 50. These are all just random thoughts
-- I haven't put them together into anything cohesive yet.
On the rendering front, I actually added a custom extension to .api
files that WOLips will interpret for this view such that you can
declare a <preview> block of HTML in your api file. This supports
variable replacement for bindings via $syntax as well. This allows
you to provide a simple custom IDE override for your component of
what HTML to display in its preview state (for instance, it is
impossible for me to ever render WODynamicElements via static analysis).
Another possible future direction is to actually run your components
full on in a WO instance in that tab. This presents a ton of
complicated issues as well, but it's a possibility.
> - hover over a component and see all its bindings (OK, you're going
> to tell me to use inline bindings?)
What what it's worth, I never told you to do this, it was someone
else. There was a ranting match on the other mailing list that I
bowed out of. The only rant I had was that people log bugs for
broken stuff or broken stuff stays broken till I stumble on it (and
even then sometimes). And also, I've been contemplating all kinds of
potentially interesting extensions to the component editor to do
things like combine the WOD/HTML views together with rollover
bindings editors, etc. Until I find ways to better visualize
component boundaries combined with real CSS, the HTML editor side of
things is going to be where real work gets done in WOLips.
> - click on an element and go to the component editor with that
> component highlighted
This can probably be done, but I have to figure out how to intercept
custom events from the SWT browser control.
> - tables. Yes, tables! Despite the trendy hatred of tables, the W3C
> tells us there are times when tables are absolutely right: for
> example, a table of data! And being able to see the heading
> straight above the cell you are editing is very useful.
Easy on the snarkiness :)
> I was going to say more, but opening a moderately complex component
> in preview soaked 100% CPU in Eclipse, and it still hasn't
> finished. I think I'll kill it...
You might have managed to hit an infinite loop of components ... It's
not particularly smart yet, and just a place to explore visualization
concepts.
ms
This archive was generated by hypermail 2.0.0 : Thu Oct 04 2007 - 08:21:13 EDT