On 3/22/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi Sergiu,
> > 1. Right now we are putting Interface Elements (IE for short, also stands
> for Interface Extension) manually in the current skin. The only thing
> aggregated are the panels. Each of these elements is put in a <div>, maybe
> with an id and class. In XUL, each element having an id is a possible
> extension point (EP for short). It would be hard to use divs and ids, that's
> why we should replace these with something like #startelement("id", "class")
> and #endelement("id" "class"). These macros create extension points, and
> they aggregate any content that wants to be included in here. (as a bonus,
> we can keep a stack of open elements, and when we close an element (with an
> id) we can automatically close the missing #endelement-s)
>
In your example you expanded #startelement some times to a div tag,
but some other time to an img tag (which was wrapped in a div just to
make things fit). This probably means in the end you would have a
#startelement("div" "id" "class") in the first case, and a
#startelement("img" "id" "class") in the second. So one more "tag"
argument.
To me this seems like reinventing HTML tags in Velocity. Why couldn't
we do it in plain HTML using id's and classes for the usual HTML
elements (not necessarily divs)? Every element that wants to be an
extension point could also have class "ep". At this point I don't see
why this wouldn't work. We could just pass the page first through a
very simple "extension renderer", which might even expand begin and
end tags to velocity #startelement-s and #endelement-s, and then leave
the work to Velocity.
I know it is difficult to use #startelement and #endelement. This is not a final decision, but rather an idea of how it could be done in the given architecture (velocity + radeox). Maybe it could be done a lot easier in wikimodel.
Using HTML only means that we need to add a new rendering engine, one that expands extension points. It is a better idea, but it needs more work. More, we don't need any special syntax, and it does not depend on velocity. Even more, we're not bound to using only div elements or specifying all the attributes that we might want to set to the generated element; all the markup is already there.
Before jumping to the implementation, we do need to define how exactly is an EP defined, and when and how are they filled in. What we need to decide is the architecture, meaning what is an extension point and what is an extension.
The advantage of this would be a very simple syntax with which
designers are already used to (plain HTML), rather that one that looks
like HTML but with an awkward syntax.