[xwiki-dev] [ArchitectureV2] UI Interfaces

[Sergiu Dumitriu]

On 3/22/07, Catalin Hritcu <catalin.hritcu at 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.
>
>
-- 
http://purl.org/net/sergiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070322/623bbbcb/attachment.html