22 Mar
2007
22 Mar
'07
10:48 a.m.
On 3/22/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hi Sergiu,
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
> 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. designers are already used to (plain HTML), rather
that one that looks
like HTML but with an awkward syntax.
--
http://purl.org/net/sergiu